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

[Randall Gellens <[e-mail]>]

At 7:54 PM +0000 3/16/13, 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.

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.

>   > 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.

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.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- 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