Subject: [AVTCORE] FW: New Version Notification for draft-rescorla-avtcore-6222bis-00.txt

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sun, 14 Oct 2012 02:32:58 +0000

We have submitted a draft to replace 6222. This document is a new version
of 6222 and has the fixes proposed by Eric in the last meeting.

Comments are welcome.
-acbegen

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Saturday, October 13, 2012 10:30 PM
To: "Ali C. Begen" <[email-masked]>
Cc: "Eric com>" <[email-masked]>
Subject: New Version Notification for draft-rescorla-avtcore-6222bis-00.txt

>
>A new version of I-D, draft-rescorla-avtcore-6222bis-00.txt
>has been successfully submitted by Ali Begen and posted to the
>IETF repository.
>
>Filename:	 draft-rescorla-avtcore-6222bis
>Revision:	 00
>Title:		 Guidelines for Choosing RTP Control Protocol (RTCP) Canonical
>Names (CNAMEs)
>Creation date:	 2012-10-14
>WG ID:		 Individual Submission
>Number of pages: 10
>URL:             
>http://www.ietf.org/internet-drafts/draft-rescorla-avtcore-6222bis-00.txt
>Status:          
>http://datatracker.ietf.org/doc/draft-rescorla-avtcore-6222bis
>Htmlized:        
>http://tools.ietf.org/html/draft-rescorla-avtcore-6222bis-00
>
>
>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, 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.  RFC 6222 was published to update those
>   guidelines to allow endpoints to choose unique RTCP CNAMEs.
>   Unfortunately, later investigations showed that some parts of the new
>   algorithms were unnecessarily complicated and/or ineffective.  This
>   document specifies a replacement for those parts.
>
>                  
>        
>
>
>The IETF Secretariat
>