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

From: Christian Groves <[email-masked]>
Date: Tue, 09 Jul 2013 17:13:23 +1000

Hello Randall,

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).

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?

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?

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?

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).
>

---

From: Randall Gellens <[email-masked]>
Date: Tue, 9 Jul 2013 14:58:28 -0700

Hi Christian,

Thanks for the review and comments.

At 5:13 PM +1000 7/9/13, Christian Groves wrote:

> 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.

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).

>  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?

>
>  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.

>
>  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
>
>>>   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,
>>
>> 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
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/mmusic

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Not a shred of evidence exists in favor of the idea that
life is serious.                          --Brendan Gill