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

Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> Tue, 09 July 2013 07:58 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 9F00E21F9DAB for <mmusic@ietfa.amsl.com>; Tue, 9 Jul 2013 00:58:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 U-9o-dpVi6Uh for <mmusic@ietfa.amsl.com>; Tue, 9 Jul 2013 00:58:34 -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 C570A21F9DA6 for <mmusic@ietf.org>; Tue, 9 Jul 2013 00:58:27 -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>; Tue, 9 Jul 2013 09:58:19 +0200 (CEST)
Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-05-01.atm.binero.net (Postfix) with ESMTPA id ADADE3A0DA for <mmusic@ietf.org>; Tue, 9 Jul 2013 09:58:19 +0200 (CEST)
Message-ID: <51DBC29C.9030200@omnitor.se>
Date: Tue, 09 Jul 2013 09:58:20 +0200
From: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: mmusic@ietf.org
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>
In-Reply-To: <BLU169-W1392BC759582397692F5AAA93790@phx.gbl>
Content-Type: multipart/alternative; boundary="------------060707010607050006050004"
Subject: Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-language-00.txt - preferences between media
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 07:58:39 -0000

On 2013-07-09 08:56, 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.
<GH>And the humintlang specification allows that if the requirement to 
have symmetric specifications per media is deleted ( as described in 
another mail ).

But there is also a need for absolute preference. Or relative order of 
preference between media.

It is easy to use a sign language example fort that situation.

A person prefers to use British sign language in both directions but is 
capable with some reluctance to use English text. That is natural. Text 
is always slower and less expressive than sign language or spoken language.

A call goes to a call center that declared spoken English and English 
text in both directions.
The result can be a direct connection using English text, or invocation 
of a sign relay service translating between British sign language and 
spoken English.

An ability to declare that the British sign language is preferred over 
the English text would result in the invocation of the sign relay 
service and make both sides happy with a call with good flow.

Without the relative preference between media, the call will likely 
result in the direct text communication that will work but with less 
satisfaction.

This can be solved either by an absolute preference indication  : 
British sing language *preferred*  , English text *managed*
Or by some order of preference between the media;  video *preferred* 
text *managed*

I think an absolute preference indication is easiest to handle. Media 
preference will collide with relative preference between languages in 
each medium.

I suggest that that is introduced with some suitable coding.

/Gunnar Hellström

>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic