Subject: [MMUSIC] T.140 in Data Channel scenarios

From: Bernard Aboba <[email-masked]>
Date: Tue, 24 Sep 2019 11:44:47 -0700

At the W3C TPAC 2019 meeting last week,
draft-ietf-mmusic-t140-usage-data-channel came up as part of a discussion
of Accessible RTC Use Cases:
https://www.w3.org/WAI/APA/wiki/Accessible_RTC_Use_Cases

Here are a few of the questions that came up.

Section 3

       +--------------------------+-------------------------------+
       | Subprotocol Identifier   | t140                          |
       | Transmission reliability | reliable                      |
       | Transmission order       | in-order                      |
       | Label                    | See Section 4.1
<https://tools.ietf.org/html/draft-ietf-mmusic-t140-usage-data-channel-05#section-4.1>
and Section 6 <https://tools.ietf.org/html/draft-ietf-mmusic-t140-usage-data-channel-05#section-6>
|
       +--------------------------+-------------------------------+

Are there any situations in which unreliable or partially reliable
transport might be appropriate?

For example, some participants envisaged scenarios in which low
latency communications might be desirable, such as in emergencies, and
questioned whether it might make sense to use the maxPacketLifetime or
maxRetransmissions parameters.

So there was a question about whether it might ever make sense to
support an unreliable data channel (possibly with redundancy).

Lost information (compared with RTP)

We had some questions relating to information "lost in translation"
between realtime text

and data channel.  This includes aspects of the RTP header, including
SSRCs, timestamps and sequence numbers.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 24 Sep 2019 20:12:11 +0000

Hi Bernard,

Gunnar will probably be able to give a better answer, but below are some comments from me.

>At the W3C TPAC 2019 meeting last week, draft-ietf-mmusic-t140-usage-data-channel came up as part of a discussion of Accessible RTC Use Cases:

>       | Label                    | See Section 4.1<https://tools.ietf.org/html/draft-ietf-mmusic-t140-usage-data-channel-05#section-4.1> and Section 6<https://tools.ietf.org/html/draft-ietf-mmusic-t140-usage-data-channel-05#section-6> |

> Are there any situations in which unreliable or partially reliable transport might be appropriate?

> For example, some participants envisaged scenarios in which low latency communications might be

>  desirable, such as in emergencies, and questioned whether it might make sense to use the maxPacketLifetime

> or maxRetransmissions parameters.

> So there was a question about whether it might ever make sense to support an unreliable data channel (possibly with redundancy).

T.140 requires the transport mechanism to keep packets in order, and without duplication. When using RTP, the sequence number is used to detect out-of-order packets and loss of packets. You don’t have that mechanism in a data channel, and T.140 itself does not contain a sequence number.

When using RTP, reliability can provided by sending of redundant data, or by using FEC. FEC is RTP-specific, so you can’t use that on a data channel.

I don’t think the redundancy mechanism can be used on the data channel either, because it uses the RTP header timestamp.

And, you can not re-transmit T.140 text on a data channel (T.140 RTP packets are not re-transmitted either), because the receiver will not be able to detect it (again, because T.140 does not contain a sequence number).

Of course we could have defined an “envelope” for the data channel T.140 text, with sequence numbers. But, the idea was to simply send the T.140 text as the data channel itself provides delivery and reliability.

---

>We had some questions relating to information "lost in translation" between realtime text

>and data channel.  This includes aspects of the RTP header, including SSRCs, timestamps and sequence numbers.

Yes, that information is lost.

There were some discussions about including SSRC somehow, in order to support conferences where a mixer uses a single data channel for text received from multiple remote users, but we decided that it is outside the scope of this draft.

Regards,

Christer

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 24 Sep 2019 14:46:42 -0700

Thanks for the explanation.  Would there be a way for some of this to make
its way into the document?  I think that would make it easier for the APA
to review.

Christer said:

"T.140 requires the transport mechanism to keep packets in order, and
without duplication. When using RTP, the sequence number is used to detect
out-of-order packets and loss of packets. You don’t have that mechanism in
a data channel, and T.140 itself does not contain a sequence number.

When using RTP, reliability can provided by sending of redundant data,
or by using FEC. FEC is RTP-specific, so you can’t use that on a data
channel.

I don’t think the redundancy mechanism can be used on the data channel
either, because it uses the RTP header timestamp.

 And, you can not re-transmit T.140 text on a data channel (T.140 RTP
packets are not re-transmitted either), because the receiver will not
be able to detect it (again, because T.140 does not contain a sequence
number).

Of course we could have defined an “envelope” for the data channel T.140
text, with sequence numbers. But, the idea was to simply send the T.140
text as the data channel itself provides delivery and reliability."

