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

Qin Wu <> Wed, 04 September 2013 01:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A1FC321E8123 for <>; Tue, 3 Sep 2013 18:49:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LNTwykCwUDdD for <>; Tue, 3 Sep 2013 18:49:55 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7B83621E811C for <>; Tue, 3 Sep 2013 18:49:54 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.5-GA FastPath queued) with ESMTP id AVA33702; Wed, 04 Sep 2013 01:49:52 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Wed, 4 Sep 2013 02:48:06 +0100
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Wed, 4 Sep 2013 02:48:19 +0100
Received: from ([]) by ([]) with mapi id 14.01.0323.007; Wed, 4 Sep 2013 09:48:10 +0800
From: Qin Wu <>
To: Colin Perkins <>, Roni Even <>
Thread-Topic: [AVTCORE] New Version Notification for draft-wu-avtcore-dynamic-pt-usage-00.txt
Thread-Index: AQHOp8RsvL6G0EkcGUWNGcXvM1i/kZmx0RqAgAHcH4CAARv+gA==
Date: Wed, 4 Sep 2013 01:48:10 +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_B8F9A780D330094D99AF023C5877DABA43BDAD25nkgeml501mbschi_"
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: Wed, 04 Sep 2013 01:49:59 -0000


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.

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

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.

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.

That's something brought up in the open issue part of draft-roach-mmusic-unified-plan-00.



-----Original Message-----
From: Colin Perkins [<>]
Sent: 02 September, 2013 1:07 PM
To: Roni Even
Cc:<> WG
Subject: Re: [AVTCORE] New Version Notification for draft-wu-avtcore-


Can you explain what's new in this draft? As far as I can tell, it just
repeats the

guidance in RFCs 3551 and 5761.


On 30 Aug 2013, at 17:33, Roni Even <<>> wrote:

Apologize for the cross posting. Please comment only in avtcore
mailing list

We have submitted a draft that clarifies the usage of dynamic payload


This is based on email discussion in MMUSIC Thanks Roni Even

-----Original Message-----
From:<> [<>]
Sent: 30 August, 2013 7:29 PM
To: Qin Wu; Wenson Wu; Rachel Huang; Roni Even; Rachel Huang
Subject: New Version Notification for

A new version of I-D, draft-wu-avtcore-dynamic-pt-usage-00.txt
has been successfully submitted by Qin Wu and posted to the IETF

Filename:         draft-wu-avtcore-dynamic-pt-usage
Revision:         00
Title:                Guideline for dynamic payload type number usage

Creation date: 2013-08-30
Group:             Individual Submission
Number of pages: 5




 The RTP Profile for Audio and Video Conferences with Minimal Control
 (RTP/AVP) is the basis for many other profiles, such as the Secure
 Real-time Transport Protocol (RTP/SAVP), the Extended RTP Profile for
 Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/
 AVPF), and the Extended Secure RTP Profile for RTCP-Based Feedback
 (RTP/SAVPF).  This document updates RFC 3551 and provide guidelines
 for payload type number usage policy.

Please note that it may take a couple of minutes from the time of
submission until the htmlized version and diff are available at

The IETF Secretariat

Audio/Video Transport Core Maintenance

Colin Perkins

<Mail Attachment.eml>

Colin Perkins