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

[Qin Wu <[e-mail]>]

Hi,Colin:
For motivation, May I point you to look at the following discussion on MMUSIC mailing list:
http://www.ietf.org/mail-archive/web/payload/current/msg00542.html
http://www.ietf.org/mail-archive/web/mmusic/current/msg11062.html
http://www.ietf.org/mail-archive/web/mmusic/current/msg11107.html

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.

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

Qin,

Comments inline.

Colin

On 4 Sep 2013, at 02:48, Qin Wu <[e-mail]<mailto:[e-mail]>> wrote:
Hi,Colin:

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Colin Perkins
Sent: Wednesday, September 04, 2013 12:20 AM
To: Roni Even
Cc: [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> wrote:
Hi Colin,
The major motivation is to update the closed IANA registry
http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-parameters-1 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 3.2.1.2 of
http://tools.ietf.org/id/draft-roach-mmusic-unified-plan-00.txt

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
http://csperkins.org/