Re: [AVT] FW: New Version Notification for draft-begen-avt-rtp-cnames-01

Hi Ali,

I suppose it is covered by the statement in 4.1
"To provide a binding across multiple media tools
   used by one participant in a set of related RTP sessions, the CNAME
   SHOULD be fixed for that participant. "

But I would also suggest that a bullet point in the guidelines might
help make this more explicit. Something like:
"An endpoint which is emitting multiple related streams which require
synchronization at the receiver SHOULD use a persistent CNAME . "

Peter Musgrave

On Mon, May 24, 2010 at 10:09 PM, Ali C. Begen (abegen)
<abegen@cisco.com> wrote:
> Hi Peter,
>
> Indeed. Could you have a look at today's revision? It discusses when per-session or persistent cnames should be used.
>
> http://tools.ietf.org/html/draft-begen-avt-rtp-cnames-02
>
> -acbegen
>
>> -----Original Message-----
>> From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com]
>> Sent: Monday, May 24, 2010 10:03 PM
>> To: Ali C. Begen (abegen)
>> Cc: avt@ietf.org
>> Subject: Re: [AVT] FW: New Version Notification for draft-begen-avt-rtp-cnames-01
>>
>> Hi Ali,
>>
>> In the context of synchronizing multiple media flows (multiple audio
>> streams or audio+video) from a unique source - cnames can be useful to
>> determine which media streams are from a common node and need to be
>> aligned in time for playback. The use of a session specific cname
>> would break this usage (or we would require e.g the audio and video
>> subsystems to agree on a session specific cname - which is an
>> implementation constraint I would prefer to avoid).
>>
>> Is it worth mentioning that session specific cnames are not suitable
>> in cases such as this?
>>
>> Peter Musgrave
>>
>>
>>
>> On Wed, May 5, 2010 at 10:34 AM, Ali C. Begen (abegen) <abegen@cisco.com> wrote:
>> > Here is the new version of the CNAME draft.
>> >
>> > http://www.ietf.org/id/draft-begen-avt-rtp-cnames-01.txt
>> >
>> > We took the comments into consideration. Hopefully, the text is almost complete now. Feedback is
>> welcome.
>> >
>> > -acbegen
>> >
>> > -----Original Message-----
>> > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]
>> > Sent: Wednesday, May 05, 2010 10:31 AM
>> > To: Ali C. Begen (abegen)
>> > Cc: csp@csperkins.org
>> > Subject: New Version Notification for draft-begen-avt-rtp-cnames-01
>> >
>> >
>> > A new version of I-D, draft-begen-avt-rtp-cnames-01.txt has been successfully submitted by Ali Begen
>> and posted to the IETF repository.
>> >
>> > Filename:        draft-begen-avt-rtp-cnames
>> > Revision:        01
>> > Title:           Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)
>> > Creation_date:   2010-05-05
>> > WG ID:           Independent Submission
>> > Number_of_pages: 6
>> >
>> > 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
>> > recommendations for choice of the RTCP CNAME provided in RFC 3550 are
>> > insufficient to achieve this uniqueness.  This memo updates the
>> > guidelines in RFC 3550 to allow endpoints to choose unique CNAMEs.
>> >
>> >
>> >
>> > The IETF Secretariat.
>> >
>> >
>> > _______________________________________________
>> > Audio/Video Transport Working Group
>> > avt@ietf.org
>> > https://www.ietf.org/mailman/listinfo/avt
>> >
>