Update the accessibility section 14 to include RFC 8865 for real-time text in WebRTC data channel

[gunnarhm]

The last three paragraphs of section 14 on Accessibility describe that real-time text would be transported in WebRTC by the WebRTC Data Channel and that there is ongoing work in IETF mmusic on that topic. The work is completed, and RFC 8865 T.140 Real-Time Text Conversation over WebRTC Data Channels was published in January 2021.

It would therefore be good to update the last three paragraphs of section 14 to reflect that RFC 8865 exists and is intended to be used for the described purpose.

[aboba]

Are there any WebRTC applications supporting RFC 8865? RFC 8865 Section 4 describes SDP parameters specific to negotiation of a T.140 data channel (dcsa and dcmap) that are not supported by any browser. Similarly, no existing browser supports the SDP attributes defined in RFC 8373.

Was it envisaged that browsers or the WebRTC API would need to change to support these new attributes? Or are the new attributes purely for signaling and therefore can be ignored in the API?

[gunnarhm]

The dcsa and dcmap attributes are for signaling. They are specified to be used for RFC 8373 Language Negotiation, RFC 8873 MSRP over WebRTC, RFC 8865 RTT over WebRTC and RFC 9248 Relay Service User Agent (by reference to RFC 8865). It would be convenient to have API support for handling these attributes. A first step could be to update the three paragraphs at the end of section 14 to reflect the current state, and then consider if any more support by the API could be established to make life easier for applications.

I know only one early and limited implementation, but not using the dcsa and dcmap attributes.

[alvestrand]

Seems better to address this with an explainer talking about how the APIs of WEBRTC relate to applications that want to do timed text.

[gunnarhm]

RFC 8864 specifies how to create data channels, and include parameters with the DCSA and DCMAP attributes.
Both RFC 8864 and RFC 8865 mentions that the data channels can be created by other means than sdp, and indicate that it can be done by the WebRTC API. But that is complicated both because of the lack of support for dcmap and dcsa parameters, and because some problem with the Stream IDs that I hope others who have tried this in practice can explain. So, yes, explaining how to do it for RFC 8865 real time text is a good goal, but I would like to also see support in the API and an update in section 14. I can try to contribute with the update of section 14 as a start.

[cdh4u]

There are 2 separate issues: the text in Section 14, and the possible API support of the SDP dcsa and dcmap attributes.

As far as the text in Section 14 goes, it should have no technical impacts, because it would only update the status of RFC 8865 as it is no longer "ongoing".

[alvestrand]

Per comment #2931 (comment), the dcsa and dcmap attributes have never been implemented. So there's nothing we can interoperate with if this is implemented. This may indicate that the need for dcsa/dcmap is not the greatest - people have found other solutions.

In particular, if one is writing an application that supports a datachannel carrying T.140, there doesn't seem to be a need to do anything but including "t140" in the subprotocol argument of an in-band negotiated datachannel - simpler and doesn't require any change to the WEBRTC documents.

(note: personally I resisted adding the "externally negotiated datachannel" feature at all, because I thought it added functionality that was not needed and made implementation more complex. But the RTCWEB WG declared consensus to include it.)

[cdh4u]

Even if you don't use the dcsa/dcmap attributes, RFC 8865 still defines how to send t.140 over a data channel. So, again, it would be useful to update the sentence in Section 14.

[brtech99]

I would really like to see the Section 14 updated.

As with many accessibility features, lack of implementation is frequently lack of understanding rather than alternate means. And in this case, it's probably more important to have a standard way to get the T.140 through, so that assistive devices and software have a better shot at playing nice with others. So that's more argument for recommending its use rather than alternatives.

We're starting to look at WebRTC stuff for emergency communications, and these kinds of things get more important there.

[gunnarhm]

I would like to see the API support conveying the dcsa attribute contents. Then it would be easier to fully implement RFC 8865 with its full intentions. There seems also to be a conflict to handle the stream ID, if you want to use the API to create the data channel but add the dcsa negotiation beside the API.Then dcsa has the stream id as a parameter to set, but the API usually controls setting the stream ID when you request the data channel creation.

