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

Paul Kyzivat <> Mon, 25 March 2013 14:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EA03B11E80C5 for <>; Mon, 25 Mar 2013 07:48:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.307
X-Spam-Status: No, score=0.307 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZUIIBY83Rjp3 for <>; Mon, 25 Mar 2013 07:48:36 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:44:76:96:59:243]) by (Postfix) with ESMTP id DC83A11E80B8 for <>; Mon, 25 Mar 2013 07:48:35 -0700 (PDT)
Received: from ([]) by with comcast id Fmxc1l0011YDfWL5DqobjL; Mon, 25 Mar 2013 14:48:35 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id Fqob1l00G3ZTu2S3gqobPT; Mon, 25 Mar 2013 14:48:35 +0000
Message-ID: <>
Date: Mon, 25 Mar 2013 22:48:35 +0800
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20121106; t=1364222915; bh=6tFPSzNFxy9de1dwjjETSyv/LqMgIsepZSpwALHzjws=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Ac5r8n/jG5RsV7LJwx7t7RGzbZhMlqRwj6REKZ0t08rLD+YMBbny43EP1+881A9LW GQNoL7mrsFQuYL/Dm9alr362ddDS+HPgygjw1bMGVlsEtb4cbGDebt3mJXp+3ZzqW4 HKXyNu7pMjPqOKI5nXsWQ2ctqfQ3Rh6iquGHffabNV8v4yc2/ELaYztp30aNdI5z6+ IlWsE+86SV05Qll7eTO5NtG1hxryb7+6RKB0i+luwrUsXOJ+Hn/Ps0iTFioiamoyeB UlbRnNGjDogVBqHF4S5Wp4brotDVzeilj67KndZJYwp6Nt6H1ujVOpS1HCkru9t5Vh 4Xsr7pw5g5m/A==
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: Mon, 25 Mar 2013 14:48:37 -0000

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

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


On 3/17/13 3:54 AM, Hadriel Kaplan wrote:
> On Mar 15, 2013, at 2:49 PM, Randall Gellens <> 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 (, nor in the meeting materials (, nor is the draft on the MMUSIC tools page (  I only mention this because I was looking for the slides and draft today and didn't find them.
> _______________________________________________
> mmusic mailing list