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

"Mo Zanaty (mzanaty)" <> Thu, 12 September 2013 18:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2FED811E8239 for <>; Thu, 12 Sep 2013 11:25:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id az+Zw1C72Kkp for <>; Thu, 12 Sep 2013 11:24:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CD48011E80D3 for <>; Thu, 12 Sep 2013 11:24:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2489; q=dns/txt; s=iport; t=1379010292; x=1380219892; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/qszDN+l2YMqVgp7WPZlTcg9G5/gYsbwlkqChTv8anU=; b=Z+4n9BhhwpRLchW0ZmHrWqGuofs2tGC3Mo7dx0fnoHQX2VdCa9/ubwBq jMrik0JPCG4onJy+mDNWtzxuZFkpn14oJmPPEekH4ll3hQ9PvexAVUvbh qR67gxTDqeOQLiFKXUtq1blL3Mg5XcTTB8gwR6ZhPzPsFUbqyGikcY9vM 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.90,892,1371081600"; d="scan'208";a="258982656"
Received: from ([]) by with ESMTP; 12 Sep 2013 18:24:47 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r8CIOQDv028483 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Sep 2013 18:24:26 GMT
Received: from ([]) by ([fe80::200:5efe:]) with mapi id 14.02.0318.004; Thu, 12 Sep 2013 13:22:36 -0500
From: "Mo Zanaty (mzanaty)" <>
To: "Dale R. Worley" <>, Roni Even <>
Thread-Topic: [AVTCORE] Should we update the IANA registry to reflect RFC 5761?
Thread-Index: AQHOr+NGw8rlqP8Zu0ilfkiVEfZTCpnCaSVg
Date: Thu, 12 Sep 2013 18:22:34 +0000
Message-ID: <>
References: <> <026301ceae62$8ff6d770$afe48650$> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
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:25:07 -0000

Hi Dale,
I think RFC 5761 already addresses your points below, clearly and concisely.


-----Original Message-----
From: [] On Behalf Of Dale R. Worley
Sent: Thursday, September 12, 2013 2:05 PM
To: Roni Even
Subject: Re: [AVTCORE] Should we update the IANA registry to reflect RFC 5761?

> 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.

Audio/Video Transport Core Maintenance