But, how about both updating section 14 and trying to create advice in the normative part of the document for how to support RFC 8865 through the API and something defined extra.

Yes I would also expect emergency communication to start looking at supporting WebRTC.

[gunnarhm]

I have made proposals for initial changes of the text in section 14, in file base-rec.html . I would need advice on how to test it.

[dontcallmedom]

@gunnarhm the changes would be to be brought to the webrtc.html file, not base-rec.html; at this stage, I think the simpler way to test it would be to start a pull request - the continuous integration system will then run and identify potential technical issues

[alvestrand]

A proposal for an API change needs to go to webrtc-extensions, not to webrtc-pc.
We don't add unimplemented feature proposals to webrtc-pc.

The simpler way to support the content of dcsa (characters per second, language for sending and receiving) is to define a message to be sent on the T.140 datachannel that conveys the content - 8864 says that the rules for dcsa are defined by the subprotocol anyway, so there's no possible subprotocol-independent implelentation of RFC 8864.

Keeping the negotiation of cps, hlang-send and hlang-receive inside the datachannel will allow the implementation of an RFC 8865bis that specs this to be done on top of currently implemented WebRTC implementations, without any need for an API change or updating of platforms.

[gunnarhm]

So, I stick to a wording proposal for section 14 here, and continue with discussions on how to achieve simple straightforward support in another issue. Here is a rewording of section 14 I hope I can get checked here before making a pull request of it (The RFC links do not work here, but will once implemented):

14. Accessibility Considerations
This section is non-normative.

The WebRTC 1.0 specification exposes an API to control protocols (defined within the IETF) necessary to establish real-time audio, video and data exchange.

Real-Time Text (RTT), transported by RTP as specified in [RFC4103], updated by [RFC9071] for multiparty RTT, utilizes T.140 to enable a character-by-character style text communication in IP-based communications, person-to-person as well as including emergency communication with emergency services Public Safety Access Points (PSAP).

RTT is a higher functionality replacement of the Telecommunications Device for the Deaf (TDD/TTY) or text telephones, being older devices enabling individuals who are hearing or speech impaired (among others) to communicate over telephone lines.

Since Real-Time Text requires the ability to send and receive data in near real time, it can in WebRTC technology be best supported via the WebRTC 1.0 data channel API. As defined by the IETF, the data channel protocol utilizes the SCTP/DTLS/UDP protocol stack, which supports both reliable and unreliable data channels.

Since the IETF chose a different approach than RTP for data channel transport as part of the WebRTC suite of protocols, there is no standardized way for the WebRTC APIs to directly support Real-Time Text as defined in IETF RFC 4103 and implemented in U.S. (FCC) regulations for wireless communications. The WebRTC working Group will evaluate whether the developed IETF protocols in this space warrant direct exposure in the browser APIs and is looking for input from the relevant user communities on this potential gap.

Within the IETF work is completed with [RFC8865] enabling Real-time text to be sent over the WebRTC data channel, allowing WebRTC client support for RTT, and gateways to be deployed to translate between the SCTP data channel protocol and RFC 4103 Real-Time Text. This work, enables a unified and interoperable approach for integrating real-time text in WebRTC user-agents (including browsers) - through a gateway or otherwise.

Gateways that enable effective RTT support in WebRTC clients can be developed through the use of RFC 8865 WebRTC data channel and RFC 4103 + RFC 9071 Real-Time Text. This will need to be defined at IETF in conjunction with related work at W3C groups to effectively and consistently standardise RTT support internationally.

[aboba]

@alvestrand If an RFC 8865bis were to be developed, there are probably other changes that will be needed. For example, RFC 8865 has an "impedance mismatch" with RFC 4103, due to the differing transports. For example, what does a gateway do if it is receiving RFC 4103 packets, but there is a "hole" due to loss that is not filled in? How long does the gateway wait for the "hole" to be filled in, and what happens if it is not filled? Also, RFC 8865 lacks RTP packet fields such as timestamp and CSRC/SSRC that are important for sync with audio/video as well as implementation of RFC 9071 conferencing. If an RFC 8865bis design sent RTP packets over data channel unreliable/unordered transport, these problems would not arise.

[gunnarhm]

