Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)
draft-rescorla-avtcore-6222bis-00
Document | Type |
Replaced Internet-Draft
(candidate for avtcore WG)
Expired & archived
|
|
---|---|---|---|
Authors | Eric Rescorla , Ali C. Begen | ||
Last updated | 2013-03-11 (Latest revision 2012-10-13) | ||
Replaced by | draft-ietf-avtcore-6222bis | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Intended RFC status | (None) | ||
Formats | |||
Additional resources | Mailing list discussion | ||
Stream | WG state | Call For Adoption By WG Issued | |
Document shepherd | (None) | ||
IESG | IESG state | Replaced by draft-ietf-avtcore-6222bis | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
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. 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 specifies a replacement for those parts.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)