Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-language-00.txt - asymmetric preferences

Randall Gellens <randy@qti.qualcomm.com> Tue, 09 July 2013 21:52 UTC

Return-Path: <randy@qti.qualcomm.com>
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 B7FCB11E8171 for <mmusic@ietfa.amsl.com>; Tue, 9 Jul 2013 14:52:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 1NmM62AmSVG2 for <mmusic@ietfa.amsl.com>; Tue, 9 Jul 2013 14:52:10 -0700 (PDT)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE2611E8164 for <mmusic@ietf.org>; Tue, 9 Jul 2013 14:52:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1373406726; x=1404942726; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=YnEbtbgEtIhBd5F9dsFF/HT36nIOOw91+NgSVQfTcuU=; b=LZJDaK1y79QN0VO1qDU258MDHRUFjEwbYtn16WmDT5o9bip2M6PxR8rm y4LP4/3++Vz0eQYbRn30El9/Ou4E8EQLDKkDF5bzoGDrb/Bj49SV7a1or 5vB+Dr6P45lQqL+QU1EnkQcw/3F80HcrlGA5tp4Dyb5Nnw2HZOdaUk855 A=;
X-IronPort-AV: E=Sophos;i="4.87,1030,1363158000"; d="scan'208";a="47185513"
Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth02.qualcomm.com with ESMTP; 09 Jul 2013 14:52:03 -0700
X-IronPort-AV: E=Sophos;i="4.87,1030,1363158000"; d="scan'208";a="502264979"
Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 09 Jul 2013 14:52:03 -0700
Received: from [99.111.97.136] (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 9 Jul 2013 14:52:02 -0700
Message-ID: <p0624060dce023473d2e3@[99.111.97.136]>
In-Reply-To: <BLU169-W1392BC759582397692F5AAA93790@phx.gbl>
References: <20130707223940.32193.45404.idtracker@ietfa.amsl.com>, <51DA8FA6.4060705@omnitor.se>, <p0624060ece011b92fdac@[99.111.97.136]>, <51DBA497.6050400@omnitor.se> <BLU169-W1392BC759582397692F5AAA93790@phx.gbl>
X-Mailer: Eudora for Mac OS X
Date: Tue, 09 Jul 2013 14:48:30 -0700
To: Bernard Aboba <bernard_aboba@hotmail.com>, Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
From: Randall Gellens <randy@qti.qualcomm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Originating-IP: [172.30.48.1]
Cc: "mmusic (E-mail)" <mmusic@ietf.org>
Subject: Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-language-00.txt - asymmetric preferences
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: Tue, 09 Jul 2013 21:52:14 -0000

At 11:56 PM -0700 7/8/13, Bernard Aboba wrote:

>
>
>>  This is very similar to the use case included of a user who can 
>> hear English but not speak; an audio and text stream are set up, 
>> both using English.  The point of negotiating language is to get 
>> the call to a callee who can communicate with the caller (e.g., a 
>> PSAP and call taker who understand at least one language in common 
>> with the caller).  The point is not to fully specify exactly how 
>> the media will be used; there is no need to do so and it won't 
>> help get the call to the right callee, but will make things much 
>> more complex.
>>
>>  It is simpler and more robust to handle cases such as you describe 
>> and the one in the document now by negotiating the needed media as 
>> two-way streams.
>>
>  [BA]  I think this example points out the limitations of a call 
> routing approach that relies solely on language. In this case, it 
> is important for the "hint" to cause the call to be routed to an 
> endpoint that can handle text media, since otherwise the caller 
> will not be able to communicate.  Since both the audio and text 
> media are set up using English in both directions, one might 
> conclude that the "hint" need only express the language preference 
> (English), but that would not be sufficient to get a satisfactory 
> result.  What needs to be expressed in the "hint" is *both* a 
> preference for English and a requirement for text media support.

[RG] In the case of emergency calls, policy based routing can look at 
media needs and with the proposal to include language in SDP, also 
language.  So for emergency calls, there is no need for a SIP "hint." 
The SIP "hint" is in the current draft because at the Orlando 
discussion it was suggested as a way to allow non-emergency calling 
facilities that lack the ability to examine SDP when determining call 
handling.  I agree that it isn't sufficient if the caller requests 
non-audio media.  I think currently, corporate call centers usually 
have a dedicated number for text communications, while for audio they 
resort to "press 1 for <default language>, 2 for <alternate language 
1>, ..." approaches.  So having just language in the hint would map 
to current usage.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
This is not a novel to be tossed aside lightly.  It should
be thrown with great force.               --Dorothy Parker