There are certainly improvements that can be imagined in an RFC 8865bis. But I do not see any urgent ones if we only can arrange convenient support through the WebRTC API.
About your questions: There is a section 6.2 Gateway considerations in RFC 9071 describing how to handle multiparty RTT over the border between RTP based and WebRTC data channel based RTT. The gateway would need a complete receiver on the RTP side, analyzing sequence numbers and recovering from lost packets. If there is a gap, section 5.4 of RFC 4103 recommends to wait one second to see if any packets out of order arrives and if not mark the loss and send on to the WebRTC data channel side.
The lack of timestamp is not critical, real time text users, at least in human conversational situations accept a delay of real time text of one second without regarding it annoyingly late. Therefore the requirements on synchronicity with audio or video would be something in that range. I assume that that requirement will be satisfied in WebRTC without any special action for synchronization.
The lack of CSRC/SSRC may be a bit more risky. The gateway considerations in RFC 9071 as well as the multiparty considerations in RFC 8865 section 5.5 say that the label should be used to identify the source, but it is not said how to compose the label.
The use of RTP and redundancy to assure rapid and reliable delivery of real time text is an old heritage from RFC 2793, drafted in 1999, when there was no support for any other transport than RTP in SDP. The reliable WebRTC data channel with delivery in order is a more suitable channel for the purpose. So I think it is good time to do an orderly technology shift and hopefully get convenient API support for rapid reliable delivery in order. So, the main problem I see now is the lack of support for dcsa and dcmap in the API. Maybe not so much for their contents, we can likely live without cps and this way of language indication but for that RFC 8865 says that dcmap MUST be used and the API apparently makes an SDP but has no way to include dcmap but handles its parameters in another way through the API. Maybe that is even a difference small enough to sort out by an ERRATA to RFC 8865 to say that the dcmap is not needed if the contents is transferred in another way?

Have you looked at my proposal for a modified section 14 above? Shall I make a PR of it?

[alvestrand]

Suggested replacement modification in section 14:

"For the provision of real time text in conjunction with real time media, RFC 8865 has serious known deficiencies, and defines a format that is unsuitable for the purpose of providing RTT together with media. Its implementation is therefore NOT RECOMMENDED."

[cdh4u]

Suggested replacement modification in section 14:

"For the provision of real time text in conjunction with real time media, RFC 8865 has serious known deficiencies, and defines a format that is unsuitable for the purpose of providing RTT together with media. Its implementation is therefore NOT RECOMMENDED."

I don't agree with that suggestion. RFC8865 is the only (AFAIK) standardized mechanism to transport RTT over WebRTC, as I assume browsers don't support T.140 over RTP.

[aboba]

@cdh4u RFC 8865 went through the MMUSIC WG. Since it did not go through the RTCWEB WG, there are no references to RFC 8865 in RTCWEB documents (even in revisions such as JSEPbis) and the new SDP attributes have not been implemented in WebRTC endpoints. Given the lack of inclusion in RTCWEB WG documents and the lack of implementation in WebRTC endpoints, it seems odd to say that RFC 8865 is a "standardized mechanism to transport RTT over WebRTC".

[alvestrand]

there are many IETF Proposed Standards whose use is recommended against in other documents (sometimes because it's a bad fit fot that context, sometimes just because it's a bad design). So there's nothing unique about the PS label on 8865 that warrants deeming it fit for purpose for RTT in WebRTC.

[cdh4u]

@cdh4u RFC 8865 went through the MMUSIC WG. Since it did not go through the RTCWEB WG, there are no references to RFC 8865 in RTCWEB documents (even in revisions such as JSEPbis) and the new SDP attributes have not been implemented in WebRTC endpoints. Given the lack of inclusion in RTCWEB WG documents and the lack of implementation in WebRTC endpoints, it seems odd to say that RFC 8865 is a "standardized mechanism to transport RTT over WebRTC".

What I meant was that RFC 8865 is the only standardized mechanism that can be used with WebRTC today. Note that it is possible to use 8865 without the API support of the attributes, but then the application has to modify the SDP and insert that attribute itself.

[cdh4u]

there are many IETF Proposed Standards whose use is recommended against in other documents (sometimes because it's a bad fit fot that context, sometimes just because it's a bad design). So there's nothing unique about the PS label on 8865 that warrants deeming it fit for purpose for RTT in WebRTC.

As has been indicated, there are some limitations (lack of SSRC etc), but that doesn't automatically make it unfit.

[cdh4u]

It is also important to note that the dcmap and dcsa attributes are not 8865 specific. ANY application that want to signal the data channel usage using SDP can use the attributes. Currently such applications have to modify the SDP in order to insert the attributes.

[alvestrand]

Yes; in my opinion the definition of dcmap and dcsa attributes in RFC 8864 is not a good way to signal information about datachannels, AND I don't think using dcmap and dcsa in the way 8865 uses them is a good use of the attributes.

So I'm happy to object to inserting references to either of those documents in the WebRTC specs.

[aboba]

In addition to Harald's concerns, the transport mismatch between RFC 8865 and the RTT RFCs such as RFC 4103 and RFC 9071 are concerning. If RFC 8865 encapsulated RTP fields like timestamp, CSRC/SSRC and used unreliable/unordered data channel, the translation to/from RFC 4103 and 9071 would be simplified. As it is, I don't see how the RFC 8865 design can be deployed in a reliable way at large scale. In particular, the design seems like it would be particularly problematic for life critical services such as emergency calling. It would be extremely irresponsible for a W3C Recommendation to endorse such a design. Even a SHOULD NOT may not be harsh enough if the protocol represents a threat to life, as would be the case in emergency calling.

[cdh4u]

In addition to Harald's concerns, the transport mismatch between RFC 8865 and the RTT RFCs such as RFC 4103 and RFC 9071 are concerning. If RFC 8865 encapsulated RTP fields like timestamp, CSRC/SSRC and used unreliable/unordered data channel, the translation to/from RFC 4103 and 9071 would be simplified. As it is, I don't see how the RFC 8865 design can be deployed in a reliable way at large scale. In particular, the design seems like it would be particularly problematic for life critical services such as emergency calling.

So, are you saying that a Web app that uses a data channel to transport T.140 should generate and send RTP-specific information (CSRC/SSRC) in the data channel, in case there will be data channel-to-RTP gateway somewhere in the path? Wouldn't that gateway create such RTP information, on behalf of the Web app?

[cdh4u]

Yes; in my opinion the definition of dcmap and dcsa attributes in RFC 8864 is not a good way to signal information about datachannels, AND I don't think using dcmap and dcsa in the way 8865 uses them is a good use of the attributes.

So I'm happy to object to inserting references to either of those documents in the WebRTC specs.

The pre-8865 individual draft is already mentioned in the spec, and one of the suggestions was to simply update the text currently saying that there is ongoing work in IETF.

[gunnarhm]

Yes, right, this issue is about updating section 14. I provided a proposal above in #2931 (comment)
I would hope that it was fair to state that the work in mmusic is completed and RFC 8865 exsits.

Did you see my earlier response to why I do not think it would be a good idea to repeat the RTP based solution of RFC 4103 + RFC9071 in WebRTC? It is also available above in #2931 (comment)

We need a much less complex solution than RFC4103 + RFC9071 in WebRTC. I am convinced that it is RFC 8865, but it would be even easier if the attributes we use, which are approved in IETF as common attributes for WebRTC channels, would be supported in the API. I think we should start a new issue about how to ease RTT implementation in WebRTC, and just agree on the updated wording of Section 14 here.

[gunnarhm]

This issue is marked "Discuss at next meeting". May I join?

[aboba]

The W3C policy limits contributions to approved W3C members.

[alvestrand]

This thread made me take a closer look at RFC 8864.
I filed an errata on it: https://www.rfc-editor.org/errata/eid7805
This error illustrates, to my mind, that this protocol was not implemented before standardization.

[caribouW3]

This error illustrates, to my mind, that this protocol was not implemented before standardization.

My understanding is that it could have been specified with a specific non-bidirectional use case in mind (e.g. emergency calls), in that case the direction is known "out of band". That does not make it implementable for generic use cases, of course, but there could have been existing implementations for such use case.

