Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-data-channel - language indication

Gunnar Hellström <> Mon, 26 August 2019 08:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1C7AE120025 for <>; Mon, 26 Aug 2019 01:58:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aaIFsx_kOQaX for <>; Mon, 26 Aug 2019 01:58:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F25DB120048 for <>; Mon, 26 Aug 2019 01:58:29 -0700 (PDT)
X-Halon-ID: a5422dcb-c7df-11e9-837a-0050569116f7
Received: from [] (unknown []) by (Halon) with ESMTPSA id a5422dcb-c7df-11e9-837a-0050569116f7; Mon, 26 Aug 2019 10:58:18 +0200 (CEST)
To: Christer Holmberg <>, "" <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <>
Message-ID: <>
Date: Mon, 26 Aug 2019 10:58:25 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-data-channel - language indication
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 26 Aug 2019 08:58:35 -0000

Hi Christer,

Den 2019-08-26 kl. 09:30, skrev Christer Holmberg:
> Hi Gunnar,
> 12. At the end of 3.2, add the following about language negotiation
>>>>> The users may be interested to negotiate language to use during the
>>>>> real-time text session. This is done by including specifications of
>>>>> language capabilities in the media descriptors for the t140 data
>>>>> channels by use of dsca attributes hlang-send and hlang-recv
>>>>> according to RFC 8373 [RFC8373]. The format is as follows:
>>>>> a=dsca:id hlang-send:language
>>>>> a=dsca:id hlang-send:language
>>>>> The negotiation is performed as indicated in RFC8373.
>>>> Whoops, there was a copy-paste error there. the second dsca attribute was intended to be:
>>>> a=dsca:id hlang-recv:language
>>>> also, the value may be a list of space separated language tags, so it would be more correct to say:
>>>> a=dsca:id hlang-send:language(s)
>>>> a=dsca:id hlang-recv:language(s)
>>>> This is a bit informal way to specify the format. Do you think it is acceptable? The reader should
>>>> anyway look into RFC 8373 for the complete specification.
>>> I don't think we need to say anything how to specify. draft-data-channel-sdpneg defines how to convey
>>> SDP attributes in the dsca attribute, and 8873 defines the format of the hdland-send/recv attributes.
>> We could include an example instead.
> Yes.


Change 3.3. header from Example to Examples

Add at the end of 3.3 the following:

Another example is an offer for a T.140 data channel from an 
organisation offering real-time text conversation in Spanish and 
Esperanto, and an answer accepting Esperanto.


  m=application 911 UDP/DTLS/SCTP webrtc-datachannel
        c=IN IP6 2001:db8::3
        a=sctp-port 5000
        a=dcmap:1 label="ACME customer service";subprotocol="t140"
        a=dcsa:1 fmtp:-
        a=dsca:1 hlang-send:es eo
        a=dsca:1 hlang-recv:es eo


m=application 911 UDP/DTLS/SCTP webrtc-datachannel
        c=IN IP6 2001:db8::3
        a=sctp-port 5000
        a=dcmap:1 label="ACME customer service";subprotocol="t140"
        a=dcsa:1 fmtp:-
        a=dsca:1 hlang-send:eo
        a=dsca:1 hlang-recv:eo

(Christer, can you please insert the variations needed in the answer to 
make it a realistic example of offer - answer.)

> ---
> 12a: Allow use of hlang- attributes together with m=application media declarations
>>>>>> RFC 8373 has a statement in section 5.3 saying:
>>>>>> "This document does not define the use of language tags in media
>>>>>> other than interactive streams of audio, video, and text (such as "message" or "application").
>>>>>> Such use could be supported by future work or by application agreement."
>>>>>> The reason for this limitation is that it must be clear for what
>>>>>> modality (spoken or written or signed ) the language is intended to
>>>>>> be used. For audio, text and video, RFC 8373 defines the implicit
>>>>>> relation audio=spoken, text=written, video=signed, but for
>>>>>> "application" there is no such implicit relation and it is in our case the subprotocol T140 that
>>>>>> we can be sure carries written language modality. So, we just need to specify in the draft that
>>>>>> for media "application  / webrtc-datachannel" and subprotocol "t140", the language modality
>>>>>> is "written".  It may in fact be evident from the context.
>>>>> I will look into it, but it seems like a useful clarification to make.
>>>> Yes, it may be sufficient with a clear statement that for m=application / webrtc-datachannel
>>>> subprotocol T140, language indications according to RFC 8373 are allowed and indicate written
>>>> language media. But that is a kind of extension over what RFC 8373 specified because the use
>>>> for a=application was excluded there. Do we need to make IANA aware of that extension in some way?
>>> Not sure about IANA, but it might be an update to 8373.
>>> The problem is that we are not defining usage of the lang attributes, and modality, for the 'application/webrtc-datachannel' media type:
>>> we are defining modality and usage of the attributes for a specific data channel.
>>> So, maybe something like:
>>>        "This document updates RFC 8373, by defining how the SDP hlang-send and hlang-recv attributes are used for
>>>          the "application/webrtc-datachannel" media type.
>>>         SDP endpoints MUST NOT include the attributes directly in the m= section associated with the
>>>         'application/webrtc-datachannel' media type. Instead, the attributes MUST be associated with
>>>         individual data channels, using the  SDP dcsa attribute. A specification that defines a subprotocol
>>>         that uses the attributes MUST specify the modality for that subprotocol.
>>>         For T.140 data channels the modality is 'written'."
>>     This works for the T140 data channel, but another subprotocol may be
>>     able to carry more than one media type and therefore have some other
>>     indication of what media type is used. An example is the msrp data
>>     channel that can carry messages with different modalities.
> Sure, and the text says that each subprotocol specification need to define what the modality is.
> (Of course, it would have been great if 8373 would have defined a way to explicitly indicate the modality, instead of implicitly retrieve it from the media type.)
Agreed. It was discussed but not included in the final result.
>>     So, yes, it is tempting to say that we extend RFC 8373 in general, but
>>     we can do in in a fully specified way only for the T140 data channel.
>>     How would you express that?
> Using the suggested text above :)
> - It updates 8373 by allowing usage of the lang attributes for application/webrtc-datachannel media types.
> - It updates draft-data-channel-sdpneg, by indicating that the modality must be defined for each data channel that
>    uses the lang attributes. In draft-t140-data-channel we then define the modality for T.140 data channels.

Yes, I agree, it can be read your way.

But I read "A specification that defines a subprotocol that uses the 
attributes MUST specify the modality for that subprotocol." as if only 
one modality was tied to a specific subprotocol identity.

Can we change the sentence to "A specification that defines a 
subprotocol that uses the attributes MUST specify how the modality is 
deducted for languages used with that subprotocol."



> Regards,
> Christer
> _______________________________________________
> mmusic mailing list

Gunnar Hellström
+46 708 204 288