Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)
RFC 6222
Document | Type |
RFC - Proposed Standard
(April 2011; No errata)
Obsoleted by RFC 7022
Updates RFC 3550
|
|
---|---|---|---|
Authors | Colin Perkins , Ali Begen , Dan Wing | ||
Last updated | 2015-10-14 | ||
Replaces | draft-begen-avt-rtp-cnames | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 6222 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Robert Sparks | ||
Send notices to | (None) |
Internet Engineering Task Force (IETF) A. Begen Request for Comments: 6222 Cisco Updates: 3550 C. Perkins Category: Standards Track University of Glasgow ISSN: 2070-1721 D. Wing Cisco April 2011 Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) Abstract 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. This memo updates those guidelines to allow endpoints to choose unique RTCP CNAMEs. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6222. Begen, et al. Standards Track [Page 1] RFC 6222 Choosing an RTCP CNAME April 2011 Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction ....................................................2 2. Requirements Notation ...........................................2 3. Deficiencies with Earlier Guidelines for Choosing an RTCP CNAME ......................................................3 4. Choosing an RTCP CNAME ..........................................3 4.1. Persistent RTCP CNAMEs versus Per-Session RTCP CNAMEs ......4 4.2. Requirements ...............................................5 5. Procedure to Generate a Unique Identifier .......................6 6. Security Considerations .........................................7 6.1. Considerations on Uniqueness of RTCP CNAMEs ................7 6.2. Session Correlation Based on RTCP CNAMEs ...................7 7. Acknowledgments .................................................8 8. References ......................................................8 8.1. Normative References .......................................8 8.2. Informative References .....................................9 1. Introduction In Section 6.5.1 of the RTP specification, [RFC3550], there are a number of recommendations for choosing a unique RTCP CNAME for an RTP endpoint. However, in practice, some of these methods are not guaranteed to produce a unique RTCP CNAME. This memo updates guidelines for choosing RTCP CNAMEs, superseding those presented in Section 6.5.1 of [RFC3550]. 2. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Begen, et al. Standards Track [Page 2] RFC 6222 Choosing an RTCP CNAME April 2011 3. Deficiencies with Earlier Guidelines for Choosing an RTCP CNAME The recommendation in [RFC3550] is to generate an RTCP CNAME of the form "user@host" for multiuser systems, or "host" if the username is not available. The "host" part is specified to be the fullyShow full document text