[aboba]

Attempts to implement RFC 8864 and 8865 are stopping in the design phase because the protocol is unusable and unsafe. I would argue it should never have been published as Proposed Standard since it has less implementation experience than Experimental RFCs like Framemarking. Unfortunately the IESG has mandated "Standards Inflation" by pushing back on Experimental RFCs.

[cdh4u]

Attempts to implement RFC 8864 and 8865 are stopping in the design phase because the protocol is unusable and
unsafe.

The protocol is SDP, which we already use anyway, and we are talking about some additional SDP attributes. So, it would be really useful if you would explain WHY you think it is unstable and unsafe.

[cdh4u]

This thread made me take a closer look at RFC 8864. I filed an errata on it: https://www.rfc-editor.org/errata/eid7805

It's a good catch.

Now, it's some years since the RFC was published, and AFAIR I was not very deeply involved in the work, so without digging in the mail- and meeting minutes archives I ASSUME that the 8864 authors simply applied the DCEP rules without considering that the SDP offer takes place BEFORE the DTLS roles have been determined.

Now, my own speculations about why this has not been raised from the implementation community before:

• In all data channel use-cases I have seen, the data channel and the data channel usage (e.g., RTT) are created by the offerer in the initial O/A exchange. After that no additional data channel usages are created. So, the answerer may accept whatever stream identifier (odd or even) it receives.

• In most (all?) data channel use-cases I have seen, when the offerer sends ACTPASS, the receiver returns PASSIVE. So, the offerer assumes it will become that DTLS client. I have also seen cases where the offerer offers ACTIVE, in which case it knows it will become DTLS client (if the answerer accepts the offer).

[lminiero]

Just FYI and to contribute to the discussion, some time ago I prototyped a partial implementation of RFC 8865 in Janus, my open source WebRTC server which can be used as a SIP gateway as well. When I say "partial", I mean I ignored the already mentioned dcsa and dcmap attributes, as unsupported in WebRTC, and so relied on some "assumptions" in my POC demo (e.g., agreed upon label).

For some implementation considerations, I wrote a detailed post a couple of years ago here:
https://www.meetecho.com/blog/realtime-text-sip-and-webrtc/

and made a presentation about it last year at the Kamailio World conference:
https://www.youtube.com/watch?v=yehYE34d3mI&t=19937s

I don't have an instance installed anywhere for testing, but the code is open source and available in a PR:
meetecho/janus-gateway#3231

In case it may help accelerate adoption, I'd be happy to participate to interops and stuff like that. Unfortunately, very few implementations are available in the open source space for testing, which means I had to use either very old clients, or come up with basic homemade ones (like the one I wrote for this short and silly demo).

[gunnarhm]

Do I understand the current situation that:
RFC 8865 says in section 1 that it can be used with DCEP, and without using the SDP of its section 4. That is still true, resulting in that the parameters for characters per second and language preferences cannot be conveyed in any standard way. The characters per second will be at its default 30, which is suitable for most applications.
An ERRATA is submitted for RFC 8864 and discussed. It relates to DTLS initiation. If it can be resolved by an ERRATA, then RFC 8865 would not need any modification. It would still be convenient for implementations if the W3C WebRTC API would support the RFC 8864 SDP attributes.
I suggest that section 14 is updated to reflect this current situation. I can change my proposal for section 14 update.

I am also interested to know what the comment on "unstable and unsafe" referred to.

[gunnarhm]

@aboba , you said > "Also, RFC 8865 lacks RTP packet fields such as timestamp and CSRC/SSRC that are important for sync with audio/video as well as implementation of RFC 9071 conferencing. If an RFC 8865bis design sent RTP packets over data channel unreliable/unordered transport, these problems would not arise."

I see that my answers on these comments were not complete. Here is a refinement:

When drafting RFC 8831, it was decided that real time text should use a reliable data channel. That is specified in RFC 8831 3.2 U-C 5. Therefore, sending over unreliable/unordered is not within scope.
RFC 8865 is made in alignment with that decision.
RFC 8865 makes use of the stream id for mapping the source to the stream similar to how SSRC/CSRC is used in RTP. And the Label provides mapping between source and a readable name of the source like RTCP CNAME.

I already answered the other questions, So I hope that all issues are solved now, except the discovered problem with RFC 8864 when using a mix of SDP according to section 4 of RFC 8865 and RFC 8832 for creating the channel.

We can temporarily say: When applying RFC 8865 together with the W3C WebRTC API, section 4 of RFC 8865 MUST not be used.

[aboba]

@gunnarhm The problem is that in practice, RFC 4103 does not specify robustness requirements sufficiently to prevent garbling of calls when high loss is experienced. For example, we know that in practice burst loss of > 3 packets is common so that use of RED-3, 4 or even 5 may be required to recover from loss. However, RFC 4103 does not require support for RTCP (RRs or NACK/RTX) so that dynamic adjustment of RED is difficult and alternatives (such as NACK) cannot be relied on.

This presents a problem for a gateway built on a reliable data channel when the there is a gap in the RTT jitter buffer. In practice, under conditions of substantial loss, RED-2 is not sufficient to fill in the jitter buffer holes, and then the gateway faces a difficult choice: when faced with an unfilled hole in the jitter buffer, should it reset the reliable data channel, or if not, how long should it wait for the holes to fill?

These problems do not occur when using an unreliable data channel transport, since incoming RTT packets can just be reincapsulated without delay.

Also, as Harald noted, RFC 8865 is incompatible with the specification for the WebRTC data channel, and as a result, it is not implementable.

[gunnarhm]

@aboba You point at characteristics in another way to transport real time text (RTT) as a reason to not accept the agreed way to transport RTT in WebRTC. In RFC 8831 section 3.2 a decision from the early days of WebRTC is reflected that says that RTT shall use the reliable data channel. I think it is a good decision. It makes application development simple and straightforward, and it is sufficiently rapid. Therefore RFC 8865 for RTT in WebRTC is made according to that decision.
The problems you see in gatewaying to the RTP based RFC 4103 are easily explainable. There is a section 6 in RFC 8865 about gateway considerations covering most cases to consider in gatewaying with RFC 4103. But a gateway designer would of course also need to look into RFC 4103. There the answer is found about how long to wait if an unrecoverable sequence number gap is detected. The answer is one second. That should be no big problem for a gateway, knowing that the packet rate in RTT is usually 3 per second, the payload being usually about three characters per packet and the need to keep anything in a buffer is only when a packet loss of three or more packets in sequence appears. There is also no hard decision for the gateway on what to do. It is specified that if character loss is suspected, then a character indicating possible character loss shall be inserted in the text stream. Resetting and restarting the data channel is specified for error situations on the WebRTC side.

It is true that RFC 4103 does not specify any recovery method based on RTCP. But the usual RR / SR reporting is expected to be used, as it is expected from RFC 3550. The use of RFC 4103 in mobile phones is specified in 3GPP TS 26.114, and there it is also mentioned that "For real-time text, RTCP reporting should be used according to general recommendations for RTCP."
So, it is there and can be used for detection of bad network conditions as mentioned in RFC 4103.

I hope this takes away all your concerns.

The one noted by Harald though, I would like to see rapid amendment of. As I understand it, it relates to that the way RFC 8864 sets up data channels with SDP is not compatible with the way it is done when using the WebRTC API. There will be collissions between parameters set by RFC 8864 that also the API expects to have control over. At least part of the problem is discussed in IETF as a possible ERRATA to RFC 8864.
So, it seems that without changes, two alternatives exist:

1. using all of RFC 8865 is possible if other ways to handle the data channel than through the W3C API.
2. use of RFC 8865 except the SDP part in section 4, with the WebRTC API.

This may solve the issue for many cases, but it is unfavourable that full use of RFC 8865 is not combinable with the WebRTC API
Since RFC 8864 is intended for general creation of WebRTC data channels and is already specified to be used for other applications than RTT, I think that the best would be if W3C and IETF mmusic got together and made RFC 8864 and the API work well together.

[dontcallmedom]

RFC8831 does not mandate use of reliable data channels for RTT; it lists "real-time text chat" as a use case where reliable data channels can be used.

So this is both not a requirement, and not particularly applicable to RTT in the sense of RFC 4103 which is not a generic chat mechanism but one that needs to fulfil specific requirements beyond what "chat" typically describes (e.g. for interactions with emergency services)

[gunnarhm]

It was RTT that was discussed when that sentence was agreed in RFC 8831. The "real-time text" part is sufficient to indicate that. The additional "chat" is just a common addition in this case not meaning that the conversation would need to be reduced to non-real time message-wise communication. Another example of the use of the"chat" word: video chat usually means a real-time conversational video communication. I though understand the risk for misunderstanding. I think we should avoid using both chat and messaging in relation to real time text, but it happens.

[cdh4u]

Also, as Harald noted, RFC 8865 is incompatible with the specification for the WebRTC data channel,
and as a result, it is not implementable.

That is not correct.

It is true that there is a case where SCTP stream-id collision can occur, if:

1. the offer contains actpass; AND
2. the application uses both DCEP and RFC 8864 at the same time

I am not aware of applications that would use both DCEP and RFC 8864 at the same time. WebRTC does not mandate usage of DCEP, AFAIK.

So, while there is a case (unlikely to occur, in my experience) where a collision could occur, that does not mean it is implementable.

[gunnarhm]

I see the problem always appearing when you try to create an association and open a channel and using actpass for DTLS at the same time. Then you cannot follow the even/odd rule of RFC 8864 section 6.1 because you do not know who is the client.
It could be solved by first creating the association so you get the DTLS client/server roles sorted out, and then open the channel when you know how to set the even/odd stream-ID.

Before this is resolved in IETF, I suggest that a recommendation is inserted at least in section 14 here that when RFC 8865 is used with the WebRTC API, RFC 8865 shall only be used as specified in sections 3,5,6 (=without section 4 (SDP)) until the problem with RFC 8864 is sorted out.

More visibility to this recommendation would be created by a similar ERRATA to RFC 8865, but that may be unfair because the problem is in RFC 8864.

[gunnarhm]

Answers on W3C comments on RFC 8865.docx

I have answered comments about RFC 8865 in the attached document and tried to compose a kind of implementors guide, explaining how RFC 8865 can be used without problems. The implementors guide may need adjustments.

Some of the comments above propose that the unreliable channel should have been used instead of the reliable, because then gateways to the RTP carried RFC 4103 + RFC9071 would be easier. I think that is not a favourable way to go, to require development of protocols for delivery in order and loss detection and correction just because of historical reasons for the case that a gateway may be needed in the path. Gatewaying is possible with the gateway considerations in RFC8865. It is better to use the modern features in WebRTC make life easier for the developer.

Looking forward to resolve this and get hints on the formulations in the implementors guide part in the attached document.

[edited by @dontcallmedom to include content of attachment inline]

Proposed responses to W3C WebRTC comments to CEN/CENELEC/ETSI eACC JTB about RFC 8865 as a specification for real time text (RTT) in WebRTC

W3C comment: Web technologies
For communication in Web Technologies, W3C and IETF have created the WebRTC concept [i.rfc8825]. IETF has published RFC 8865 [i.rfc8865] for implementation of RTT in web technologies using the WebRTC Data channel concept
RFC 8865 lacks important RTP packet fields for the synchronization of real-time audio and video with RTT.

Response: The real time characteristics of the intended use of RTT, audio and video is sufficient for the relaxed need for synchronization of RTT to the other media. Rapid delivery is enough.
Audio and video may need synchronization actions to achieve the goal of presenting video not more than 140 ms and not more than 80 ms after audio, because there is a value in having events creating sound heard and seen simultaneously. With RTT, there is no event at the transmitting side that is important to present in synch with the text presentation. For cases when RTT is sent as a written alternative to voice, it is of value for the user that the text is delivered rapidly, but no creation process can create the text in true synch with speech. Occasionally speech-to-text can create text while a long word is spoken, but more often the word can not be decided until a short while after it was uttered.
A good speech speed is 2 words per second, so text creation can usually not start until 500 ms after the beginning of the spoken word. Audio and video must be delivered within 400 ms after creation to be useful for real time communication, so it is already late for RTT to be truly synchronized. RTT creation by typing can easily cause longer delays. The RTT requirements specify that RTT shall be presented within one second after creation.
A typical sampling time for RTT is 300 ms, causing a mean delay of 150 ms after creation of each letter.
Synchronization of media can in real time communication only be achieved by delaying presentation of early received media to synchronize it with later received media. From the facts above, it is easily seen that it would totally destroy the real time characteristics of audio and video if their presentation was to be delayed to be synchronized with real time delivered RTT. Therefore the timestamps used in RTP are not needed for RTT transmission in the data channel of WebRTC, and presentation of RTT as soon as it has been received is sufficient for its relaxed synchronization requirements.

