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

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

On 3/17/13 3:54 AM, Hadriel Kaplan wrote:
>
> On Mar 15, 2013, at 2:49 PM, Randall Gellens <randy@qti.qualcomm.com> 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
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>