Re: [webrtc-pc] Update the accessibility section 14 to include RFC 8865 for real-time text in WebRTC data channel (#2931)

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? 

-- 
GitHub Notification of comment by gunnarhm
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2931#issuecomment-1924763575 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 2 February 2024 21:56:54 UTC