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

Sure. But, let's wait until WG approval and in the next revision, we can put that text in.

Thanks for the review.
-acbegen

> -----Original Message-----
> From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com]
> Sent: Tuesday, May 25, 2010 7:10 AM
> 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,
> 
> 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
> >> >
> >