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

[Gunnar Hellstrom <[e-mail]>]

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 
>>> <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic