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

[Gunnar Hellstrom <[e-mail]>]

Randall,
In my view the draft aims at solving the difference between the 
user-to-user call with known similar context and the situation when the 
user-to-user call has dissimilar contexts and need support.

The call center gets invoked because of the difference between the users 
in order to fill the gap.

Of course there are other situations where it can be useful, but this is 
the main application that I see.

In USA, it is called to dial-around, when the users are connected 
without connection of an assisting service, and use of relay service 
when assistance is needed and invoked.
In Sweden we call the concept Call-direct.
The function is mentioned and demonstrated a number of times 
Internationally, and this is an opportunity to get proper standardized 
support for it.

Users interested in this service will have the language settings. It is 
very valid to do the comparison between the users and invoke services if 
needed.
For users who have not set the language indicators, there will need to 
be a place for assumptions in the evaluation logic.


And. Most important, I think we should follow Christian's advice to get 
a way to include language indications specified here, and the ways to 
use it specified in other specifications.

But in order to get the indications useful, we must settle some use 
cases. So there we have a risk of including assumptions of how the 
indications can be used.

Gunnar






------------------------------------------------------------------------
Gunnar Hellström
Omnitor
[e-mail]
[phone]
On 2013-07-18 18:21, Randall Gellens wrote:
> Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-langua
> Hi Gunnar,
>
> I am concerned that getting into person-to-person usage will overly 
> complicate the draft with no real-world benefit, since 
> person-to-person communication has context and implied language/media, 
> as stated in the draft.  The draft is trying to solve a more focused 
> real-world problem where there is no context.
>
> At 8:40 AM +0200 7/15/13, Gunnar Hellstrom wrote:
>
>> 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 Hellstrs(m
>> Omnitor
>> [e-mail] <mailto:[e-mail]>
>> [phone]
>> 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
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>
>
> -- 
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for myself only
> -------------- Randomly selected tag: ---------------
> If you make people think they're thinking, they'll love you; but if you
> really make them think they'll hate you.