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

[Randall Gellens <[e-mail]>]

At 1:03 AM +0000 3/17/13, Hadriel Kaplan wrote:

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

I don't want to put words in Harald's mouth, but my recollection is 
that he specifically mentioned the "in practice" as being an abuse.

>   For example: the 'a=inactive' attribute.  It's not inactive for a 
> specific direction, it's inactive for both directions.

That makes sense, and personally I'm in favor of keeping things as 
simple as possible.  But I also don't want to be accused of fomenting 
further misuse of SDP :-)

>>  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"? ;)

The preference is not mandatory (if it was, it wouldn't be a 
preference, it would be a demand).  The preference indicates if the 
caller wants the callee to treat language as mandatory versus 
advisory.

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

If this is really what is wanted, it is quicker if the call fails 
during setup rather than going through full setup, possible queues 
(remember, a major use case is calling call centers), attempting to 
speak to a representative, and then hanging up in frustration.

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

I am also concerned about introducing features where it is not 
obvious what the client should do.  I can see obvious ways for a 
client to make a reasonable default language choice, and ways to 
allow the user to configure it.  It's harder to see how a client 
knows if the advisory token should be set to fail or proceed.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
The fetters imposed on liberty at home have ever been forged out of the
weapons provided for defence against real, pretended, or imaginary
dangers from abroad.
        --James Madison, 4th US president (1751-1836)