Subject: Re: [MMUSIC] T.140 in Data Channel scenarios - SDP support- the pull request

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

https://github.com/cdh4u/draft-datachannel-t140/pull/35

Regards,

Christer

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

Hi,
Den 2019-09-27 kl. 09:47, skrev Christer Holmberg:
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.

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

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

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>

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,

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:

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

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:

>https://www.w3...org/WAI/APA/wiki/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).

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.

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

---

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

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.

[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

_______________________________________________

mmusic mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/mmusic

--

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

Gunnar Hellström

Omnitor

[email-masked]<mailto:[email-masked]>

+46 708 204 288

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 27 Sep 2019 04:03:17 -0700

I do not understand the PR. 

> On Sep 27, 2019, at 2:41 AM, Christer Holmberg <[email-masked]> wrote:
> 
> 
[BA] No existing browser generates the attributes defined in the draft in createOffer(). Since the SDP cannot be changed, that also means that if you pass the draft attributes to SLD/SRD these calls will fail.
> 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.
[BA] That is not correct. If you pass the draft attributes to SLD/SRD all browsers will fail.
> Therefore, the discussed note seems too strong
> 

The note is correct as written. What could be clarified is that if support for the attributes can be handled in the application, browser support is not required.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 27 Sep 2019 11:05:56 +0000

Hi,

The PR simply removes the note saying that the W3C API does not support the attributes.

Since the W3C API doesn’t need to support the attribute, as they are processed in the application, I think the note would simply confuse people and give the impression that the T.140 data channel cannot be used with browsers.

Regards,

Christer

From: Bernard Aboba <[email-masked]>
Date: Friday, 27 September 2019 at 14.03
To: Christer Holmberg <[email-masked]>
Cc: Gunnar Hellstrom <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [MMUSIC] T.140 in Data Channel scenarios - SDP support- the pull request

On Sep 27, 2019, at 2:41 AM, Christer Holmberg <[email-masked]> wrote:
https://github.com/cdh4u/draft-datachannel-t140/pull/35<https://protect2.fireeye.com/url?k=6c07239e-308ef9b2-6c076305-0cc47ad93da2-91c6408d5e3af454&q=1&u=https%3A%2F%2Fgithub.com%2Fcdh4u%2Fdraft-datachannel-t140%2Fpull%2F35>