- From: aboba via GitHub <sysbot+gh@w3.org>
- Date: Mon, 28 Nov 2016 23:05:38 +0000
- To: public-webrtc-logs@w3.org
@vr000m In my experience, a common issue encountered with systems not sending RTCP is call drops during "hold" scenarios. The problem occurs when a peer that doesn't send RTCP stops sending RTP (e.g. after being notified that it has been put on hold) and the other peer interprets the lack of traffic as evidence that connectivity or endpoint liveness has been lost. Compliant WebRTC endpoints and gateways should not encounter these issues, as long as they implement updated specifications and weed out archaic RTP keepalive logic. For example: RFC 7675 (STUN consent freshness) is the mechanism used by WebRTC to determine endpoint liveness and consent - RTP keepalive mechanisms (described in RFC 6263) play no role in this. So for example, a legacy implementation using RTCP receipt as evidence of endpoint liveness is broken. ICE also does not utilize on RTP keepalive mechanisms. While RFC 5245 had Section 10 Keepalives which refers to RTP keepalive mechanisms discussed (and not recommended) in RFC 6263, this text has been removed in RFC 5245bis Section 8. So a WebRTC-compliant ICE implementation should not incorporate RTP keepalive logic. -- GitHub Notification of comment by aboba Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/951#issuecomment-263423597 using your GitHub account
Received on Monday, 28 November 2016 23:05:45 UTC