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

Randall Gellens <> Sun, 17 March 2013 19:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B2BC421F8B74 for <>; Sun, 17 Mar 2013 12:43:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.374
X-Spam-Status: No, score=-106.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6N2PIGbwX3sQ for <>; Sun, 17 Mar 2013 12:43:32 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7E16321F8AA0 for <>; Sun, 17 Mar 2013 12:43:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=qcdkim; t=1363549412; x=1395085412; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=mYnNlDOWxw0ldCnuibzZV0tkj6lp2cNygXYTYThyx2E=; b=ABK+tI29QBCgVP7lKBKt8uNJvGjhD5n/WkSFIH0d8eBAcfntnjEYMBbC Y2ie9PCrQY3YDubyBX4MHCzLMTQe4vJooaFoF3BJV8NspKSQ8rMqa1n38 9QogQZfsN6SO0TOOMIzrkD1fe4IoTU138apOHIVRvt93faKrY4zEUEUnG U=;
X-IronPort-AV: E=Sophos;i="4.84,860,1355126400"; d="scan'208";a="30395716"
Received: from ([]) by with ESMTP; 17 Mar 2013 12:43:31 -0700
X-IronPort-AV: E=Sophos;i="4.84,860,1355126400"; d="scan'208";a="443843191"
Received: from ([]) by with ESMTP/TLS/RC4-SHA; 17 Mar 2013 12:43:31 -0700
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 14.2.318.4; Sun, 17 Mar 2013 12:43:31 -0700
Message-ID: <p06240600cd6bc8856061@[]>
In-Reply-To: <>
References: <> <> <> <>
X-Mailer: Eudora for Mac OS X
Date: Sun, 17 Mar 2013 12:36:22 -0700
To: Hadriel Kaplan <>
From: Randall Gellens <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Originating-IP: []
Cc: Randall Gellens <>, "" <>, "" <>
Subject: Re: [MMUSIC] Notes from Orlando human language draft discussion
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 17 Mar 2013 19:43:34 -0000

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

>  On Mar 16, 2013, at 5:54 PM, Randall Gellens <> 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 

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