Re: [MMUSIC] T.140 in Data Channel scenarios - SDP support

[Gunnar Hellström <[e-mail]>]

Hi,

Den 2019-09-26 kl. 15:57, skrev Christer Holmberg:
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.

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:

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



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 <[e-mail]><mailto:[e-mail]>
Date: Thursday, 26 September 2019 at 0.39
To: Bernard Aboba <[e-mail]><mailto:[e-mail]>
Cc: Christer Holmberg <[e-mail]><mailto:[e-mail]>, "[e-mail]"<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]>
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>

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.

"

<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





   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 <[e-mail]<mailto:[e-mail]>> 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---------------------<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





   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 <[e-mail]<mailto:[e-mail]>> 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

[e-mail]<mailto:[e-mail]>

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

--

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

Gunnar Hellström
Omnitor
[e-mail]<mailto:[e-mail]>
[phone]