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

[Magnus Westerlund <[e-mail]>]

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

On 2013-04-26 20:20, Dale R. Worley wrote:
>> From: Magnus Westerlund <[e-mail]>
>>
>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
> 
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------