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

"Mo Zanaty (mzanaty)" <> Thu, 25 April 2013 18:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0183D21F9671; Thu, 25 Apr 2013 11:57:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.539
X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id H47H+Q5t9hUy; Thu, 25 Apr 2013 11:57:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0984521F8411; Thu, 25 Apr 2013 11:57:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2628; q=dns/txt; s=iport; t=1366916268; x=1368125868; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=lH8OVXyc9gZ8+6CgKDUB+oAEjpSEmgJ2Kvx+/RESnqk=; b=IZ2b/i25HunEJajkF4IQSoB9sHEQMQ3DDHRxRnBmn2YrzvQ5MpaOpUp7 n4J/dtuDLcdcoBVPuW78zDwIpnOLX165rCGxndHTSmbzlMRucSg+d6XWb 5I2xvPTVZynCV1rz3ECVCsh2Gp5tud60/LlFhKGBlLXzqSJAITKOtbEMY 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.87,552,1363132800"; d="scan'208";a="200150634"
Received: from ([]) by with ESMTP; 25 Apr 2013 18:57:47 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r3PIvlAR031810 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Apr 2013 18:57:47 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Thu, 25 Apr 2013 13:57:46 -0500
From: "Mo Zanaty (mzanaty)" <>
To: "Dale R. Worley" <>, "" <>, "" <>, "Ali C. Begen (abegen)" <>
Thread-Topic: [MMUSIC] Should we update the IANA registry to reflect RFC 5761?
Thread-Index: AQHOQdoLz3rs6rgYyUO2pptDF+kp/pjnRTkw
Date: Thu, 25 Apr 2013 18:57:46 +0000
Message-ID: <>
References: <>
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
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: Thu, 25 Apr 2013 18:57:49 -0000

I agree with the IANA update below for clarity. But practically speaking, PAYLOAD will never assign another static payload, so we are effectively limited to the dynamic range for all modern codecs unless PAYLOAD decides to reallocate 35-63 from static to dynamic. I could only see that happening if products really need to support >32 codecs. (True codecs, not demux IDs for different streams in bundles.)


-----Original Message-----
From: [] On Behalf Of Dale R. Worley
Sent: Thursday, April 25, 2013 1:26 PM
Subject: [MMUSIC] Should we update the IANA registry to reflect RFC 5761?

I was looking at the IANA registry "RTP Payload types (PT) for
standard audio and video encodings"
to see what the allowed dynamic payload types are, and what PTs are
reserved to avoid confusion with RTCP.  The unassigned range is:

35-71   Unassigned
72-76   Reserved for RTCP conflict avoidance    [RFC3551]
77-95   Unassigned
96-127  dynamic                                 [RFC3551]

Unfortunately, this doesn't reflect RFC 5761 ("Multiplexing RTP Data
and Control Packets on a Single Port"), which gives these
instructions in section 4:

   Given these constraints, it is RECOMMENDED to follow the guidelines
   in the RTP/AVP profile [7] for the choice of RTP payload type values,
   with the additional restriction that payload type values in the range
   64-95 MUST NOT be used.  Specifically, dynamic RTP payload types
   SHOULD be chosen in the range 96-127 where possible.  Values below 64
   MAY be used if that is insufficient, in which case it is RECOMMENDED
   that payload type numbers that are not statically assigned by [7] be
   used first.

Since the entire range 64 to 95 is now reserved, the table should

35-63   Unassigned
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]

IMHO, it would be helpful to get this table up to date with regard to
the RFCs, even though it is marked "Closed".

Do people agree with me on this?  (And how do we go about it?  I
assume that the AD can route it to IANA.)

(This also limits us to 61 PTs, which is another matter.)

mmusic mailing list