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

[Hadriel Kaplan <[e-mail]>]

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

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

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