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

Qin Wu <> Thu, 05 September 2013 02:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2A9F021F99DE for <>; Wed, 4 Sep 2013 19:43:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.255
X-Spam-Status: No, score=-6.255 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id G7jsn7RckJ7p for <>; Wed, 4 Sep 2013 19:42:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EB13421F99DC for <>; Wed, 4 Sep 2013 19:42:54 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.5-GA FastPath queued) with ESMTP id AVB32223; Thu, 05 Sep 2013 02:42:51 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 5 Sep 2013 03:42:12 +0100
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 5 Sep 2013 03:42:27 +0100
Received: from ([]) by ([]) with mapi id 14.01.0323.007; Thu, 5 Sep 2013 10:42:20 +0800
From: Qin Wu <>
To: Colin Perkins <>
Thread-Topic: [AVTCORE] New Version Notification for draft-wu-avtcore-dynamic-pt-usage-00.txt
Thread-Index: AQHOqb3YTAyRQvjP/EGKbY79ZB4wtpm2X60A
Date: Thu, 5 Sep 2013 02:42:19 +0000
Message-ID: <>
References: <> <008201cea59e$aa9fd3a0$ffdf7ae0$> <> <015a01cea7d3$62c3cbe0$284b63a0$> <> <> <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA43BDB385nkgeml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
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 02:43:00 -0000

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.

For your comments, I do think we give a new policy for new payload format coming up,
please see my reply below.

From: Colin Perkins []
Sent: Thursday, September 05, 2013 6:27 AM
To: Qin Wu
Cc: Roni Even;
Subject: Re: [AVTCORE] New Version Notification for draft-wu-avtcore-dynamic-pt-usage-00.txt


Comments inline.


On 4 Sep 2013, at 02:48, Qin Wu <<>> wrote:

From:<> [<>] On Behalf Of Colin Perkins
Sent: Wednesday, September 04, 2013 12:20 AM
To: Roni Even
Subject: Re: [AVTCORE] New Version Notification for draft-wu-avtcore-dynamic-pt-usage-00.txt

Hi Roni,

On 2 Sep 2013, at 12:55, Roni Even <<>> wrote:
Hi Colin,
The major motivation is to update the closed IANA registry that points to RFC 3551 and does not have the right allocations by referring to this document , I have the wrong pointer in the draft. This is based on the email thread started with the attached email.

I would have thought that could be resolved with an email to IANA, rather than a new draft, since all you're doing is updating the registry to match the published RFCs.

[Qin]: One of motivation to write this draft, I think , is to avoid running out of possible payload type space in case of multiple RTP
   streams in a single session, we need some guideline on how to use dynamic payload type number space.

RFC 3551 and 5761 provide that guidance already. Your draft just seems to repeat that guidance.

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

One example, is RFC2032 is obsoleted by RFC4587, RTCP Control Packet types 192,193 should be called back and recycled for
dynamic payload number allocation when payload number space is a issue, since one principle defined in RFC5761 is
"for each RTP payload type (PT), PT+128 is distinct from the RTCP packet types used."

This seems to be the only change compared to RFC 5761: to allow RTP payload types 64 and 65 to be used as a last resort. I'm unconvinced this is worth the trouble, but maybe.

Another open issue we want to solve is as pointed by section 4, editor note, can we recommend re-use of payload type in
bundled m-lines if they map to the same payload format here, if yes, that is something different from RFC3551.

That's an issue for the BUNDLE specifications, and not something that should go into a draft updating RFC 3551.

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

The other reason is to clarify which payload types from the range 0-95 can be used for dynamic mapping and in what order. This is based on the MMUSIC session in Berlin and the open issue in section of

But, the draft just seems to repeat the guidelines in RFC 5761 and 3551. The only difference seems to be to give an explicit order in which the unassigned payload type numbers are to be used, which seems unnecessary.

[Qin] Yes, explicit order is not necessary, however that is not what we proposed in this draft( i.e., to give the order).

One thing I am not sure is do you believe Support for multiple RTP

 streams in a single session which is recommended in order

to reduce the number of open transport connections can

 exhaust the payload type space.

I'm not convinced that exhausting the RTP payload type space is a real problem in practice. However, even if it is a real problem, I don't think the additional two payload types made available by draft will solve it.

[Qin]: Agree. I think section 3 of this draft for "update to RFC3551" can go away now.

Colin Perkins