Subject: [clue] Capture Attribute Discussion: 4.3. Language

From: Christian Groves <[email-masked]>
Date: Thu, 13 Dec 2012 14:42:03 +1100

Hello

The language attribute is described in draft-groves-clue-capture-attr:

"4.3.   Language

    As indicated in the discussion in section 2 captures may be offered
    in different languages in case of multi-lingual and/or accessible
    conferences.  It is important to allow the remote end to distinguish
    between them.  It is noted that SDP already contains a language
    attribute however this may not be available at the time that an
    initial CLUE message is sent.  Therefore a language attribute is
    proposed for CLUE.

    This indicates which language is associated with the capture. For
    example: it may provide a language associated with an audio capture
    or a language associated with a video capture when sign
    interpretation or text is used.  The possible values for a language
    tag are the values of the 'Subtag' column for the "Type: language"
    entries in the "Language Subtag Registry" defined in [RFC5646]"

Are there any concerns about adding a language attribute to the framework?

Regards, Christian

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 13 Dec 2012 08:01:29 +0100

Hi,

You will need to have a possibility to have multiple language values to 
a capture.

An example is a video with one sign language, and embedded text in a 
written language.
( I have not followed the discussion, so I do not know if you can have a 
language attribute to the text attribute. )

Another example is audio from the main speaker in a physical conference. 
The speaker may switch, and thereby the audio language in the main audio 
capture. ( the speech may be made understandable by embedded text 
translation in the video capture )

Gunnar

___________________________________________________
Gunnar Hellström
Omnitor
[email-masked]
+46708204288

On 2012-12-13 04:42, Christian Groves wrote:
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 13 Dec 2012 18:06:55 +0100

There have been discussions elsewhere about the difference between supported language and preferred language. The text here should at least be clear as to which is meant.

I assume multiple values of this can be associated with any capture.

I'll have to think some more about duplicate usage with SDP.

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Christian Groves
> Sent: 13 December 2012 03:42
> To: [email-masked]
> Subject: [clue] Capture Attribute Discussion: 4.3. Language
> 
> Hello
>

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 13 Dec 2012 23:49:05 +0100

> There have been discussions elsewhere about the difference between supported language and preferred language. The text here should at least be clear as to which is meant.
My first thoughts on an answer to yur question was this:
Since the attribute is linked to a capture, I would think that it means 
a possible content language in the capture.
That is neither preferred nor supported. Such concept are for a receiver.
If multiple values appear, it means that the contents can vary between 
the specified alternatives.

But second thought:
That simple description does not always match what the participants want 
to know.

One case can be that the language is negotiable, and can be decided 
between the participants during the meeting among a set of supported 
languages. Some language could then also be a preferred production 
language  because of the competence of the participants.

Another case can be that different persons will take turn to be 
represented in the main speakers capture, and each will use one 
language. Some other capture may contain interpretation to one specific 
language all the time.

------
This is different than the SDP specification of language that I guess 
rather should be preferred language of reception, at least for a sendrcv 
media.
> I assume multiple values of this can be associated with any capture.
I agree that that sounds most useful. But I did not see anything about 
that in the draft, and there are some words indicating single values, 
e.g.  " indicates *which* language ".
I agree that multiple languages should be supported. I do not know if it 
is then best with multiple language tags within one language attributes, 
or multiple language attributes with one language tag each.
> I'll have to think some more about duplicate usage with SDP.
Language tags are also allowed on the SIP header level.

Does this start to be too complex compared to what will be asked for in 
reality.

/Gunnar

---

From: Christian Groves <[email-masked]>
Date: Fri, 14 Dec 2012 11:11:14 +1100

Hello Gunnar and Keith,

Please see my responses below.

Regards, Christian

On 14/12/2012 9:49 AM, Gunnar Hellström wrote:
> Since the attribute is linked to a capture, I would think that it 
> means a possible content language in the capture.
[CNG] Yes this is what I had envisaged when proposing the attribute.
>
> But second thought:
> That simple description does not always match what the participants 
> want to know.
>
[CNG] This is a difficult one. The participants can always agree to use 
another language once communications are established. i.e. the 
participants here that they both have Swedish accents so they speak 
Swedish to each other. It must be remembered that CLUE is used before 
any substantive SDP is exchanged about the media streams. Once the 
participants decide to speak Swedish is there any point in sending a 
updated Advertisement or Configure?

