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

Christian Groves <> Tue, 09 July 2013 07:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EA02D21F9F6F; Tue, 9 Jul 2013 00:13:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d2QFhiFZLtxR; Tue, 9 Jul 2013 00:13:29 -0700 (PDT)
Received: from ( [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by (Postfix) with ESMTP id E7BE821F9F34; Tue, 9 Jul 2013 00:13:28 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApMBAHe321F20QPz/2dsb2JhbAANTcITgneBM4MXAQEBBDgbFRABEAsOCgkWDwkDAgECAUUGDQEHAQGuXpI+j2sHg3ADrD4
Received: from (HELO []) ([]) by with ESMTP; 09 Jul 2013 16:43:27 +0930
Message-ID: <>
Date: Tue, 09 Jul 2013 17:13:23 +1000
From: Christian Groves <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Randall Gellens <>
References: <> <> <> <> <> <> <p06240615cdfea836f364@[]>
In-Reply-To: <p06240615cdfea836f364@[]>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "" <>,
Subject: Re: [MMUSIC] Notes from Orlando human language draft discussion
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Jul 2013 07:13:30 -0000

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