- From: Bernard Aboba via GitHub <sysbot+gh@w3.org>
- Date: Fri, 15 Mar 2024 21:58:21 +0000
- To: public-webrtc-logs@w3.org
@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. -- GitHub Notification of comment by aboba Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2931#issuecomment-2000531590 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 15 March 2024 21:58:23 UTC