Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)
draft-begen-avt-rtp-cnames-02
| Document | Type |
Replaced Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Authors | Ali C. Begen , Colin Perkins , Dan Wing | ||
| Last updated | 2010-08-04 (Latest revision 2010-05-24) | ||
| Replaced by | draft-ietf-avt-rtp-cnames | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Replaced by draft-ietf-avt-rtp-cnames | |
| 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, the CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams. For proper functionality, 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 these guidelines to allow endpoints to choose unique CNAMEs.
Authors
Ali C. Begen
Colin Perkins
Dan Wing
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)