Subject: [MMUSIC] Notes from Orlando human language draft discussion

From: Randall Gellens <[email-masked]>
Date: Fri, 15 Mar 2013 11:49:49 -0700

Hi everyone,

Thanks very much for the productive discussion.  Here are my notes:

SDP or SIP:
- Use SDP for actual negotiation, but use SIP header to provide a hint
- Emergency services use case can use SDP for policy routing/handling decisions
- Other use cases may or may not have ability/desire to use SDP for 
this and can use the SIP header hint
- SDP useful in protocols other than SIP
- SIP header with hint is either a new header or caller preferences 
(RFC 3841), presumably Accept-Contact; caller sets media and language 
and optionally required; not clear if this matches our desired 
semantics
- SIP header is just a hint; it is not required to be sent or to be 
used on receipt; it is recommended to be sent

New SDP attribute(s) vs re-use of existing 'lang' attribute:
- Existing attribute semantics are unclear so should be avoided
- Minting new attributes is cheap

Directionality of SDP attributes:
- Define two new SDP media-level attributes: 'send-lang' and 
'recv-lang'.  In an offer, send-lang is a list in preference order of 
the languages the offerer wishes to send and recv-lang is a list in 
preference order of the languages the offerer wishes to receive.  In 
most cases these are expected to have the same value, because 
otherwise it is harder to match desired resources.  In an answer, 
send-lang is the accepted language the answerer will send (which in 
most cases should be one of the languages in the offer's recv-lang) 
and recv-lang is the accepted language the answerer expects to 
receive (which in most cases should be one of the languages in the 
offer's send-lang).

Advisory vs Required:
- Does call fail if no common language?
- Define token for use in offer to indicate caller's preference to 
fail call or not if no common language.
- One choice is to say that if the last character of the send-lang or 
recv-lan value an asterisk, this indicates a request to not fail the 
call (similar to SIP Accept-Language syntax).  Either way, the called 
party may ignore this, e.g., for the emergency services use case, a 
PSAP will likely not fail the call.

Other changes (from additional side discussions):
- Add advice that the value of the parameters should stick to the 
largest granularity of language tags, that is, it is recommended not 
to add subtags (e.g., for region or dialect) unless the languages 
might be mutually incomprehensible without them.
- Expand Introduction to be more clear about purpose of document and 
problem being solved
- Add more detailed use case descriptions

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
I was gratified to be able to answer promptly, and I did.  I said
I didn't know."                                      --Mark Twain

---

From: Gunnar Hellstrom <[email-masked]>
Date: Fri, 15 Mar 2013 20:04:58 +0100

These seem to be good conclusions.

You say about directionality, for the lang-parameters in the different 
directions:
In most cases these are expected to have the same value, because 
otherwise it is harder to match desired resources.

I do not think that should be expected.

Examples:
1. Many deafblind persons prefer to sign for sending, but require text 
reception.

2. Many hard-of-hearing persons want to talk but receive text back.

3. Many persons with speech disabilities want to send text but receive 
speech

The conclusion to develop specifications for both the SIP level and the 
SDP level seems a bit complex, but can provide the desired resulting 
functionality.

Good.

/Gunnar

On 2013-03-15 19:49, Randall Gellens wrote:
> and optionally required; not clear if this matches our desired semantics
> and recv-lang is the accepted language the answerer expects to receive 
> (which in most cases should be one of the languages in the offer's 
> send-lang).
>
> Advisory vs Required:

---

From: Randall Gellens <[email-masked]>
Date: Fri, 15 Mar 2013 15:14:04 -0700

At 8:04 PM +0100 3/15/13, Gunnar Hellstrom wrote:

>  Examples:
>  1. Many deafblind persons prefer to sign for sending, but require 
> text reception.
>
>  3. Many persons with speech disabilities want to send text but receive speech

Yes, but that does not mean that the media streams need to be 
explicitly negotiated such.  E.g., just because someone intends to 
primarily use a text stream for sending does not mean it must be 
prohibited to receive text back.

-------------- Randomly selected tag: ---------------
It is by the fortune of God that, in this country, we have three
benefits: freedom of speech, freedom of thought, and the wisdom never
to use either.                                           --Mark Twain

---

From: Gunnar Hellstrom <[email-masked]>
Date: Sat, 16 Mar 2013 08:23:02 +0100

> prohibited to receive text back.
Yes, very true.
Other media and media directions than the ones you declare preference 
for are usually also appreciated, and sometimes important.
You said some time ago that a medium-direction with no language 
indication just means that there is no preferred language use of it, but 
it may very well be desired in the call and should be connected if 
supported. That was why the a=sendonly and a=recvonly attributes cannot 
be used for preference indications.

Let us take the deaf-blind example.

A deaf-blind person may prefer to sign, and prefer to receive text, and 
be able to send text.
But in contact with another deaf-blind person with same preferences and 
capabilities, there are then two choices:
1. Connect the call directly and type both ways.
or
2. Connect a relay service that handles sign-to-text translation both ways.

I would assume that most users for this case would select the direct 
connection, but that is a matter of preference and situation.

This can create a need for level of preference indication between two 
different media, and not just by position of a language within one medium.
I mean for the example above: prefer sign out, but manage text out.

/Gunnar

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 16 Mar 2013 19:54:44 +0000

On Mar 15, 2013, at 2:49 PM, Randall Gellens <[email-masked]> wrote:

> - Other use cases may or may not have ability/desire to use SDP for this and can use the SIP header hint

Another reason not to only put it in SDP is the delayed-offer scenario.

> - Define two new SDP media-level attributes: 'send-lang' and 'recv-lang'.  In an offer, send-lang is a list in preference order of the languages the offerer wishes to send and recv-lang is a list in preference order of the languages the offerer wishes to receive.  In most cases these are expected to have the same value, because otherwise it is harder to match desired resources.  In an answer, send-lang is the accepted language the answerer will send (which in most cases should be one of the languages in the offer's recv-lang) and recv-lang is the accepted language the answerer expects to receive (which in most cases should be one of the languages in the offer's send-lang).

What's the use-case when the two directions are not identical?  I.e., when does it make sense to receive Latin but send Swahili for the same media?
I ask because this separation complicates things quite a bit in code/testing/error-handling, obviously.

> - Does call fail if no common language?

I haven't thought about this draft's scenarios much, but think we need to think about this very carefully.  Otherwise the outcome would be SBCs would strip it from the INVITE, just to avoid failing the call.  I don't think anyone would actually want such calls to truly fail for the end user - not just for Emergency calls, but for any calls - people can always hang up if they don't like what they hear/see.  ISTM that there's a high likelihood of this language value actually being *wrong* in either the sender or receiver or both, so I think failing the call because of a mismatch would be really bad.

At first glance, I can see one and only one reason failing it would make sense: for a serial-forking proxy/B2BUA/UA to be able to recurse to alternate targets if the first one didn't support the language(s).  But it has a very negative drawback: if there are no more targets it can recurse to, or if there were no such forking to begin with, the call fails.  Then we're back to square one above, and the thing gets removed from all calls by middleboxes, just to avoid such cases.

-hadriel
p.s. was this presented in MMUSIC this past week?  For some reason this topic was neither on the MMUSIC agenda pages (http://www.ietf.org/proceedings/86/agenda/agenda-86-mmusic), nor in the meeting materials (https://datatracker.ietf.org/meeting/86/materials.html), nor is the draft on the MMUSIC tools page (http://tools.ietf.org/wg/mmusic/).  I only mention this because I was looking for the slides and draft today and didn't find them.

---

From: Gunnar Hellstrom <[email-masked]>
Date: Sat, 16 Mar 2013 22:32:21 +0100

> I ask because this separation complicates things quite a bit in code/testing/error-handling, obviously.
Examples are:

1. Deaf-blind person who want to use sign language in video out, but 
cannot see it in reception and therefore declare language in video only 
for send video.
( also declaring preference for reading text and acceptance for typing 
text )

2. Hard-of-hearing person who want to talk in audio channel, but cannot 
hear answers , and therefore declare languge for audio only in send audio
( also declaring preference for reading text and acceptance for typing 
text )

3. Person with speech disabilities who want to hear in audio channel, 
but cannot use audio for talking
( also declaring preference for typing text and acceptance for reading 
text )

By the way, here we have a tricky case:
4. Person with speech disabilities who want to hear in audio channel, 
and talks unclearly, so that he want a speech relay service to listen to 
the call and clarify what got hard to understand for the other party.
Maybe that service needs to be requested with an explicit service 
request instead of language and modality matching?

  /Gunnar

---

From: Randall Gellens <[email-masked]>
Date: Sat, 16 Mar 2013 14:54:46 -0700

At 7:54 PM +0000 3/16/13, Hadriel Kaplan wrote:

>> 'recv-lang'.  In an offer, send-lang is a list in preference order 
>> of the languages the offerer wishes to send and recv-lang is a 
>> list in preference order of the languages the offerer wishes to 
>> receive.  In most cases these are expected to have the same value, 
>> because otherwise it is harder to match desired resources.  In an 
>> answer, send-lang is the accepted language the answerer will send 
>> recv-lang) and recv-lang is the accepted language the answerer 
>> expects to receive (which in most cases should be one of the 
>> languages in the offer's send-lang).
>
>  What's the use-case when the two directions are not identical? 
> I.e., when does it make sense to receive Latin but send Swahili for 
> the same media?

I'll let Harald speak to this as he was pretty insistent that it was 
a misuse of SDP (if I understood him) to use the same attribute for 
sending and receiving.

>  I haven't thought about this draft's scenarios much, but think we 
> need to think about this very carefully.  Otherwise the outcome 
> would be SBCs would strip it from the INVITE, just to avoid failing 
> the call.  I don't think anyone would actually want such calls to 
> truly fail for the end user - not just for Emergency calls, but for 
> any calls - people can always hang up if they don't like what they 
> hear/see.  ISTM that there's a high likelihood of this language 
> value actually being *wrong* in either the sender or receiver or 
> both, so I think failing the call because of a mismatch would be 
> really bad.
>
>  At first glance, I can see one and only one reason failing it would 
> make sense: for a serial-forking proxy/B2BUA/UA to be able to 
> recurse to alternate targets if the first one didn't support the 
> language(s).  But it has a very negative drawback: if there are no 
> more targets it can recurse to, or if there were no such forking to 
> begin with, the call fails.  Then we're back to square one above, 
> and the thing gets removed from all calls by middleboxes, just to 
> avoid such cases.

The result of the discussion is to add a token for the caller to 
indicate a preference for the language being mandatory or advisory, 
but the callee is not required to honor this preference.  I can 
imagine scenarios where failing the call might be preferred, such as 
a caller who will call an alternate party if the required language 
isn't supported.

>
>  -hadriel
>  p.s. was this presented in MMUSIC this past week?  For some reason 
> this topic was neither on the MMUSIC agenda pages 
> (http://www.ietf.org/proceedings/86/agenda/agenda-86-mmusic), nor 
> in the meeting materials 
> (https://datatracker.ietf.org/meeting/86/materials.html), nor is 
> the draft on the MMUSIC tools page 
> (http://tools.ietf.org/wg/mmusic/).  I only mention this because I 
> was looking for the slides and draft today and didn't find them.

No, this is my fault.

-------------- Randomly selected tag: ---------------
An economist is an expert who will know tomorrow why the things he
predicted yesterday didn't happen today.       --Laurence J. Peter

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 17 Mar 2013 00:21:37 +0000

Preface note: I am not against the needs of hearing-impaired or visually-impaired people - I'm asking the questions because I think the simpler the mechanism is, the more likely it will be to actually work and be deployed, and thus not hinder such cases.

I may be very very wrong, and I'd certainly defer to those who know for sure, but I would think they'd want the call to succeed for the media types they need to use, rather than only succeed if the specific directionality traits of those media lines are supported by the other side.

For the below comments, I'll use 'sign-language' as a token, although I assume there must actually be many tokens since there are many sign languages.

Other comments inline...

On Mar 16, 2013, at 5:32 PM, Gunnar Hellstrom <[email-masked]> wrote:

> 1. Deaf-blind person who want to use sign language in video out, but cannot see it in reception and therefore declare language in video only for send video.
> ( also declaring preference for reading text and acceptance for typing text )

So just indicate 'sign-language' for video media, and have a text media line.
It will be very clear to the far-end when they see the caller is blind that they can only see sign language but not send it.  Or if you want to make it one-way video on the wire, that's what the 'a=sendonly' is for. (same goes for text media line)

The important thing is that you need to reach someone who can understand your sign language.

> 2. Hard-of-hearing person who want to talk in audio channel, but cannot hear answers , and therefore declare languge for audio only in send audio
> ( also declaring preference for reading text and acceptance for typing text )

If you literally only want to send audio but not receive, use 'a=sendonly' for the audio line, and have a text media line.  If, however, you mean they want bi-directional audio but a preference to reach someone who can also do text, or video for sign-language, send normal audio and text media lines, or with a 'sign-language' video line.

The important thing is that you reach someone who can hear you, and can type text back to you (or do sign language).

> 3. Person with speech disabilities who want to hear in audio channel, but cannot use audio for talking
> ( also declaring preference for typing text and acceptance for reading text )

Same as above, but with 'a=recvonly' if you literally want one-way on the wire.
The important thing is you reach someone who can talk to you, but also can read text from you or see your sign language.

> 4. Person with speech disabilities who want to hear in audio channel, and talks unclearly, so that he want a speech relay service to listen to the call and clarify what got hard to understand for the other party.
> Maybe that service needs to be requested with an explicit service request instead of language and modality matching?

I have not looked into how such relay services work, for example VRS.  It would be good to know how they're used in practice. (I can imagine several ways they could be done)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 17 Mar 2013 01:03:13 +0000

On Mar 16, 2013, at 5:54 PM, Randall Gellens <[email-masked]> wrote:

> I'll let Harald speak to this as he was pretty insistent that it was a misuse of SDP (if I understood him) to use the same attribute for sending and receiving.

That may be true for attributes specific to a format/payload type... maybe.  But for just attributes applying to a media or session section, I don't think so.  You can look up the registered SDP attributes in IANA and find a bunch that really apply to both directions, at least in practice.  For example: the 'a=inactive' attribute.  It's not inactive for a specific direction, it's inactive for both directions.

> The result of the discussion is to add a token for the caller to indicate a preference for the language being mandatory or advisory, but the callee is not required to honor this preference.  

If the callee is not required to honor a mandatory preference, then it's not really mandatory is it?
Is there a third token for "I really mean it"? ;)

> I can imagine scenarios where failing the call might be preferred, such as a caller who will call an alternate party if the required language isn't supported.

I can imagine scenarios where the caller will call an alternate party as well, but that's what we let them do by letting them hang-up/end the session.
And I'm not saying that to be flippant.  I'm really worried calls will fail when the user didn't want them to, and that would be bad.  Bad because I don't want them having to read a manual to make a call work, or having them contact their provider's tech support to figure out why their call failed.

-hadriel

---

From: Gunnar Hellstrom <[email-masked]>
Date: Sun, 17 Mar 2013 08:37:00 +0100

> I may be very very wrong, and I'd certainly defer to those who know for sure, but I would think they'd want the call to succeed for the media types they need to use, rather than only succeed if the…
Yes, we said so yesterday:
>>> I ask because this separation complicates things quite a bit in code/testing/error-handling, obviously.
The need came from the relay service examples.
But let us try to fancy a need from the spoken language side:
A high level conference is held with English as main language but 
possibility to get interpreting to and from other languages.

A delegate from Kenya feel well confident in listening directly in 
English, not risking delays and dropouts through interpreters, but feel 
much more confident in expressing herself in Swahili when she speaks. 
Therefore she selects that combination and the remote conference is set 
up so that she get the Swahili interpretation when she talks.
> The important thing is that you need to reach someone who can understand your sign language.
No, the important thing is to have a chance to rapidly evaluate either 
how to route the call to someone who match the preferences, or to add 
services doing translations so that the preferences are fulfilled.

It is not good to let the deaf-blind user be connected with a person who 
has only video enabled.
> If you literally only want to send audio but not receive, use 'a=sendonly' for the audio line, and have a text media line.
We said yesterday that that is not the case, we are not discussing 
sendonly etc.  It is use of the media we are discussing.  Support of the 
media is another thing, already well covered in both SDP and SIP.
>   If, however, you mean they want bi-directional audio but a preference to reach someone who can also do text, or video for sign-language, send normal audio and text media lines, or with a 'sign-language' video line.
>
Read
http://www.etsi.org/deliver/etsi_es/202900_202999/202975/01.02.01_60/es_202975v010201p.pdf

/Gunnar

---

From: Randall Gellens <[email-masked]>
Date: Sun, 17 Mar 2013 12:36:22 -0700

At 1:03 AM +0000 3/17/13, Hadriel Kaplan wrote:

>>> I.e., when does it make sense to receive Latin but send Swahili 
>>> for the same media?
>>  I'll let Harald speak to this as he was pretty insistent that it 
>> was a misuse of SDP (if I understood him) to use the same 
>> attribute for sending and receiving.
>
>  That may be true for attributes specific to a format/payload 
> type... maybe.  But for just attributes applying to a media or 
> session section, I don't think so.  You can look up the registered 
> SDP attributes in IANA and find a bunch that really apply to both 
> directions, at least in practice.

I don't want to put words in Harald's mouth, but my recollection is 
that he specifically mentioned the "in practice" as being an abuse.

>   For example: the 'a=inactive' attribute.  It's not inactive for a 
> specific direction, it's inactive for both directions.

That makes sense, and personally I'm in favor of keeping things as 
simple as possible.  But I also don't want to be accused of fomenting 
further misuse of SDP :-)

>> indicate a preference for the language being mandatory or 
>> advisory, but the callee is not required to honor this preference.
>

The preference is not mandatory (if it was, it wouldn't be a 
preference, it would be a demand).  The preference indicates if the 
caller wants the callee to treat language as mandatory versus 
advisory.

>>  I can imagine scenarios where failing the call might be preferred, 
>> such as a caller who will call an alternate party if the required 
>> language isn't supported.
>
>  I can imagine scenarios where the caller will call an alternate 
> party as well, but that's what we let them do by letting them 
> hang-up/end the session.

If this is really what is wanted, it is quicker if the call fails 
during setup rather than going through full setup, possible queues 
(remember, a major use case is calling call centers), attempting to 
speak to a representative, and then hanging up in frustration.

>  And I'm not saying that to be flippant.  I'm really worried calls 
> will fail when the user didn't want them to, and that would be bad. 
> Bad because I don't want them having to read a manual to make a 
> call work, or having them contact their provider's tech support to 
> figure out why their call failed.

I am also concerned about introducing features where it is not 
obvious what the client should do.  I can see obvious ways for a 
client to make a reasonable default language choice, and ways to 
allow the user to configure it.  It's harder to see how a client 
knows if the advisory token should be set to fail or proceed.

-------------- Randomly selected tag: ---------------
The fetters imposed on liberty at home have ever been forged out of the
weapons provided for defence against real, pretended, or imaginary
dangers from abroad.
        --James Madison, 4th US president (1751-1836)

---

From: Christian Groves <[email-masked]>
Date: Mon, 25 Mar 2013 16:50:33 +1100

Hello,

One thing that doesn't seem to be noted is an overlap with the work of 
the CLUE WG. There has been some discussion in the CLUE working group 
about adding attributes to captures to describe the language, whether 
sub-titles are used, whether a stream comes from an interpreter, etc. 
Where multiple streams are used I would expect any work in this area 
should be aligned.

Regards, Christian

On 17/03/2013 6:37 PM, Gunnar Hellstrom wrote:
>> Preface note: I am not against the needs of hearing-impaired or 
>> visually-impaired people - I'm asking the questions because I think 
>> the simpler the mechanism is, the more likely it will be to actually 
>> work and be deployed, and thus not hinder such cases.
>>
>> I may be very very wrong, and I'd certainly defer to those who know 
>> for sure, but I would think they'd want the call to succeed for the 
>> media types they need to use, rather than only succeed if the 
>> specific directionality traits of those media lines are supported by 
>> the other side.
> indication just means that there is no preferred language use of it, 
> but it may very well be desired in the call and should be connected if 
> supported. That was why the a=sendonly and a=recvonly attributes 
> cannot be used for preference indications.
>>
>> For the below comments, I'll use 'sign-language' as a token, although 
>> I assume there must actually be many tokens since there are many sign 
>> languages.
>>
>> Other comments inline...
>>
>>
> English, not risking delays and dropouts through interpreters, but 
> feel much more confident in expressing herself in Swahili when she 
> speaks. Therefore she selects that combination and the remote 
> conference is set up so that she get the Swahili interpretation when 
> she talks.
>>> Examples are:
>>>
>>> cannot see it in reception and therefore declare language in video 
>>> only for send video.
>> It will be very clear to the far-end when they see the caller is 
>> blind that they can only see sign language but not send it.  Or if 
>> you want to make it one-way video on the wire, that's what the 
>> 'a=sendonly' is for. (same goes for text media line)
>>
> It is not good to let the deaf-blind user be connected with a person 
> who has only video enabled.
>>
>>
>>> 2. Hard-of-hearing person who want to talk in audio channel, but 
>>> cannot hear answers , and therefore declare languge for audio only 
>>> in send audio
>> If you literally only want to send audio but not receive, use 
>> 'a=sendonly' for the audio line, and have a text media line.
> sendonly etc.  It is use of the media we are discussing.  Support of 
> the media is another thing, already well covered in both SDP and SIP.
>>   If, however, you mean they want bi-directional audio but a 
>> preference to reach someone who can also do text, or video for 
>> sign-language, send normal audio and text media lines, or with a 
>> 'sign-language' video line.
>>
>> The important thing is that you reach someone who can hear you, and 
>> can type text back to you (or do sign language).
>>
>>
>>> 3. Person with speech disabilities who want to hear in audio 
>>> channel, but cannot use audio for talking
>> The important thing is you reach someone who can talk to you, but 
>> also can read text from you or see your sign language.
>>
>>
>>> 4. Person with speech disabilities who want to hear in audio 
>>> channel, and talks unclearly, so that he want a speech relay service 
>>> to listen to the call and clarify what got hard to understand for 
>>> the other party.
>> I have not looked into how such relay services work, for example 
>> VRS.  It would be good to know how they're used in practice. (I can 
>> imagine several ways they could be done)
> Read
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Mar 2013 22:48:35 +0800

I think you need to distinguish two cases here:

- both ends understand and use the language negotiation mechanism,
   and there is a mismatch between what is desired and what is
   required.

- one end is using this language negotiation mechanism, and has
   expressed certain requirements, but the other end doesn't
   understand and isn't using the mechanism.

In the first case it may make sense to fail the call. In the other case 
it probably does not.

Callerprefs has tried to deal with this, though the mechamism for doing 
so it rather obscure. If there is a desire to deal with this at the SDP 
level then it will take some work to do so.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Mar 2013 22:55:04 +0800

> Where multiple streams are used I would expect any work in this area

I agree here. But we are concerned about this at the RTP stream level 
(more or less - there are terminology issues) where there may be 
multiple RTP streams per m-line. So dealing with this via per-m-line 
attributes will likely not be sufficient.

This is all entangled with the bundling discussion.

It may be prudent to defer general work on this human language signaling 
until some of the current messes regarding bundling and multiple RTP 
streams per RTP session have been resolved.

	Thanks,
	Paul

---

From: Gunnar Hellstrom <[email-masked]>
Date: Mon, 25 Mar 2013 20:43:10 +0100

>   and there is a mismatch between what is desired and what is
Yes,
This could first lead to an effort to route the call to an endpoint that 
has declared more suitable language and modality preferences and 
capabilities.

Secondly it can lead to addition of a relay service or translation 
service if one of the parties has access to such services. It can be 
added in a three-party call fashion, translating languages or modalities 
as needed.
>   understand and isn't using the mechanism.
Yes,
this will sadly be a common case.
The one who use the mechanism need to make assumptions.
One obvious assumption is that audio media capability alone will mean 
capability and preference for spoken language,
So if the other user prefers other media and modalities, there is a need 
for relay services that need to be invoked.
Spoken language interpreting service need will be harder to detect.

If the one who is not using the mechanism is declaring audio and text 
media capabilities, it will be harder to select what to do.
If the one supporting the mechanism also support audio and text, a 
direct connection could be tried, hoping that they can get along with 
either speaking or typing or mixing these modalities as they wish.

If the one who is not using the mechanism is declaring audio, video and 
text media capabilities, and the one supporting the mechanism also 
support these three media, it is also hard to select what to do.
The one supporting the mechanism may prefer to use sign language. Having 
no indication why the other party declares video capability, it may be 
risky to just connect them.
It might be best to include a sign relay service in the call.
But that might be not needed and just disturbing and resource consuming 
if both parties know the same sign languages.

   So, yes, there are many use case variations that need to be captured 
and best approach described.
>
>
> In the first case it may make sense to fail the call. In the other 
> case it probably does not.
>
> Callerprefs has tried to deal with this, though the mechamism for 
> doing so it rather obscure. If there is a desire to deal with this at 
> the SDP level then it will take some work to do so.
Yes, it is tempting to try to reuse the callerprefs mechanism.
I had hoped that the implicit preference evaluation could have included 
capabilities declared in SDP, but it is not. So, right now there is no 
link between the callerpref methods and a new definition is needed of 
how the language and modality capabilities and preference expressions in 
SDP can be evaluated and acted on.

/Gunnar
>>> of the languages the offerer wishes to send and recv-lang is a list 
>>> in preference order of the languages the offerer wishes to receive.  
>> What's the use-case when the two directions are not identical? I.e., 
>> when does it make sense to receive Latin but send Swahili for the 
>> same media?
>> need to think about this very carefully.  Otherwise the outcome would 
>> be SBCs would strip it from the INVITE, just to avoid failing the 
>> call.  I don't think anyone would actually want such calls to truly 
>> fail for the end user - not just for Emergency calls, but for any 
>> calls - people can always hang up if they don't like what they 
>> hear/see.  ISTM that there's a high likelihood of this language value 
>> actually being *wrong* in either the sender or receiver or both, so I 
>> think failing the call because of a mismatch would be really bad.
>>
>> make sense: for a serial-forking proxy/B2BUA/UA to be able to recurse 
>> to alternate targets if the first one didn't support the 
>> begin with, the call fails.  Then we're back to square one above, and 
>> the thing gets removed from all calls by middleboxes, just to avoid 
>> such cases.
>>
>> -hadriel
>> (http://www.ietf.org/proceedings/86/agenda/agenda-86-mmusic), nor in 
>> the meeting materials 
>> (https://datatracker.ietf.org/meeting/86/materials.html), nor is the 
>> draft on the MMUSIC tools page (http://tools.ietf.org/wg/mmusic/).  I 
>> only mention this because I was looking for the slides and draft 
>> today and didn't find them.
>>