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

@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.


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


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

Received on Saturday, 16 March 2024 06:57:41 UTC