Re: [MMUSIC] Should we update the IANA registry to reflect RFC 5761?

"Roni Even" <> Mon, 13 May 2013 08:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 92CB621F92F4; Mon, 13 May 2013 01:46:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.567
X-Spam-Level: *
X-Spam-Status: No, score=1.567 tagged_above=-999 required=5 tests=[AWL=4.166, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oilvrP2zspXG; Mon, 13 May 2013 01:46:48 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::232]) by (Postfix) with ESMTP id 6979321F9347; Mon, 13 May 2013 01:46:47 -0700 (PDT)
Received: by with SMTP id ey16so655943wid.5 for <multiple recipients>; Mon, 13 May 2013 01:46:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=iXKwtxnTPiI2xxXBpSymcVg5qcSq7NWo+elt09Koacs=; b=QczqhHcknho4ql9YvyzBr6JMUn8ohLVtVg3JRnUEd4FWeEheILfcG9UEzCXGafSbWr 9Jt1i1+hh9WVznXmQBRhBv5V5BC65x9f25QffOw/wy808wNZMA9EgRrXDq2t6FmdStAC e8n+UM4GZdnQnFfUxxAUEZcV2fI34Thtog8K3hLy/O8W7gkG9exs6W3dPk5ibiKAMLvN uDXariX/Xr7bnnK4kZk6SjNTPMClEJ71m9nf8WJobCngyrkdxWoN5H1Ws6tUiuHb9izd on2Tlq4ZOpqSaUQGkTew6RGaPmlqOrwAAQKSehIgL73dNbvjfTY28IFafTrA7fci9VbV iDhQ==
X-Received: by with SMTP id bu6mr17072329wib.34.1368434806557; Mon, 13 May 2013 01:46:46 -0700 (PDT)
Received: from RoniE ( []) by with ESMTPSA id ay7sm6551238wib.9.2013. for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 13 May 2013 01:46:45 -0700 (PDT)
From: "Roni Even" <>
To: "'Magnus Westerlund'" <>, "'Dale R. Worley'" <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Date: Mon, 13 May 2013 11:45:51 +0300
Message-ID: <008d01ce4fb6$47860250$d69206f0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHhSi4rMF59GtWVZLm6eUv/wmHmTAG3YjvyAXHa8loCRvWqfgHvq+67AYZd+3eYlaWWgA==
Content-Language: en-us
Subject: Re: [MMUSIC] Should we update the IANA registry to reflect RFC 5761?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 May 2013 08:46:48 -0000

I am also concerned about putting in the registries the different case where
RTCP mux is used or not. I think the best we can do is add a general note in
the registry point at RFC5761 saying that it provides clarification on using
the pt type numbers in different cases.

-----Original Message-----
From: [] On Behalf Of
Magnus Westerlund
Sent: 13 May, 2013 11:03 AM
To: Dale R. Worley
Subject: Re: [MMUSIC] Should we update the IANA registry to reflect RFC


Ok, I think you have convinced me that there is a point in updating or at
least clarifying the registry. However, I think it is important that one
makes clear the difference between using RTP/RTCP MUX and not. The
considerations for doing static allocations which was this registries
original purpose and the the usage of dynamic PT assignments with and
without RTP/RTCP MUX is quite different.

>From my perspective I don't see major issues to use all 128 values of PT
field if needed when doing dynamic allocation and not using RTP/RTCP MUX.
Yes, I would use the one that collide with SR/RR RTCP packets last, but I
still would use them. The thing that is getting screwed up are classifier
filters, not the actual end-points.

Clearly if using RTP/RTCP MUX you need to avoid the PT values corresponding
to RTCP packets types in use. Especially if reduced size RTCP is used.

I also think you should check with IANA if one can touch a closed registry
at all, or if we are restricted to clarifying notes for the registry.



On 2013-04-26 20:20, Dale R. Worley wrote:
>> From: Magnus Westerlund <>
>> Regarding the IANA, Mo you have correctly identified the registry as 
>> closed and Adam pointed to the relevant text. Is this level of 
>> indirection so problematic that this registry needs a Note to the effect?
> (cleaning up my proposal)
> I use the IANA registries as the reference for how the various number 
> spaces are managed.  The current final rows of the Payload Types table
> read:
>     35-71   Unassigned
>     72-76   Reserved for RTCP conflict avoidance    [RFC3551]
>     77-95   Unassigned
>     96-127  dynamic                                 [RFC3551]
> I find these to be problematic in several ways:
> 1) RFC 5761 is not mentioned at all, despite that it provides 
> important modifications of the governing text in RFC 3551.  This is a 
> practical problem:  Note that Adam quoted the text in RFC 3551, not 
> the text in RFC 5761, and the 3551 text is now incorrect.
> 2) The range that is reserved for RTCP avoidance is not specified 
> correctly.  It's true that the rest of the RTCP avoidance range is 
> marked "Unassigned", but in the context of RFC 3551, that suggests 
> that they can be used as a secondary dynamic assignment area.
> 3) The range 35-71 should be marked more clearly as the secondary 
> dynamic assignment area.
> Because of this, I suggest the following changes to this registry:
> 1) The "Reference" section should be changed from "[RFC3551]" to 
> "[RFC5761][RFC3551]".
> 2) The final rows should be changed to
>     35-63   Unassigned/secondary dynamic area       [RFC5761]
>     64-71   Reserved for RTCP conflict avoidance    [RFC5761]
>     72-76   Reserved for RTCP conflict avoidance    [RFC3551]
>     77-95   Reserved for RTCP conflict avoidance    [RFC5761]
>     96-127  Dynamic                                 [RFC3551]
> Dale
> _______________________________________________
> mmusic mailing list


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:

mmusic mailing list