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

[Randall Gellens <[e-mail]>]

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.

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


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