W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > November 2016

Re: [webrtc-pc] RTCP is mandatory, but not always implemented in legacy systems

From: aboba via GitHub <sysbot+gh@w3.org>
Date: Mon, 28 Nov 2016 23:05:38 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-263423597-1480374335-sysbot+gh@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

This archive was generated by hypermail 2.3.1 : Wednesday, 9 October 2019 15:14:51 UTC