Subject: [rtcweb] Fwd: RFC 6222 on Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)

From: Harald Alvestrand <[email-masked]>
Date: Fri, 15 Apr 2011 14:00:06 +0200

Since this RFC effectively tells us that we should abandon the "cname is 
user@host" convention, this RFC may be of interest to this WG.

Of special interest is the explicit statement that a CNAME is used to 
identify streams that need to be synchronized between multiple RTP 
sessions; I take it that the inverse is also true - that streams that do 
not need to be synchronized do not need to have the same CNAME.

                Harald

-------- Original Message --------
Subject: 	RFC 6222 on Guidelines for Choosing RTP Control Protocol 
(RTCP) Canonical Names (CNAMEs)
Date: 	Thu, 14 Apr 2011 11:26:24 -0700 (PDT)
From: 	[email-masked]
To: 	[email-masked], [email-masked]
CC: 	[email-masked], [email-masked]

A new Request for Comments is now available in online RFC libraries.

         RFC 6222

         Title:      Guidelines for Choosing RTP Control
                     Protocol (RTCP) Canonical Names (CNAMEs)
         Author:     A. Begen, C. Perkins,
                     D. Wing
         Status:     Standards Track
         Stream:     IETF
         Date:       April 2011
         Mailbox:    [email-masked],
                     [email-masked],
                     [email-masked]
         Pages:      9
         Characters: 20393
         Updates:    RFC3550

         I-D Tag:    draft-ietf-avt-rtp-cnames-05.txt

         URL:        http://www.rfc-editor.org/rfc/rfc6222.txt

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.  [STANDARDS-TRACK]

This document is a product of the Audio/Video Transport Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
   http://www.ietf.org/mailman/listinfo/ietf-announce
   http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
Association Management Solutions, LLC

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 18 Apr 2011 11:57:18 +0200

Harald and others,

This is just one of many things we recommend in our draft on how RTP
should be used in the RTCWEB context.
https://datatracker.ietf.org/doc/draft-perkins-rtcweb-rtp-usage/

We do like to get feedback on our document.

> not need to be synchronized do not need to have the same CNAME.

Yes, it is mostly true. And if ones intention is to provide sources that
you don't want to force synchronization with, then using different
CNAMEs are necessary. However, there are a bit of overloading on the
CNAME field that makes one have to be a bit careful when using different
CNAMEs from the same end-point. And I would like to add that
synchronization of SSRCs with the same CNAME is not only between RTP
sessions, but also within the RTP session.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: David Singer <[email-masked]>
Date: Mon, 18 Apr 2011 11:10:14 -0700

> sessions, but also within the RTP session.

If I am doing a point-to-point call, and I have the connectivity established (i.e. IP addresses and the like), why should I trouble at all with CNAME?  And, indeed, are there privacy concerns with it (well, there are with using <userid>@<host>, I rather suspect).  Can the CNAME problem be handled when aggregation happens?

David Singer
Multimedia and Software Standards, Apple Inc.

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 19 Apr 2011 11:05:28 +0200

David Singer skrev 2011-04-18 20:10:
> 
> If I am doing a point-to-point call, and I have the connectivity
> established (i.e. IP addresses and the like), why should I trouble at
> all with CNAME?  And, indeed, are there privacy concerns with it
> (well, there are with using <userid>@<host>, I rather suspect).  Can
> the CNAME problem be handled when aggregation happens?

Because you don't know when a peer is a single user, or a conference
bridge. In the later case of you will need the cname. Also for point to
point you might need it if you have multiple sources that should or
should not be synchronized. The point of the new RFC is that the cname
can be set session specific, by drawing a random number that is being
used. Thus you can avoid the downsides of CNAME from privacy point of
view, and the generation aspects.

cheers

Magnus Westerlund

---

From: "Roni Even" <[email-masked]>
Date: Wed, 20 Apr 2011 08:26:15 +0300

Hi,
I think that CNAMEs are also useful for third party monitors as described in
RFC 3550
Roni Even

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Magnus Westerlund
> Sent: Tuesday, April 19, 2011 12:05 PM
> To: David Singer
> Cc: [email-masked]
> Subject: Re: [rtcweb] Fwd: RFC 6222 on Guidelines for Choosing RTP
> Control Protocol (RTCP) Canonical Names (CNAMEs)
> 
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb