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

Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> Mon, 25 March 2013 19:43 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 CC8E921F9507 for <mmusic@ietfa.amsl.com>; Mon, 25 Mar 2013 12:43:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.149
X-Spam-Level:
X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=1.450, 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 yH105Zz+Oj7H for <mmusic@ietfa.amsl.com>; Mon, 25 Mar 2013 12:43:17 -0700 (PDT)
Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id ED8CE21F9421 for <mmusic@ietf.org>; Mon, 25 Mar 2013 12:43:16 -0700 (PDT)
Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP for <mmusic@ietf.org>; Mon, 25 Mar 2013 20:43:08 +0100 (CET)
Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-10-01.atm.binero.net (Postfix) with ESMTPA id EAEE63A141 for <mmusic@ietf.org>; Mon, 25 Mar 2013 20:43:07 +0100 (CET)
Message-ID: <5150A8CE.1030504@omnitor.se>
Date: Mon, 25 Mar 2013 20:43:10 +0100
From: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
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>
In-Reply-To: <515063C3.3040700@alum.mit.edu>
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: Mon, 25 Mar 2013 19:43:18 -0000

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