Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: RFC Editor <firstname.lastname@example.org>, avtcore mailing list <email@example.com>, avtcore chair <firstname.lastname@example.org> Subject: Protocol Action: 'Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)' to Proposed Standard (draft-ietf-avtcore-6222bis-06.txt) The IESG has approved the following document: - 'Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)' (draft-ietf-avtcore-6222bis-06.txt) as Proposed Standard This document is the product of the Audio/Video Transport Core Maintenance Working Group. The IESG contact persons are Richard Barnes and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-avtcore-6222bis/
Technical Summary The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a persistent transport-level identifier for an RTP endpoint. While the Synchronization Source (SSRC) identifier of an RTP endpoint may change if a collision is detected or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams. For proper functionality, RTCP CNAMEs should be unique within the participants of an RTP session. However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard are insufficient to achieve this uniqueness. RFC 6222 was published to update those guidelines to allow endpoints to choose unique RTCP CNAMEs. Unfortunately, later investigations showed that some parts of the new algorithms were unnecessarily complicated and/or ineffective. This document addresses these concerns and replaces RFC 6222. Working Group Summary The requirements for this replacement of RFC 6222 came from RTCWEB WG, which identified the linkability and privacy issue of the previous random method. There was strong WG consensus to address this issue. The method of addressing it, using a cryptographic random number generator, was obvious. The main concern in WG last call has been around the clarity of the motivation for the update. Document Quality The Shepherd assumes that this will see significant implementation, especially initially in any WebRTC implementations. The document has gotten a fair amount of reviews in the WG last call. Personnel Magnus Westerlund is the Document Shepherd. Richard Barnes is the Responsible Area Director.