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

Gunnar Hellstrom <> Sun, 12 May 2013 21:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4266321F8C9B for <>; Sun, 12 May 2013 14:20:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PMTGjf+6rF7d for <>; Sun, 12 May 2013 14:20:08 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 49EE321F8C40 for <>; Sun, 12 May 2013 14:20:05 -0700 (PDT)
Received: from (unknown []) by (Halon Mail Gateway) with ESMTP for <>; Sun, 12 May 2013 23:19:53 +0200 (CEST)
Received: from [] ( []) (Authenticated sender: by (Postfix) with ESMTPA id 5C6453A00B for <>; Sun, 12 May 2013 23:19:53 +0200 (CEST)
Message-ID: <>
Date: Sun, 12 May 2013 23:19:56 +0200
From: Gunnar Hellstrom <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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, 12 May 2013 21:20:13 -0000

Did we get to any workable conclusions on this?


On 2013-03-25 20:43, Gunnar Hellstrom wrote:
> On 2013-03-25 15:48, Paul Kyzivat wrote:
>> 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
>>   required.
> Yes,
> This could first lead to an effort to route the call to an endpoint 
> that has declared more suitable language and modality preferences and 
> capabilities.
> Secondly it can lead to addition of a relay service or translation 
> service if one of the parties has access to such services. It can be 
> added in a three-party call fashion, translating languages or 
> modalities as needed.
>> - 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.
> Yes,
> this will sadly be a common case.
> The one who use the mechanism need to make assumptions.
> One obvious assumption is that audio media capability alone will mean 
> capability and preference for spoken language,
> So if the other user prefers other media and modalities, there is a 
> need for relay services that need to be invoked.
> Spoken language interpreting service need will be harder to detect.
> If the one who is not using the mechanism is declaring audio and text 
> media capabilities, it will be harder to select what to do.
> If the one supporting the mechanism also support audio and text, a 
> direct connection could be tried, hoping that they can get along with 
> either speaking or typing or mixing these modalities as they wish.
> If the one who is not using the mechanism is declaring audio, video 
> and text media capabilities, and the one supporting the mechanism also 
> support these three media, it is also hard to select what to do.
> The one supporting the mechanism may prefer to use sign language. 
> Having no indication why the other party declares video capability, it 
> may be risky to just connect them.
> It might be best to include a sign relay service in the call.
> But that might be not needed and just disturbing and resource 
> consuming if both parties know the same sign languages.
>   So, yes, there are many use case variations that need to be captured 
> and best approach described.
>> 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.
> Yes, it is tempting to try to reuse the callerprefs mechanism.
> I had hoped that the implicit preference evaluation could have 
> included capabilities declared in SDP, but it is not. So, right now 
> there is no link between the callerpref methods and a new definition 
> is needed of how the language and modality capabilities and preference 
> expressions in SDP can be evaluated and acted on.
> /Gunnar
>>     Thanks,
>>     Paul
>> 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
>> _______________________________________________
>> mmusic mailing list
> _______________________________________________
> mmusic mailing list