IETF Logo Mail Archive

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

Peter Musgrave <peter.musgrave@magorcorp.com> Tue, 25 May 2010 02:02 UTC

Return-Path: <peter.musgrave@magorcorp.com>
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C3A23A6964 for <avt@core3.amsl.com>; Mon, 24 May 2010 19:02:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.354
X-Spam-Level:
X-Spam-Status: No, score=0.354 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_50=0.001, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRYcuUXgtAoG for <avt@core3.amsl.com>; Mon, 24 May 2010 19:02:56 -0700 (PDT)
Received: from mail-yw0-f171.google.com (mail-yw0-f171.google.com [209.85.211.171]) by core3.amsl.com (Postfix) with ESMTP id 0017B3A67E2 for <avt@ietf.org>; Mon, 24 May 2010 19:02:55 -0700 (PDT)
Received: by ywh1 with SMTP id 1so1106996ywh.22 for <avt@ietf.org>; Mon, 24 May 2010 19:02:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.151.117.14 with SMTP id u14mr4800447ybm.184.1274752963659; Mon, 24 May 2010 19:02:43 -0700 (PDT)
Received: by 10.150.58.14 with HTTP; Mon, 24 May 2010 19:02:43 -0700 (PDT)
In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540C044FF3@xmb-sjc-215.amer.cisco.com>
References: <04CAD96D4C5A3D48B1919248A8FE0D540C044FF3@xmb-sjc-215.amer.cisco.com>
Date: Mon, 24 May 2010 22:02:43 -0400
Message-ID: <AANLkTil92EG-JUp8ylDtQ2-P2AOEQ4E28cXvDnPPNVcM@mail.gmail.com>
From: Peter Musgrave <peter.musgrave@magorcorp.com>
To: "Ali C. Begen (abegen)" <abegen@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: avt@ietf.org
Subject: Re: [AVT] FW: New Version Notification for draft-begen-avt-rtp-cnames-01
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 May 2010 02:02:57 -0000

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
>

v2.23.0 | Report a Bug | By Email