On Tue, Sep 24, 2019 at 1:12 PM Christer Holmberg <
[email-masked]> wrote:

> >       | Label                    | See Section 4.1 <https://tools.ietf.org/html/draft-ietf-mmusic-t140-usage-data-channel-05#section-4.1> and Section 6 <https://tools.ietf.org/html/draft-ietf-mmusic-t140-usage-data-channel-05#section-6> |
>

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 24 Sep 2019 22:08:14 +0000

Hi,

Hi Bernard,

[GH] I agree with Christer. There is a risk that during very severe conditions, the reliable SCTP association makes a number of retries for up to 30 seconds and then breaks,

But the chance to get understandable text through in such conditions by sending in an unreliable channel with redundancy is probably not much higher. And it would require to for example use RTP and RFC 4103 on top of an unreliable data channel, a complication I would not like to introduce.

I made a bit more comments on this on August 21.

---

[GH] The Stream-ID can be seen as "an SSRC", and the Label can be seen as a CNAME in one direction. Sequence number and timestamp are usually only used on transport level, and something similar is likely used in the reliable data channel transport, but not reported to the application.

A concern though: If the reliable channel breaks because of bad conditions, can we then really know on both sides what has been transmitted so that if we get a successful reconnection we can avoid resending already received text?

Regards

Gunnar

Regards,

Christer

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 24 Sep 2019 15:15:22 -0700

Gunnar said:

"A concern though: If the reliable channel breaks because of bad
conditions, can we then really know on both sides what has been transmitted
so that if we get a successful reconnection we can avoid resending already
received text?"

[BA] Without some additional application-layer mechanism, I think the
answer is "no".

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 25 Sep 2019 09:26:29 +0000

Hi,

> Thanks for the explanation.  Would there be a way for some of this to make its way into the document?
> I think that would make it easier for the APA to review.

What about the following note below the table:

“NOTE: T.140 does not provide reliable and ordered transmission of T.140 data.
Instead, T.140 requires the transport channel to provide real-time text without
duplication and in original order. When RTP based transport is used, the RTP sequence
number is used to detect packet loss and out-of-order packets, and a redundancy
mechanism using the RTP timestamp is used to achieve reliable delivery of T.140 data.”

Regards,

Christer

Christer said:

"T.140 requires the transport mechanism to keep packets in order, and without duplication. When using RTP, the sequence number is used to detect out-of-order packets and loss of packets. You don’t have that mechanism in a data channel, and T.140 itself does not contain a sequence number.

Of course we could have defined an “envelope” for the data channel T.140 text, with sequence numbers. But, the idea was to simply send the T.140 text as the data channel itself provides delivery and reliability."

On Tue, Sep 24, 2019 at 1:12 PM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi Bernard,

---

Regards,

Christer

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 25 Sep 2019 11:58:18 -0700

Your note looks good.  You might also want to add a sentence or two about
why you have chosen reliable transport and the implications (that
redundancy is not needed).

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 25 Sep 2019 19:26:36 +0000

Hi,

Gunnar said:

"A concern though: If the reliable channel breaks because of bad conditions, can we then really know on both sides what has been transmitted so that if we get a successful reconnection we can avoid resending already received text?"

[BA] Without some additional application-layer mechanism, I think the answer is "no".

[GH] Yes, I expected that. Even if the data channel protocol has ambitions to report what data was sent and received before a failure, I am sure that there are error situations when this ambition cannot be satisfied, and the applications is left not exactly knowing what was transmitted successfully before a channel or association breakage.

This finding calls for reviewing wording in two places in the draft,

