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

[Gunnar Hellstrom <[e-mail]>]

On 2013-07-19 03:08, Christian Groves wrote:
> Hello Randall,
>
> I think you're mixing protocol functionality with application.
>
> From a protocol perspective I think that all you need to say is 
> something like:
>
> Clients that have a language preference related to a media stream/s 
> shall set the 'humintlang-send' and/or 'humintlang-recv' attribute on 
> the applicable media stream at session establishment. Receivers of the 
> 'humanintlang-*" attributes may then apply session handling based on 
> the received language/s and according to local policy. For example: 
> Call centers and PSAPs may route the session to an operator that is 
> capable of communicating in the preferred language/s.
>
> I think this describes the protocol behaviour without requiring 
> behaviour depending on user type.
Yes, this looks better.
With this wording, I see a risk that the answering part does not realize 
that they shall also send the attributes. So, I suggest to add "both 
when offering and answering" in the first sentence.
With that, and a couple of other small changes, the paragraph could be:

"Clients that have a language preference related to media stream/s shall 
set the 'humintlang-send' and/or 'humintlang-recv' attribute on the 
applicable media stream/s at session establishment both when offering 
and answering. Receivers of the 'humanintlang-*" attributes may apply 
session handling based on the received language preferences and 
according to local policy. For example: Call centers and PSAPs may route 
the session to an operator that is capable of communicating in the 
preferred language/s ."


/Gunnar




>
> Regards, Christian
>
> On 19/07/2013 2:14 AM, Randall Gellens wrote:
>> Hi Christian,
>>
>> How about this text:
>>
>>    Clients acting on behalf of end users are expected to set one or both
>>    'humintlang-send' and 'humintlang-recv' attributes on each media
>>    stream primarily intended for human communication in an offer when
>>    placing an outgoing session, but either ignore or take into
>>    consideration the attributes when receiving incoming calls, based on
>>    local configuration and capabilities.  Systems acting on behalf of
>>    call centers and PSAPs are expected to take into account the values
>>    when processing inbound calls.
>>
>>
>> At 12:11 PM +1000 7/15/13, 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]
>>>>  https://www.ietf.org/mailman/listinfo/mmusic
>>>>
>>>
>>>  _______________________________________________
>>>  mmusic mailing list
>>>  [e-mail]
>>>  https://www.ietf.org/mailman/listinfo/mmusic
>>
>>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic