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.