> language. Some other capture may contain interpretation to one 
> specific language all the time.
[CNG] OK, this one I think justifies having the language tag being a list.
> rather should be preferred language of reception, at least for a 
> sendrcv media.
> I agree that multiple languages should be supported. I do not know if 
> it is then best with multiple language tags within one language 
> attributes, or multiple language attributes with one language tag each.

[CNG] It can probably be done as multiple values to a single tag.
> Does this start to be too complex compared to what will be asked for 
> in reality.
[CNG] As the draft indicates the need for additional attributes to 
describe captures relates to how/where CLUE is used in a call flow. 
Currently its assumed that a CLUE channel is created. A provider sends 
an Advertisement. The consumer chooses the captures it wants and it 
sends a Configure. Media is then established through CLUE. If we rely on 
only SDP having the language tag then the wrong captures may have been 
chosen in the initial CLUE exchange.

>>> From:[email-masked]  [mailto:[email-masked]] On Behalf Of
>>> Christian Groves
>>> To:[email-masked]

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 14 Dec 2012 08:06:43 +0100

On 2012-12-14 01:11, Christian Groves wrote:
> sends a Configure. Media is then established through CLUE. If we rely 
> on only SDP having the language tag then the wrong captures may have 
> been chosen in the initial CLUE exchange.
Yes, I see the need for language attribute, and for multiple languages.

What I meant was that we identified different reasons to have multiple 
languages specified and wondered if we would need to distinguish between 
them.

Two examples:

1. A possibility to call customer support is offered. One offer is a 
conference call with staff that are able to handle Spanish, French and 
Italian , another with staff who handle Chinese, Japanese and Korean. 
You select which call to initiate, and then agree the language to use 
during the call by human discussion among the ones offered in the call 
and stick to that language for the call duration.  Note that this is not 
about selecting between two captures in the same CLUE, it is about 
selecting what call to make and having the CLUE description as a clue to 
select the call to make.

2. A transmission from a live physical conference, where speakers switch 
and they speak their own languages. A main audio capture contains the 
original sound. That capture would need a list of languages, but there 
is no chance for the receiver to control what language there is at any 
moment. They will take turns. (Another capture may contain spoken 
translation to one single language.)

*Question:* Do we need to differentiate between these two reasons to 
have lists of languages? One for a menue of selectable languages, and 
another for a list of languages that will appear taking turns in the 
capture.
Or should that difference be left to be made clear by the announcement 
of the conference in some other form.

Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 14 Dec 2012 16:45:53 +0100

On 2012-12-14 15:07, Michael Hammer wrote:
>
> Gunnar,
>
> The language of the capture should stick to what it advertises itself 
> to be.
>
> If the sender offers to have English captioning, and the receive opts 
> for English captioning, that is what the receiver should get.
>
Yes, agreed. I am discussing two reasons to offer a list of languages.

And it is for any capture, audio, video, video-embedded text, or text,

1. The offerer indicates a list of language capabilities,  the 
participant selects which one to use.

2. The offerer indicates that the language will vary throughout the 
session by providing a list of languages.

And my question was if the difference between these two reasons to have 
a list of languages causes a need to code the language attribute 
differently.

Gunnar

> Mike
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf 
> Of *Gunnar Hellström
> *Sent:* Friday, December 14, 2012 2:07 AM
> *To:* Christian Groves
> *Cc:* [email-masked]
> *Subject:* Re: [clue] Capture Attribute Discussion: 4.3. Language
>
>         Does this start to be too complex compared to what will be
>         asked for in reality.
>
>     describe captures relates to how/where CLUE is used in a call
>     flow. Currently its assumed that a CLUE channel is created. A
>     provider sends an Advertisement. The consumer chooses the captures
>     it wants and it sends a Configure. Media is then established
>     through CLUE. If we rely on only SDP having the language tag then
>     the wrong captures may have been chosen in the initial CLUE exchange.
>
> languages specified and wondered if we would need to distinguish 
> between them.
>
> Two examples:
>
> and stick to that language for the call duration.  Note that this is 
> not about selecting between two captures in the same CLUE, it is about 
> selecting what call to make and having the CLUE description as a clue 
> to select the call to make.
>
> 2. A transmission from a live physical conference, where speakers 
> switch and they speak their own languages. A main audio capture 
> contains the original sound. That capture would need a list of 
> languages, but there is no chance for the receiver to control what 
> language there is at any moment. They will take turns. (Another 
> capture may contain spoken translation to one single language.)
>