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

From: Harald Alvestrand <[email-masked]>
Date: Fri, 03 May 2013 14:04:15 +0200

I support this proposal.

On 04/26/2013 08:20 PM, Dale R. Worley wrote:
>> From: Magnus Westerlund <[email-masked]>
>>
>> Regarding the IANA, Mo you have correctly identified the registry as
>> closed and Adam pointed to the relevant text. Is this level of
>> indirection so problematic that this registry needs a Note to the effect?
> (cleaning up my proposal)
>
> I use the IANA registries as the reference for how the various number
> spaces are managed.  The current final rows of the Payload Types table
> read:
>
>      35-71   Unassigned
>      72-76   Reserved for RTCP conflict avoidance    [RFC3551]
>      77-95   Unassigned
>      96-127  dynamic                                 [RFC3551]
>
> I find these to be problematic in several ways:
>
> 1) RFC 5761 is not mentioned at all, despite that it provides
> important modifications of the governing text in RFC 3551.  This is a
> practical problem:  Note that Adam quoted the text in RFC 3551, not
> the text in RFC 5761, and the 3551 text is now incorrect.
>
> 2) The range that is reserved for RTCP avoidance is not specified
> correctly.  It's true that the rest of the RTCP avoidance range is
> marked "Unassigned", but in the context of RFC 3551, that suggests
> that they can be used as a secondary dynamic assignment area.
>
> 3) The range 35-71 should be marked more clearly as the secondary
> dynamic assignment area.
>
> Because of this, I suggest the following changes to this registry:
>
> 1) The "Reference" section should be changed from "[RFC3551]" to
> "[RFC5761][RFC3551]".
>
> 2) The final rows should be changed to
>
>      35-63   Unassigned/secondary dynamic area       [RFC5761]
>      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]
>
> Dale
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 10 May 2013 21:19:15 +0000

64-65 have been obsolete and given the lack of H.261 being used in deployments I think it is safe if they are in the secondary pool. 

I think they would be better to ref 

65	[RFC2032]
66	[RFC5484]

For the rest, I think it should be more like 

65	[RFC2032]
66	[RFC5484]
67	[RFC5450]

72	[RFC3550]
73	[RFC3550]
74	[RFC3550]
75	[RFC3550]
76	[RFC3550]

77	[RFC4585]
78	[RFC4585]

79	[RFC3611]
80	IEEE Std 1733TM-2011

Given how the next two are  used, bit hard to decide what the impact is when doing O/A 
81	[RFC5760] 
82	[RFC6284]

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 13 May 2013 10:03:02 +0200

Dale,

Ok, I think you have convinced me that there is a point in updating or
at least clarifying the registry. However, I think it is important that
one makes clear the difference between using RTP/RTCP MUX and not. The
considerations for doing static allocations which was this registries
original purpose and the the usage of dynamic PT assignments with and
without RTP/RTCP MUX is quite different.

>From my perspective I don't see major issues to use all 128 values of PT
field if needed when doing dynamic allocation and not using RTP/RTCP
MUX. Yes, I would use the one that collide with SR/RR RTCP packets last,
but I still would use them. The thing that is getting screwed up are
classifier filters, not the actual end-points.

Clearly if using RTP/RTCP MUX you need to avoid the PT values
corresponding to RTCP packets types in use. Especially if reduced size
RTCP is used.

I also think you should check with IANA if one can touch a closed
registry at all, or if we are restricted to clarifying notes for the
registry.

Cheers

Magnus

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Roni Even" <[email-masked]>
Date: Mon, 13 May 2013 11:45:51 +0300

Hi,
I am also concerned about putting in the registries the different case where
RTCP mux is used or not. I think the best we can do is add a general note in
the registry point at RFC5761 saying that it provides clarification on using
the pt type numbers in different cases.
Roni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Magnus Westerlund
Sent: 13 May, 2013 11:03 AM
To: Dale R. Worley
Cc: [email-masked]; [email-masked]
Subject: Re: [MMUSIC] Should we update the IANA registry to reflect RFC
5761?

Dale,

Ok, I think you have convinced me that there is a point in updating or at
least clarifying the registry. However, I think it is important that one
makes clear the difference between using RTP/RTCP MUX and not. The
considerations for doing static allocations which was this registries
original purpose and the the usage of dynamic PT assignments with and
without RTP/RTCP MUX is quite different.

>From my perspective I don't see major issues to use all 128 values of PT
field if needed when doing dynamic allocation and not using RTP/RTCP MUX.
Yes, I would use the one that collide with SR/RR RTCP packets last, but I
still would use them. The thing that is getting screwed up are classifier
filters, not the actual end-points.

Clearly if using RTP/RTCP MUX you need to avoid the PT values corresponding
to RTCP packets types in use. Especially if reduced size RTCP is used.

I also think you should check with IANA if one can touch a closed registry
at all, or if we are restricted to clarifying notes for the registry.

Cheers

Magnus

-- 

Magnus Westerlund

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 16 May 2013 11:47:38 -0400 (EDT)

> From: "Roni Even" <[email-masked]>
> 

I do not believe that the registry table format allows us to express
well the difference between the RTCP-mux case and the non-RTCP-mux
case.  I believe that we should add RFC 5761 as the *primary*
reference for this registry.  As a conservative choice, the PTs 64-95
can be marked as "reserved"; the careful reader of RFC 5761 can tell
that in the non-RTCP-mux case, there is no danger that the endpoints
will confuse those PTs with RTCP packets.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 16 May 2013 11:47:55 -0400 (EDT)

> at least clarifying the registry.

Very good.

> classifier filters, not the actual end-points.

This is true.  But it is difficult to express this fact in the table
format of a registry.  My preference is to provide RFC 5761 as the
primary reference for the registry and to mark conservatively PTs 64
to 95 as "reserved".  The careful reader of RFC 5761 can determine
that in the non-RTCP-mux case that the endpoint will not confuse the
endpoints, but that it may confuse network diagnostic elements.

> registry at all, or if we are restricted to clarifying notes for the

I have sent an inquiry to Gonzalo about this point.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 16 May 2013 11:47:20 -0400 (EDT)

I want to confirm that I understand you here:  I believe that you are
giving the references for the various RTCP packet types that could
potentially collide with the numbers given as RTP payload type.  E.g.,
RTP PT 65 could be mistaken for RTCP packet type 65 + 128 = 193.  And
RTCP 193 is marked in the "RTCP Control Packet types (PT)" registry
with reference RFC 2032.

So I believe that the information in the table you've written below is
captured in "RTCP Control Packet types (PT)"
(http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xml#rtp-parameters-3).

Dale

> From: "Cullen Jennings (fluffy)" <[email-masked]>
> CC: Magnus Westerlund <[email-masked]>,
>         "[email-masked]"
> 	<[email-masked]>,
>         "[email-masked]" <[email-masked]>
> Date: Fri, 10 May 2013 21:19:15 +0000
> Accept-Language: en-US
> 
> >

---

From: Adam Roach <[email-masked]>
Date: Thu, 16 May 2013 12:23:17 -0500

On 5/16/13 10:47, Dale R. Worley wrote:
> My preference is to provide RFC 5761 as the primary reference for the 
> registry and to mark conservatively PTs 64 to 95 as "reserved". The 
> careful reader of RFC 5761 can determine that in the non-RTCP-mux case 
> that the endpoint will not confuse the endpoints, but that it may 
> confuse network diagnostic elements.

It can also frustrate attempts to gateway between a system that does 
multiplexing and one that does not.  I think we should treat them as 
off-limits for all uses, regardless of whether we're multiplexing RTCP 
over the same channel.

/a

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 16 May 2013 17:54:03 +0000

The registry is not there to show how values are used.

It should concentrate on two issues:

-	Making sure the value is reserved so that it can not be reused for something else
-	Identifying where the user should go to find further information about that value.

Anything else should be in the RFCs. If there is lack of clarity as a result, that means spinning a new version of the RFC or filing a fix.

We cannot fix lack of clarity in the RFCs by playing with the IANA tables.

Regards

Keith

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Dale R. Worley
> Sent: 16 May 2013 16:48
> To: Roni Even
> Cc: [email-masked]; [email-masked]; [email-masked]

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 21 May 2013 14:50:30 +0000

> registry at all, or if we are restricted to clarifying notes for the

If we have consensus for the change and IESG approval, I think we can do whatever we want to the IANA registries. If we want a totally different format for the registry, we can do that - we just need a draft that updates the previous RFC that defined the registries. 

However, I agree with Keith the registry is for code point allocation, not explaining life to implementors. If we need an information RFC to summarize and explain all the info to implementors, that would be easy to publish if someone wrote it.