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

Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> Sun, 12 May 2013 21:20 UTC

Return-Path: <gunnar.hellstrom@omnitor.se>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4266321F8C9B for <mmusic@ietfa.amsl.com>; Sun, 12 May 2013 14:20:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMTGjf+6rF7d for <mmusic@ietfa.amsl.com>; Sun, 12 May 2013 14:20:08 -0700 (PDT)
Received: from vsp-authed-03-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 49EE321F8C40 for <mmusic@ietf.org>; Sun, 12 May 2013 14:20:05 -0700 (PDT)
Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-03-02.binero.net (Halon Mail Gateway) with ESMTP for <mmusic@ietf.org>; Sun, 12 May 2013 23:19:53 +0200 (CEST)
Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-01-01.atm.binero.net (Postfix) with ESMTPA id 5C6453A00B for <mmusic@ietf.org>; Sun, 12 May 2013 23:19:53 +0200 (CEST)
Message-ID: <5190077C.9010009@omnitor.se>
Date: Sun, 12 May 2013 23:19:56 +0200
From: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: mmusic@ietf.org
References: <p0624061acd691d9b38bc@dhcp-42ec.meeting.ietf.org> <B0295A41-BF2B-4520-8495-7A88B4803F30@acmepacket.com> <515063C3.3040700@alum.mit.edu> <5150A8CE.1030504@omnitor.se>
In-Reply-To: <5150A8CE.1030504@omnitor.se>
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-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 12 May 2013 21:20:13 -0000

Did we get to any workable conclusions on this?

/Gunnar

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 
>>> <randy@qti.qualcomm.com> 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 
>>> (http://www.ietf.org/proceedings/86/agenda/agenda-86-mmusic), nor in 
>>> the meeting materials 
>>> (https://datatracker.ietf.org/meeting/86/materials.html), nor is the 
>>> draft on the MMUSIC tools page (http://tools.ietf.org/wg/mmusic/).  
>>> I only mention this because I was looking for the slides and draft 
>>> today and didn't find them.
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic