Re: [AVTCORE] Should we update the IANA registry to reflect RFC 5761? (Dale R. Worley) Thu, 12 September 2013 18:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8855D21E81E9 for <>; Thu, 12 Sep 2013 11:07:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.377
X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qm9uX0LjxUnh for <>; Thu, 12 Sep 2013 11:07:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5519111E814D for <>; Thu, 12 Sep 2013 11:06:42 -0700 (PDT)
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r8CI4a7O003751; Thu, 12 Sep 2013 14:04:38 -0400
Received: from ( []) by (8.13.6/8.12.8) with ESMTP id r8CI4Z9b1016912; Thu, 12 Sep 2013 14:04:35 -0400 (EDT)
Received: (from worley@localhost) by (8.13.6/8.13.6/Submit) id r8CI4ZQW1010065; Thu, 12 Sep 2013 14:04:35 -0400 (EDT)
Date: Thu, 12 Sep 2013 14:04:35 -0400 (EDT)
Message-Id: <>
From: (Dale R. Worley)
Sender: (Dale R. Worley)
To: "Roni Even" <>
In-reply-to: <026301ceae62$8ff6d770$afe48650$> (
References: <> <026301ceae62$8ff6d770$afe48650$>
Subject: Re: [AVTCORE] Should we update the IANA registry to reflect RFC 5761?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 12 Sep 2013 18:07:35 -0000

> From: "Roni Even" <>
> We started working in it see
> Please review

I wasn't on the mailing list when that came out!

It looks like it does what is needed.

I have the following comments on draft-wu-avtcore-dynamic-pt-usage-01:

1. As others have said, the WG can simply instruct IANA to update the
assignment table, but since we want to prescribe the order of
allocation of dynamic PTs, and that requires an RFC, we might as well
put the table update in the same RFC.

2. Given the complexity of the considerations surrounding PTs 64 and
65, there should be a section that explains all of the history and

3. In section 3, the sequence in which payload types should be
allocated is given all in one dense paragraph.  It would probably be
clearer if the allocation order was broken out as an explicit list.
If I just separate the sentences that are now in the draft, there are
*five* groups to be used in order:

   Applications SHOULD first use values in the range for dynamic
   payload types [96-127].

   Those applications which need to define more than 32 dynamic
   payload types MAY bind codes below 96, in which case it is
   RECOMMENDED that unassigned payload type numbers [35-63] followed
   by ...

   ... [20-24], 27, [29-30].

   If more payload type numbers are needed, the application may use
   the reserved values 1,2,19 (see [RFC3551]for reserved values) and
   64, 65 (see [RFC5761]for reserved value).

   If more Payload type numbers are needed, then applications may
   override the static types[0, 3-18,25,26,28] map encodings to these
   defined static payload type but this may cause problems for
   applications that may assume a specific payload format based on the
   Payload Type ignoring the mapping in the signaling.