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

[Christian Groves <[e-mail]>]

Hello Randall,

Please see my response below.

Regards, Christian

On 10/07/2013 7:58 AM, Randall Gellens wrote:
> Hi Christian,
>
> Thanks for the review and comments.
>
>
> At 5:13 PM +1000 7/9/13, Christian Groves wrote:
>
>>  I had a look at the draft with respect to CLUE. The main difference 
>> between the CLUE usage of language and what is being proposed is the 
>> ability for the sender to specify sending AND receiving preferences. 
>> The current CLUE model is that an each endpoint Advertises what it 
>> can do and then each consumer chooses from this list. This could 
>> still result in an asymmetric usage of language (just negotiated 
>> differently).
>
> The draft doesn't try to accommodate asymmetric usage, since that 
> usually can just happen without detailed technical backing.  The 
> "-send" and "-receive" attributes are there because Harald warned that 
> we'd be violating SDP otherwise.
[CNG] By asymmetric I mean that a different language could be used in 
the send and receive sections. Are you saying that the draft assumes the 
same language in the "-send" and "-receive" attributes?
>
> If CLUE can allow the caller to indicate in the offer language needs 
> for each stream, this to be taken into accounting in policy bvased 
> routing, and the callee to respond to the offer with a language in 
> common, then perhaps we don't need this proposal at all and can just 
> drop it in favor of CLUE.  I admit at this point I am ignorant of CLUE 
> (yes, clueless about CLUE).

[CNG] I think you still want your proposal. Endpoints shouldn't be 
compelled to use CLUE to indicate a language preference. The first CLUE 
advertisement will most likely come after the initial SIP SDP Offer so 
it would be difficult to route the call based on CLUE language information.
I'm still trying to understand what the relationship/mapping would be 
between the language specified as a SIP "hint", to the SDP "-send" and 
"-receive" attributes in an Initial SDP Offer to any subsequent CLUE 
signalling that includes a language tag.
For example: If an endpoint sends an initial SIP (with 'hint' with SDP 
Offer with a set of languages for a single media (and indicates CLUE 
support). Should the endpoint when sending a CLUE Advertisement only 
advertise captures that contain the negotiated languages? (Seeing "the 
hint" is at the call level) Or, should it treat any media described by 
CLUE as something completely new?

>
>
>>  You may need to consider the case where there are multiple streams 
>> of the same media type with different languages. e.g. an audio 
>> conference where one stream is the main audio of the conference and 
>> there's a second stream with a translation/s. This is the type of 
>> thing CLUE is considering. I'm not sure how this fits in with your work?
>
> This is a different, and more complex, scenario than what this 
> proposal is trying to solve.  This proposal is focused on simpler 
> cases where someone places an emergency call or calls a corporate call 
> center.  Possibly this can be just a simple case of the more complex 
> cases?

[CNG] I don't think this is a problem for the SDP attributes, I think 
the issue is more for the SIP "hint" if it is media type specific. For 
example if you set "LANG1" and "LANG2" against "audio" and you actually 
have two streams one of LANG1 and another of LANG2 and base your routing 
decision on this there is a chance that you route to an endpoint based 
on LANG2 but when the endpoint inspects the SDP it actually wants the 
LANG1 stream.

>
>>
>>  Some other comments:
>>
>>  With regards to the SIP "hint" it wasn't clear to me how this 
>> matches the languages in "humintlang-send" and "humintlang-recv". Is 
>> it planned that both will be supported in the header?
>
> I suppose this depends on if the "-send" and "-recv" are really 
> needed, and if so if they should be the same.

[CNG] OK I didn't understand that from the draft.

>
>>
>>  The "TBD" paragraph in 7.3 SIP "hint" mentions (where the caller 
>> sets media and language) but in the final paragraph of the 7.3 it 
>> sounds like the "hint" is only for audio?
>
> Good catch -- this will need to be sorted out.
>
>>
>>  7.4 Silly states - How do the language sub-tags come into play here? 
>> For example: the endpoint might specify a language for an audio 
>> stream which may be valid. If the endpoint also specified a sub-tag 
>> with "script" I guess it makes it a silly state?
>>
>>  Regards, Christian
>>
>>  On 8/07/2013 8:40 AM, Randall Gellens wrote:
>>>  At 4:50 PM +1100 3/25/13, Christian Groves wrote:
>>>
>>>>   Hello,
>>>>
>>>>   One thing that doesn't seem to be noted is an overlap with the 
>>>> work of the CLUE WG. There has been some discussion in the CLUE 
>>>> working group about adding attributes to captures to describe the 
>>>> language, whether sub-titles are used, whether a stream comes from 
>>>> an interpreter, etc. Where multiple streams are used I would expect 
>>>> any work in this area should be aligned.
>>>>
>>>>   Regards, Christian
>>>
>>>  Hi Christian,
>>>
>>>  Thanks for the info.  Would it make sense to talk about this in 
>>> Berlin?  I agree that if there is overlap in the approaches we 
>>> should align them.
>>>
>>>  Also, I have an updated draft that was just uploaded.  It is now 
>>> named 'draft-gellens-mmusic-negotiating-human-language-00' (adding 
>>> -mmusic and hence reverting back to -00).
>>>
>>
>>  _______________________________________________
>>  mmusic mailing list
>>  [e-mail]
>>  https://www.ietf.org/mailman/listinfo/mmusic
>
>