Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-language-01.txt - more use cases

Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> Mon, 15 July 2013 06:40 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 5F18121F9C78 for <mmusic@ietfa.amsl.com>; Sun, 14 Jul 2013 23:40:37 -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 Gq9WH55FV+jB for <mmusic@ietfa.amsl.com>; Sun, 14 Jul 2013 23:40:32 -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 6B52821F9C0C for <mmusic@ietf.org>; Sun, 14 Jul 2013 23:40:30 -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, 15 Jul 2013 08:40:20 +0200 (CEST)
Received: from [192.168.43.175] (109.58.145.97.bredband.tre.se [109.58.145.97]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-03-01.atm.binero.net (Postfix) with ESMTPA id 94C0A3A032 for <mmusic@ietf.org>; Mon, 15 Jul 2013 08:40:20 +0200 (CEST)
Message-ID: <51E39957.3080004@omnitor.se>
Date: Mon, 15 Jul 2013 08:40:23 +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: <p0624061acd691d9b38bc@dhcp-42ec.meeting.ietf.org> <B0295A41-BF2B-4520-8495-7A88B4803F30@acmepacket.com> <5144E4E5.4030801@omnitor.se> <03559DEF-E442-4118-A616-8D7E42D1F22A@acmepacket.com> <5145729C.6030905@omnitor.se> <514FE5A9.3060900@nteczone.com> <p06240615cdfea836f364@[99.111.97.136]> <51DBB813.4060607@nteczone.com> <p0624060ece02360a322d@[99.111.97.136]> <51DC9B66.6090302@omnitor.se> <51DCE7CB.7080205@nteczone.com> <p06240603ce06ba958db4@[10.121.65.51]> <51E196B0.5080406@omnitor.se> <51E35A53.5030502@nteczone.com>
In-Reply-To: <51E35A53.5030502@nteczone.com>
Content-Type: multipart/alternative; boundary="------------070009030701040206060904"
Subject: Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-language-01.txt - more use cases
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, 15 Jul 2013 06:40:37 -0000

I suggest to add a couple of use cases.


4.x.  Deaf French sign language user calling another deaf French sign language user.

Someone who mainly uses French sign language (FSL) places a call.
The call offers a video stream listing FSL in both directions with highest preference and also
real-time text stream on low preference level for French in both directions.
Audio is also included but without language indications.
The call destination turns out to be another user of FSL with the same media and language settings.
The called client can find that the language preferences match, so the same language indications are
sent in the SDP answer, and the call can be connected without connection of any relay service.
The users can sign directly with each other in the video streams, and occasionally use the real-time
text streams for data that need exact spelling or noted.


4.y.  Spoken Japanese user calling a Spanish speaking person.

Someone who speaks Japanese and is subscriber of an on-line interpreting service places a call.
The call offers audio streams using Japanese in both directions on high preference level, video
with spoken Japanese with no specific preference and both message-wise and real-time text in
Japanese in both directions.
This user is customer of an on-line interpreting service. The service adds its interpreting
language capabilities to the SDP on lower level than the originator, and conveys the call to the destination.
The destination is a Spanish speaking person. The called terminal detects that Spanish is among the possible
languages even if not highest preference, so that call is answered with indication of spoken Spanish at high
priority level and Spanish text messaging in both directions at low priority level.
The on-line interpreting service detects that their translation between Japanese and Spanish is needed to
make the call work, so they allocate an interpreter to the call, and answers the call with an indication
of Japanese towards the caller.
Information that the call will be soon supported by a Japanese/Spanish interpreter is provided in the
appropriate languages in the text message connections.
The users can communicate in their own languages supported by the interpreter.


-------------------------------
More might be needed to clarify some more of the endless possible variations and benefit.





------------------------------------------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46708204288
On 2013-07-15 04:11, Christian Groves wrote:
> Hello Randall and Gunnar,
>
> I think Randall's clarification would be good to have in the draft. I 
> think that when a caller support the language it is sent for every 
> call. Whether the language is used by a receiver depends on the 
> receiver's local capability.
>
>
> Regards, Christian
>
>
> On 14/07/2013 4:04 AM, Gunnar Hellstrom wrote:
>> On 2013-07-13 10:07, Randall Gellens wrote:
>>> At 2:49 PM +1000 7/10/13, Christian Groves wrote:
>>>
>>>>  I wouldn't have thought that it would be use case specific... i.e. 
>>>> i'd only include my language when I called an emergency service. I 
>>>> would think an endpoint would be configured with the information 
>>>> and then provide it whenever I made a call. Is that the intent?
>>>
>>> I expect so, but then, I also didn't expect it to be used much in 
>>> the person-to-person case since usually language is implied by 
>>> context when calling an individual.  I expect it to be used when a 
>>> person is calling an call center (corporate or emergency).  To put 
>>> it another way, I expect a personal client to always set language on 
>>> outbound calls, but in most cases to ignore it on inbound calls.  
>>> I'd expect a corporate call center, as well as emergency call 
>>> handling facilities, to pay attention.  I should make this more 
>>> clear in the draft.
>>>
>> I expect the setting to be retrieved from a personal profile (likely 
>> but not necessarily stored in connection with other user information 
>> and account information) and used in every call.
>>
>> /Gunnar
>> _______________________________________________
>> 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