------------------in 5.4---------------------
5.4<https://tools.ietf.org/html/draft-ietf-mmusic-t140-usage-data-channel-05#section-5.4>.  Loss of T140blocks

   In case of network failure or congestion, T.140 data channels might
   fail and get torn down.  If this happens but the session sustains, it
   is RECOMMENDED that a low number of retries are made to reestablish
   the T.140 data channels.  If reestablishment of the T.140 data
   channel is successful, an implementation MUST evaluate if any
   T140blocks were lost.  Retransmission of already successfully
   transmitted T140blocks MUST be avoided, and missing text markers
   [T140ad1<https://tools.ietf.org/html/draft-ietf-mmusic-t140-usage-data-channel-05#ref-T140ad1>] SHOULD be inserted in the received data stream where loss
   is detected or suspected.

----------and in a bullet point in 6. Gateway considerations--------

o  If the gateway detects that the T.140 data channel has failed and
      got torn down, once the data channel has been reestablished the
      gateway SHOULD insert the T.140 missing text marker [T140ad1<https://tools.ietf.org/html/draft-ietf-mmusic-t140-usage-data-channel-05#ref-T140ad1>] in
      the data sent on the outgoing RTP stream if it detects or suspects
      that data on the T.140 data channel was lost.

-------------------------------------------------------------------

Situations when the channel is torn down because of error are expected to be very rare exceptional cases. How the text session behaves in such situation should not be required to meet the requirements in T.140.  Looking at how current multimedia conversational applications handle similar situations, it seems common that for human operated apps, the user gets alerted by a message box with text in this style . "Problems are detected with your Internet connection. We make efforts to get back to normal operation." And eventually, communication is recovered and you do not know what was lost.

Such actions could be recommendable also for sessions containing T.140 data channels, but it is a general app behavior towards users that may be less relevant for us to specify.

Looking at this phrase in 5.4: "

Retransmission of already successfully
   transmitted T140blocks MUST be avoided, and missing text markers
   [T140ad1<https://tools.ietf.org/html/draft-ietf-mmusic-t140-usage-data-channel-05#ref-T140ad1>] SHOULD be inserted in the received data stream where loss
   is detected or suspected.

"
There may be T140blocks in the data channel transmission buffer that have been transmitted, and received by the other party, but not yet noted as successfully transmitted.
So, in order to obey the MUST for not resending already successfully transmitted text, nothing that is in the transmission buffer may be resent after reconnection. So, the normal action should be to ignore any text in the transmission buffer, insert a missing text marker in the transmitted text if any unacknowledged text was in the transmission buffer at the time of the failure.
It is harder for the receiving side to analyze if anything was lost in reception over the break and reconnect. But it could be a general advice to insert a missing text marker because some text may have been lost.

So, the analysis calls for just a small modification to add "sent and" in the last sentence to make it read:
"

Retransmission of already successfully
   transmitted T140blocks MUST be avoided, and missing text markers
   [T140ad1<https://tools.ietf.org/html/draft-ietf-mmusic-t140-usage-data-channel-05#ref-T140ad1>] SHOULD be inserted in the sent and received data streams where loss
   is detected or suspected.

"

For the wording in section 6, gateway considerations, I find that the existing text is good, but marking may be needed also in the transmission direction towards the T.140 data channel. So, I suggest to add that in the bullet point to make it read:
----------------------------------------------------------------------------

o  If the gateway detects that the T.140 data channel has failed and
      got torn down, once the data channel has been reestablished the
      gateway SHOULD insert the T.140 missing text marker [T140ad1<https://tools.ietf.org/html/draft-ietf-mmusic-t140-usage-data-channel-05#ref-T140ad1>] in
      the data sent on the outgoing RTP stream and on the outgoing
      T.140 data channel if it detects or suspects
      that data on the T.140 data channel was lost in the corresponding

      transmission directions.

-------------------------------------------------------------------

Regards

Gunnar

On Tue, Sep 24, 2019 at 3:08 PM Gunnar Hellström <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Hi Bernard,

---

Regards

Gunnar

Regards,

Christer

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 25 Sep 2019 20:17:08 +0000

Hi,

We have a note in section 4.2. saying:

"NOTE: At the time of writing this specification, the latest verion of
   the API defined in [W3C.webrtc<https://tools.ietf.org/html/draft-ietf-mmusic-t140-usage-data-channel-05#ref-W3C.webrtc>] does not support the use of the SDP
   attributes defined in this section."

However, now I found that sections 4.4.1.6, 4.6 and 4.7 of the W3C API for WebRTC contains specification
 of SDP negotiation and customized SDP contents.

I would like to get comments if that SDP interface is flexible enough for including our dcsa attributes
and performing an SDP negotiation of a T.140 data channel.

If so, we should delete or reword that note in 4.2.

This is the W3C spec I read: https://www.w3.org/TR/webrtc/

Regards
Gunnar

Den 2019-09-25 kl. 21:26, skrev Gunnar Hellström:
Hi,

Gunnar said:

----------and in a bullet point in 6.. Gateway considerations--------

Situations when the channel is torn down because of error are expected to be very rare exceptional cases. How the text session behaves in such situation should not be required to meet the requirements in T.140.  Looking at how current multimedia conversational applications handle similar situations, it seems common that for human operated apps, the user gets alerted by a message box with text in this style .. "Problems are detected with your Internet connection. We make efforts to get back to normal operation." And eventually, communication is recovered and you do not know what was lost.

"

"

      transmission directions.

Regards

Gunnar

Hi Bernard,

>https://www.w3..org/WAI/APA/wiki/Accessible_RTC_Use_Cases<https://www.w3.org/WAI/APA/wiki/Accessible_RTC_Use_Cases>

---

Regards

Gunnar

Regards,

Christer

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 25 Sep 2019 14:07:22 -0700

The latest WebRTC API specification is here:
https://w3c.github.io/webrtc-pc/

While WebRTC applications are free to use whatever signaling they like, the
SDP utilized in the WebRTC API is described in the JSEP document:
https://tools.ietf.org/html/draft-ietf-rtcweb-jsep

Attributes such as hlang would not make sense for use in the WebRTC API
because browser themselves do not have language preferences (though it
might make sense for a WebRTC application to use hlang in its own
signaling).

On Wed, Sep 25, 2019 at 1:17 PM Gunnar Hellström <
[email-masked]> wrote:

>    the API defined in [W3C.webrtc <https://tools.ietf.org/html/draft-ietf-mmusic-t140-usage-data-channel-05#ref-W3C.webrtc>] does not support the use of the SDP
> [GH] Yes, I expected that. Even if the data channel protocol has ambitions
> to report what data was sent and received before a failure, I am sure that
> there are error situations when this ambition cannot be satisfied, and the
> applications is left not exactly knowing what was transmitted successfully
> before a channel or association breakage.
>
> 5.4 <https://tools.ietf.org/html/draft-ietf-mmusic-t140-usage-data-channel-05#section-5.4>.  Loss of T140blocks
>
>    [T140ad1 <https://tools.ietf.org/html/draft-ietf-mmusic-t140-usage-data-channel-05#ref-T140ad1>] SHOULD be inserted in the received data stream where loss
>       gateway SHOULD insert the T.140 missing text marker [T140ad1 <https://tools.ietf.org/html/draft-ietf-mmusic-t140-usage-data-channel-05#ref-T140ad1>] in
> Situations when the channel is torn down because of error are expected to
> be very rare exceptional cases. How the text session behaves in such
> situation should not be required to meet the requirements in T.140.
> Looking at how current multimedia conversational applications handle
> similar situations, it seems common that for human operated apps, the user
> gets alerted by a message box with text in this style .. "Problems are
> detected with your Internet connection. We make efforts to get back to
> normal operation." And eventually, communication is recovered and you do
> not know what was lost.
>
> Such actions could be recommendable also for sessions containing T.140
> data channels, but it is a general app behavior towards users that may be
> less relevant for us to specify.
>
>    [T140ad1 <https://tools.ietf.org/html/draft-ietf-mmusic-t140-usage-data-channel-05#ref-T140ad1>] SHOULD be inserted in the received data stream where loss
> There may be T140blocks in the data channel transmission buffer that have
> been transmitted, and received by the other party, but not yet noted as
> successfully transmitted.
> So, in order to obey the MUST for not resending already successfully
> transmitted text, nothing that is in the transmission buffer may be resent
> after reconnection. So, the normal action should be to ignore any text in
> the transmission buffer, insert a missing text marker in the transmitted
> text if any unacknowledged text was in the transmission buffer at the time
> of the failure.
> It is harder for the receiving side to analyze if anything was lost in
> reception over the break and reconnect. But it could be a general advice to
> insert a missing text marker because some text may have been lost.
>
>    [T140ad1 <https://tools.ietf.org/html/draft-ietf-mmusic-t140-usage-data-channel-05#ref-T140ad1>] SHOULD be inserted in the sent and received data streams where loss
> For the wording in section 6, gateway considerations, I find that the
> existing text is good, but marking may be needed also in the transmission
> direction towards the T.140 data channel. So, I suggest to add that in the
> bullet point to make it read:
>
>       gateway SHOULD insert the T.140 missing text marker [T140ad1 <https://tools.ietf.org/html/draft-ietf-mmusic-t140-usage-data-channel-05#ref-T140ad1>] in
> >https://www.w3..org/WAI/APA/wiki/Accessible_RTC_Use_Cases
> <https://www.w3.org/WAI/APA/wiki/Accessible_RTC_Use_Cases>
>
> >
>
> mmusic mailing [email-masked]://www.ietf.org/mailman/listinfo/mmusic
>
>

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 25 Sep 2019 21:39:12 +0000

Den 2019-09-25 kl. 23:07, skrev Bernard Aboba:
The latest WebRTC API specification is here:
https://w3c.github.io/webrtc-pc/

While WebRTC applications are free to use whatever signaling they like, the SDP utilized in the WebRTC API is described in the JSEP document:
https://tools.ietf.org/html/draft-ietf-rtcweb-jsep

While some statements in that draft seem to indicate that customised SDP for data channels can be made through that API,

section 5.2 limits the scope to RTP media.

"

5.2<https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-26#section-5.2>.  Constructing an Offer

   When createOffer is called, a new SDP description must be created
   that includes the functionality specified in
   [I-D.ietf-rtcweb-rtp-usage<https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-26#ref-I-D.ietf-rtcweb-rtp-usage>].  The exact details of this process are
   explained below."

Can you please check if the intention is to be able to negotiate data channels and their individual dcsa attributes?

Attributes such as hlang would not make sense for use in the WebRTC API because browser themselves do not have language preferences (though it might make sense for a WebRTC application to use hlang in its own signaling).

hlang makes sense. The main targets for hlang are the users who need to know in which language they will be able to start the spoken or typed or signed session. The browser just need to convey the values between the user and the attributes.

The question is for all dcsa attributes: cps , format, directions, hlang

Regards

Gunnar

On Wed, Sep 25, 2019 at 1:17 PM Gunnar Hellström <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Regards
Gunnar

Gunnar said:

----------and in a bullet point in 6.. Gateway considerations--------

"

"

      transmission directions.

Regards

Gunnar

Hi Bernard,

---

Regards

Gunnar

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 26 Sep 2019 06:08:23 +0000

Hi,

> Your note looks good.  You might also want to add a sentence or two about why you have 
> chosen reliable transport and the implications (that redundancy is not needed).

“NOTE: T.140 does not provide reliable and ordered transmission of T.140 data. 
Instead, T.140 requires the transport channel to provide real-time text without 
duplication and in original order. When RTP based transport is used, the RTP sequence
number is used to detect packet loss and out-of-order packets, and a redundancy
mechanism using the RTP timestamp is used to achieve reliable delivery of T.140 data.
By using the reliable and in-order transmission features on the T.140 data channel, there
is no need for a redundancy mechanism or a mechanism to detect packet loss and
out-of-order packets.”

Regards,

Christer

On Wed, Sep 25, 2019 at 2:26 AM Christer Holmberg <mailto:[email-masked]> wrote:
 
Hi,

 
 
Regards,
 
Christer

 

Christer said: 

 

 
On Tue, Sep 24, 2019 at 1:12 PM Christer Holmberg <mailto:[email-masked]> wrote:
Hi Bernard,

>       | Label                    | See https://tools.ietf.org/html/draft-ietf-mmusic-t140-usage-data-channel-05#section-4.1 and https://tools.ietf.org/html/draft-ietf-mmusic-t140-usage-data-channel-05#section-6 |

 

 
---

 
 
Regards,
 
Christer

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 26 Sep 2019 09:19:18 +0000

Hi,

> is no need for a redundancy mechanism or a mechanism to detect packet loss and

I think the proposed wording may scare some readers with the wording 
that no reliability provided etc, even if the surrounding wording 
explains the situation well. So, here is an effort to reword it slightly.

“NOTE: T.140 requires the transport channel to provide real-time text without
duplication and in original order. Therefore, T.140 does not specify reliable
and ordered transmission of T.140 data by any application protocol.
Instead, when RTP based transport is used, the RTP sequence number is used
to detect packet loss and out-of-order packets, and a redundancy mechanism
using the RTP timestamp is used to achieve reliable delivery of T.140 data.
By using the reliable and in-order transmission features on the T.140 data
channel, there is no need for a redundancy mechanism or a mechanism to detect
data loss and out-of-order delivery on the application level. The latency
characteristics of the T.140 data channel is also regarded to be sufficient
to meet the application requirements of T.140.”

Regards
Gunnar

> [email-masked]

-- 

+ + + + + + + + + + + + + +

Gunnar Hellström
Omnitor
[email-masked]
+46 708 204 288

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 26 Sep 2019 06:55:14 -0700

LGTM.

On Thu, Sep 26, 2019 at 2:19 AM Gunnar Hellström <
[email-masked]> wrote:

> packets are not re-transmitted either), because the receiver will not be
> able to detect it (again, because T.140 does not contain a sequence number).
> >
> >>         | Label                    | See
> https://tools.ietf.org/html/draft-ietf-mmusic-t140-usage-data-channel-05#section-4.1
> and
> https://tools.ietf.org/html/draft-ietf-mmusic-t140-usage-data-channel-05#section-6
> |
> > T.140 requires the transport mechanism to keep packets in order, and
> packets are not re-transmitted either), because the receiver will not be
> able to detect it (again, because T.140 does not contain a sequence number).
> >
> text as the data channel itself provides delivery and reliability.
> >
> > ---
> >
> > There were some discussions about including SSRC somehow, in order to
> support conferences where a mixer uses a single data channel for text
> received from multiple remote users, but we decided that it is outside the
> scope of this draft.
> >
> > Regards,
> >
> > Christer
> >
> >
> >

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 26 Sep 2019 13:57:31 +0000

Hi,

As far as the hlang and direction attributes are concerned, is there a need for them to be supported by the API?

The attributes are only for the applications to exchange information (they do not impact the media plane, so the browser does not need them), so the application can insert them in the SDP offer/answer before sending the SDP to the remote peer.

Regards,

Christer

From: Gunnar Hellstrom <[email-masked]>
Date: Thursday, 26 September 2019 at 0.39
To: Bernard Aboba <[email-masked]>
Cc: Christer Holmberg <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [MMUSIC] T.140 in Data Channel scenarios - SDP support

Den 2019-09-25 kl. 23:07, skrev Bernard Aboba:
The latest WebRTC API specification is here:
https://w3c.github.io/webrtc-pc/<https://protect2.fireeye.com/url?k=9311c92f-cf9bebf9-931189b4-0cc47ad93dcc-e456b7610222e27b&q=1&u=https%3A%2F%2Fw3c.github.io%2Fwebrtc-pc%2F>

"

<https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-26#section-5.2>
5.2<https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-26#section-5.2>.  Constructing an Offer

   explained below."

Regards

Gunnar

Hi,

Regards

Gunnar

Gunnar said:

------------------in 5.4---------------------<https://tools.ietf.org/html/draft-ietf-mmusic-t140-usage-data-channel-05#section-5.4>
5.4<https://tools.ietf.org/html/draft-ietf-mmusic-t140-usage-data-channel-05#section-5.4>.  Loss of T140blocks

----------and in a bullet point in 6.. Gateway considerations--------

"

      transmission directions.

Regards

Gunnar

Hi Bernard,

---

Regards

Gunnar

Regards,

Christer

mmusic mailing list

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 26 Sep 2019 14:57:54 +0000

Hi,

Den 2019-09-26 kl. 15:57, skrev Christer Holmberg:
Hi,

The note we have says that the API does not support handling of our dsca attributes. That note was because on earlier reading of the API specification I did not see the SDP-related primitives.

Now I discovered that there are SDP-related primitives which seem to enable free modification of the SDP before transmission, and analysis of incoming SDP. If that is true and works on the data channel part of the SDP, then our note is wrong and should be deleted or changed.

This is the note in question:

You are right that the directions, the languages and also the cps attributes are for action by the application. But the browser seems to be heavily involved in setting up and reporting about SDP, so I assumed that we needed to go through the API to handle our attributes.

It is of course of interest to know if our attributes can be handled other ways than through the API. Still the main question was if our note was wrong. I hope someone with deeper understanding of the WebRTC API can comment.

Regards

Gunnar

Regards,

Christer

From: Gunnar Hellstrom <[email-masked]><mailto:[email-masked]>
Date: Thursday, 26 September 2019 at 0.39
To: Bernard Aboba <[email-masked]><mailto:[email-masked]>
Cc: Christer Holmberg <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: Re: [MMUSIC] T.140 in Data Channel scenarios - SDP support

"

   explained below."

Regards

Gunnar

Hi,

Regards

Gunnar

Gunnar said:

----------and in a bullet point in 6.. Gateway considerations--------

"

      transmission directions.

Regards

Gunnar

Hi Bernard,

---

Regards

Gunnar

Regards,

Christer

mmusic mailing list

--

Gunnar Hellström
Omnitor
[email-masked]<mailto:[email-masked]>
+46 708 204 288

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 26 Sep 2019 08:11:52 -0700

In WebRTC-PC, the text about setLocalDescription
<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-peerconnection-setlocaldescription>
says:

"Passing in a description is optional. If left out, then
setLocalDescription will
implicitly create an offer
<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dfn-create-an-offer>
 or create an answer
<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dfn-create-an-answer>,
as needed. As noted in [JSEP
<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#bib-jsep>] (section
5.4. <https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-25#section-5.4>),
if a description with SDP is passed in, that SDP is not allowed to have
changed from when it was returned from either createOffer or createAnswer."

This means, that "SDP munging" is no longer supported, and that there is no
support for "custom SDP" (e.g. introducing SDP parameters that aren't
included in createOffer).

On Wed, Sep 25, 2019 at 2:39 PM Gunnar Hellström <
[email-masked]> wrote:

> While WebRTC applications are free to use whatever signaling they like,
> the SDP utilized in the WebRTC API is described in the JSEP document:
> While some statements in that draft seem to indicate that customised SDP
> for data channels can be made through that API,
>
> 5.2 <https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-26#section-5.2>.  Constructing an Offer
>
>    [I-D.ietf-rtcweb-rtp-usage <https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-26#ref-I-D.ietf-rtcweb-rtp-usage>].  The exact details of this process are
>    explained below."
>
> hlang makes sense. The main targets for hlang are the users who need to
> know in which language they will be able to start the spoken or typed or
> signed session. The browser just need to convey the values between the user
> and the attributes.
>
>
>> [GH] Yes, I expected that. Even if the data channel protocol has
>> ambitions to report what data was sent and received before a failure, I am
>> sure that there are error situations when this ambition cannot be
>> satisfied, and the applications is left not exactly knowing what was
>> transmitted successfully before a channel or association breakage.
>>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 26 Sep 2019 15:41:49 +0000

Hi Bernard,

I am not sure I understand.

When the app has called createOffer/createAnswer, and have received an SDP from the browser, what prevents the app from modifying the SDP before it sends to towards the remote peer? The app doesn’t need to include the changes when calling setLocalDescription.

Regards,

Christer

Lähettäjä: mmusic <[email-masked]> Puolesta Bernard Aboba
Lähetetty: torstai 26. syyskuuta 2019 18.12
Vastaanottaja: Gunnar Hellström <[email-masked]>
Kopio: mmusic WG <[email-masked]>
Aihe: Re: [MMUSIC] T.140 in Data Channel scenarios - SDP support

In WebRTC-PC, the text about setLocalDescription<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-peerconnection-setlocaldescription> says:

"Passing in a description is optional. If left out, then setLocalDescription will implicitly create an offer<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dfn-create-an-offer> or create an answer<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dfn-create-an-answer>, as needed. As noted in [JSEP<https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#bib-jsep>] (section 5.4.<https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-25#section-5.4>), if a description with SDP is passed in, that SDP is not allowed to have changed from when it was returned from either createOffer or createAnswer."

This means, that "SDP munging" is no longer supported, and that there is no support for "custom SDP" (e.g. introducing SDP parameters that aren't included in createOffer).

On Wed, Sep 25, 2019 at 2:39 PM Gunnar Hellström <[email-masked]<mailto:[email-masked]>> wrote:
Den 2019-09-25 kl.. 23:07, skrev Bernard Aboba:
The latest WebRTC API specification is here:
https://w3c.github.io/webrtc-pc/<https://protect2.fireeye.com/url?k=899eb21f-d5171d92-899ef284-0cc47ad93de2-0854535714974395&q=1&u=https%3A%2F%2Fw3c.github.io%2Fwebrtc-pc%2F>

"

   explained below."

Regards

Gunnar

Hi,

Regards

Gunnar

Gunnar said:

----------and in a bullet point in 6.. Gateway considerations--------

-------------------------------------------------------------------
Situations when the channel is torn down because of error are expected to be very rare exceptional cases. How the text session behaves in such situation should not be required to meet the requirements in T.140.  Looking at how current multimedia conversational applications handle similar situations, it seems common that for human operated apps, the user gets alerted by a message box with text in this style ... "Problems are detected with your Internet connection. We make efforts to get back to normal operation." And eventually, communication is recovered and you do not know what was lost.

"

      transmission directions.

Regards

Gunnar

Hi Bernard,

>https://www.w3...org/WAI/APA/wiki/Accessible_RTC_Use_Cases<https://www.w3.org/WAI/APA/wiki/Accessible_RTC_Use_Cases>

But the chance to get understandable text through in such conditions by sending in an unreliable channel with redundancy is probably not much higher.. And it would require to for example use RTP and RFC 4103 on top of an unreliable data channel, a complication I would not like to introduce.

---

Regards

Gunnar

Regards,

Christer

mmusic mailing list

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 27 Sep 2019 07:00:42 +0000

Gunnar,

So, should we remove the note regarding the API, or you want to keep it?

Regards,

Christer

From: mmusic <[email-masked]> on behalf of Christer Holmberg <christer.holmberg=[email-masked]>
Date: Thursday, 26 September 2019 at 18.42
To: Bernard Aboba <[email-masked]>, Gunnar Hellstrom <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [MMUSIC] T.140 in Data Channel scenarios - SDP support

Hi Bernard,

Regards,

Christer

"

   explained below."

Regards

Gunnar

Hi,

Regards

Gunnar

Gunnar said:

----------and in a bullet point in 6.. Gateway considerations--------

"

      transmission directions.

Regards

Gunnar

Hi Bernard,

---

Regards

Gunnar

Regards,

Christer

mmusic mailing list

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 27 Sep 2019 00:24:25 -0700

Christer said:

"When the app has called createOffer/createAnswer, and have received an SDP
from the browser, what prevents the app from modifying the SDP before it
sends to towards the remote peer? The app doesn’t need to include the
changes when calling setLocalDescription."

[BA] There is no problem with this - but to be clear, this is an app-layer
negotiation that doesn't involve the WebRTC API, and therefore can't be
enforced by the browser. So attributes like hlang or data channel
attributes relating to direction are purely for the application and are
never sent the browser which would throw an error if they appeared in an
SDP description provided to an API call, for the reasons cited.

On Thu, Sep 26, 2019 at 8:41 AM Christer Holmberg <
[email-masked]> wrote:

> When the app has called createOffer/createAnswer, and have received an SDP
> from the browser, what prevents the app from modifying the SDP before it
> sends to towards the remote peer? The app doesn’t need to include the
> changes when calling setLocalDescription.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *Lähettäjä:* mmusic <[email-masked]> *Puolesta *Bernard Aboba
> *Lähetetty:* torstai 26. syyskuuta 2019 18.12
> *Vastaanottaja:* Gunnar Hellström <[email-masked]>
> *Kopio:* mmusic WG <[email-masked]>
> *Aihe:* Re: [MMUSIC] T.140 in Data Channel scenarios - SDP support
>
>
>
> setLocalDescription will implicitly create an offer
> This means, that "SDP munging" is no longer supported, and that there is
> no support for "custom SDP" (e.g. introducing SDP parameters that aren't
> <https://protect2.fireeye.com/url?k=899eb21f-d5171d92-899ef284-0cc47ad93de2-0854535714974395&q=1&u=https%3A%2F%2Fw3c.github.io%2Fwebrtc-pc%2F>
>
>
>
> <https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-26#section-5.2> 5.2
> <https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-26#section-5.2>.
> Constructing an Offer
>
>
>
>
>
> <https://tools.ietf.org/html/draft-ietf-mmusic-t140-usage-data-channel-05#section-5.4>
> 5.4
> <https://tools.ietf.org/html/draft-ietf-mmusic-t140-usage-data-channel-05#section-5.4>.
> Loss of T140blocks
>
>
>
>
>
> gets alerted by a message box with text in this style ... "Problems are
> >https://www.w3...org/WAI/APA/wiki/Accessible_RTC_Use_Cases

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 27 Sep 2019 07:47:08 +0000

Hi,

> Christer said:
>
> "When the app has called createOffer/createAnswer, and have received an SDP from the browser, what prevents the
> app from modifying the SDP before it sends to towards the remote peer? The app doesn’t need to include the changes
> when calling setLocalDescription."
>
> [BA] There is no problem with this - but to be clear, this is an app-layer negotiation that doesn't involve the WebRTC API, and therefore can't be enforced by the browser.
> So attributes like hlang or data channel attributes relating to direction are purely for the application and are never sent the browser which would throw an error if they
> appeared in an SDP description provided to an API call, for the reasons cited.

Exactly.

So, that’s why I wonder whether we need to note to begin with, since the attributes are meant for the application, not for the browser.

Regards,

Christer

Regards,

Christer

Lähettäjä: mmusic <[email-masked]<mailto:[email-masked]>> Puolesta Bernard Aboba
Lähetetty: torstai 26. syyskuuta 2019 18.12
Vastaanottaja: Gunnar Hellström <[email-masked]<mailto:[email-masked]>>
Kopio: mmusic WG <[email-masked]<mailto:[email-masked]>>
Aihe: Re: [MMUSIC] T.140 in Data Channel scenarios - SDP support

"

   explained below."

Regards

Gunnar

Hi,

Regards

Gunnar

Gunnar said:

----------and in a bullet point in 6.. Gateway considerations--------

"

      transmission directions.

Regards

Gunnar

Hi Bernard,

---

Regards

Gunnar

Regards,

Christer

mmusic mailing list

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 27 Sep 2019 09:19:05 +0000

Hi,

Den 2019-09-27 kl. 09:47, skrev Christer Holmberg:
Hi,

Exactly.

JSEP has a statement in section 5.2.1  https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-25#section-5.2.1 about creation of an offer for a data channel saying

"Attributes other than the ones specified above MAY be included"

I do not find any similar statements for generating the answer in 5.3.1 https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-25#section-5.3.1,  but I assume that it is allowed.

Also the parsing section 5.8.1 https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-25#section-5.8.1   says:

"Other attributes that are not relevant to JSEP may also be present, and implementations SHOULD process any that they recognize."

So, to me it seems that the API and JSEP together not really supports, but also not forbids use of additional attributes in data channel specifications.

Therefore, the discussed note seems too strong and could be deleted.

Regards

Gunnar

Regards,

Christer

Regards,

Christer

"

   explained below."

Regards

Gunnar

Hi,

Regards

Gunnar

Gunnar said:

----------and in a bullet point in 6.. Gateway considerations--------

"

      transmission directions.

Regards

Gunnar

Hi Bernard,

---

Regards

Gunnar

Regards,

Christer

mmusic mailing list

--

Gunnar Hellström
Omnitor