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
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Replaces | draft-begen-avt-rtp-cnames | ||
| Stream | IETF | ||
| Formats | plain text 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 fully
Show full document text