Re: [AVTCORE] New Version Notification for draft-wu-avtcore-dynamic-pt-usage-00.txt

Colin Perkins <> Thu, 05 September 2013 12:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6233211E8191 for <>; Thu, 5 Sep 2013 05:28:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.299
X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id V1ugPT8eYHPT for <>; Thu, 5 Sep 2013 05:28:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4B87E21F9BD3 for <>; Thu, 5 Sep 2013 05:28:20 -0700 (PDT)
Received: from [] (port=50617 by with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <>) id 1VHYfY-0001n1-6K; Thu, 05 Sep 2013 13:28:17 +0100
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Colin Perkins <>
In-Reply-To: <>
Date: Thu, 5 Sep 2013 13:28:14 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <008201cea59e$aa9fd3a0$ffdf7ae0$> <> <015a01cea7d3$62c3cbe0$284b63a0$> <> <> <> <>
To: Qin Wu <>
X-Mailer: Apple Mail (2.1508)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Cc: "" <>
Subject: Re: [AVTCORE] New Version Notification for draft-wu-avtcore-dynamic-pt-usage-00.txt
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, 05 Sep 2013 12:28:32 -0000


On 5 Sep 2013, at 03:42, Qin Wu <> wrote:
> Hi,Colin:
> For motivation, May I point you to look at the following discussion on MMUSIC mailing list:
> I don’t know it is sufficient to just send some proposed IANA changes to IANA.
> Usually based on my understanding, a document is needed to let IANA to take action.

If your goal is simply to correct the registry to match RFC 5761, then I don't believe you need a new document. Just email the IANA, and ask them to make the correction to match RFC 5761.

> For your comments, I do think we give a new policy for new payload format coming up, please see my reply below.
> [Qin]: I disagree. just like two policies given in section 4 of RFC5761, one new policy we want to give in this draft is since the registry for RTP Payload types (PT) for standard audio and video 
> encodings  is closed, new payload format *MUST*   use dynamic payload type number assignment and Each new payload format is named by a registered media subtype. 
> However RFC3551 section 3.1 only said,to register additional encoding, you may either assign each encoding a short name, in some context, you refer to these encodings in the form of a MIME content-type, or assigns static RTP payload type numbers, or assign with dynamic payload type number.

I don't understand your message, but I do not believe there is a conflict between RFC 3551 and 5761.

> [Qin]: I see. However one thing I don’t understand, RFC5761only proposes Multiplexing RTP Data and Control Packets on a Single Port,
> Why two policies defined in RFC5761 can affect RFC3551 and proposed payload type usage can be used to update RFC3551.

Because the payload type in RTP and RTCP packet occupies the same byte, but is 7 bits in RTP and 8 bits in RTCP. When multiplexing RTP and RTCP packets on the same port it is necessary to specify how to distinguish. That is the reason why RFC 5761 updates RFC 3551.

Colin Perkins