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

[Bernard Aboba <[e-mail]>]

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 <
[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---------------------
> 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]> 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 [e-mail]://www.ietf.org/mailman/listinfo/mmusic
>
>