W3C comment: RFC 8865 is ambiguous as to what gateways need to do if there are holes due to losses when receiving RFC 4103 packets.

Response: The basic instructions for how to handle loss or errors during interworking with RFC 4103 RTP transported RTT can be found in section 6 “Gateway considerations” of RFC 8865. The implementor of a gateway will need to investigate the specifications of the protocols to be interworked. Further information will then be found in RFC 4103 about how to handle loss at reception and e.g. how long to wait for late packets.

W3C comment: To W3C’s knowledge, there is no mainstream implementation of RTT using RFC 8865.

Response: Right, only one partial implementation used in demonstrations is publicly known. Further implementations would be valuable.

W3C comment: There is currently a discussion in IETF related to RFC 8864, influencing RFC 8865. Use of RFC 8865 together with the WebRTC API may lead to inconsistent behaviour before that problem is solved. Basing RTT within WebRTC interoperability requirements on the current RFC 8865 provisions can result in inconsistent implementations, which can hinder interoperability and potentially put people with disabilities at risk.

Response: There is an unresolved Errata to RFC 8864 documented in https://www.rfc-editor.org/errata/rfc8864.
There has been an unfortunate low interest to resolve this problem. The mail thread from IETF mmusic can be seen here: https://mailarchive.ietf.org/arch/msg/mmusic/h6trpv04DHpU8UjxR1-LBXX7IxA/
The potential problem can be circumvented in different ways for different use cases, but that is not documented anywhere. A temporary solution until the ERRATA is resolved can be to document how to use RFC 8865 safely in different use cases.
The following use cases and implementation restrictions can be identified:

1. Use with just DCEP and browser based implementation: Avoid use of section 4, “SDP considerations” and use DCEP and the WebRTC API for channel establishment and transmission. Do not open more channels on the same association with any other means. If this method is used and the parameters for the channel specified in section 4 are needed in the application (cps, hlang-send, hlang-recv, sendonly, recvonly, sendrecv, and inactive), then these parameters need to be exchanged by other means than SDP.

2. Use with combined detailed SDP and WebRTC API. Make just an association first with ACTPASS. Use the assigned roles and create a channel with detailed SDP according to section 4 with ID:s following the usual even-odd rules. Then continue to use the WebRTC API specifying negotiated=true in the createDataChannel and following the instructions in the W3C WebRTC API for that case.
   (to be investigated: can further channels on the same association be opened by DCEP, or must all further channels on the same association be opened by detailed SDP?)

3. Use with other technologies than DCEP and WebRTC API: Create the associations with ACTPASS before creating the channels by SDP use as specified in RFC 8865 section 4. Or use any other out-of-band method for assigning streamID. Continue to use the channel according to the WebRTC data channel RFC:s but not by the W3C WebRTC API. Do not create more channels by DCEP and the WebRTC API on the same association.

W3C comment: W3C considers that RFC 8865 is currently not suitable and reliable for RTT within WebRTC. W3C strongly recommends to not base RTT within WebRTC requirements on the current RFC 8865 standard, and suggests coordination between relevant stakeholders to address the aforementioned architectural disparities for a consistent and reliable implementation of RTT within WebRTC.

Response: It is more important to create any acknowledged method for RTT use with WebRTC than to just use RFC 8865. However with the usage guides 1-3 above it may be seen that RFC 8865 can be regarded suitable for its task. Parallel efforts to perform verification projects and coordination between stakeholders to create or amend specifications seem to be the natural next steps