webrtc-pc
webrtc-pc copied to clipboard
w3c
Update the accessibility section 14 to include RFC 8865 for real-time text in WebRTC data channel
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.
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?
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.
Seems better to address this with an explainer talking about how the APIs of WEBRTC relate to applications that want to do timed text.
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.
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".
Per comment https://github.com/w3c/webrtc-pc/issues/2931#issuecomment-1900720165, 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.)
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.
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.
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.
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.
@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
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.
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.
@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.
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?
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."
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.
@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".
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 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.
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.
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.
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.
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.
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?
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.
Yes, right, this issue is about updating section 14. I provided a proposal above in https://github.com/w3c/webrtc-pc/issues/2931#issuecomment-1921766198 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 https://github.com/w3c/webrtc-pc/issues/2931#issuecomment-1924763575
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.
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.