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

From: Gunnar Hellstrom <[email-masked]>
Date: Sun, 12 May 2013 23:19:56 +0200

Did we get to any workable conclusions on this?

/Gunnar

On 2013-03-25 20:43, Gunnar Hellstrom wrote:
> On 2013-03-25 15:48, Paul Kyzivat wrote:
>> 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.
> 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.
>>
>> - 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.
> 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
>>     Thanks,
>>     Paul
>>
>> On 3/17/13 3:54 AM, Hadriel Kaplan wrote:
>>>
>>> On Mar 15, 2013, at 2:49 PM, Randall Gellens 
>>> <[email-masked]> wrote:
>>>
>>>> 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
>>>
>>> Another reason not to only put it in SDP is the delayed-offer scenario.
>>>
>>>
>>>> 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).
>>>
>>> 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.
>>>
>>>
>>>> Advisory vs Required:
>>>> - 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.
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>
>> _______________________________________________
>> mmusic mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mmusic
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 13 May 2013 14:09:28 -0700

Gunnar said: 
> 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.
[BA] The call routing aspect is probably best handled via SIP headers, just as in RFC 6442 we define the Geolocation and Geolocation-Routing Headers.   
> added in a three-party call fashion, translating languages or modalities 
> as needed.
[BA] The SIP headers might lead to the call being routed to an endpoint that supports the desired servicesnatively, or it might not.  The O/A exchange will disclose whether the desired services are available, or not. It could be that an entity indicating a language capability in its Answer might have them available on site, ormight have to call out to obtain them, but that doesn't matter to the Offerer as long as they can be deliveredby the Answerer.  On the other hand, if the Answerer doesn't have the required services, the Offerer mightdecide to add them on its own, by making another call to a relay or translation service, possibly joining thatcall to the initial one. 
> 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.
[BA] I agree. Just because a party declares capabilities doesn't necessarily mean that they are able to use them in the manner that is needed.  Just from an indication of the supported media (e.g. video, text, audio) you won't know if the Answerer supports ASL interpretation, or whether they're trained and willing to transcribe audio to text and back. So it's probably best if support for these services is made explicit. 
> and best approach described.

[BA] It seems to me that what is needed is a set of tools that can be combined in different ways to address the different use cases.  The tools can include SIP headers, SDP negotiation, and call control functionality.  Once you have the tools, you can describe how different use cases can be addressed using them.