Subject: Re: [AVTCORE] IANAs payload type number registry and RFC 5761

From: Magnus Westerlund <[email-masked]>
Date: Tue, 4 Mar 2014 14:51:31 +0000

WG,

This is what I intended to send to IANA. If you have feedback on this,
please send it ASAP.

AVTCORE WG requests that IANA adds the below note to the registry:

RTP Payload types (PT) for standard audio and video encodings
http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-parameters-1

The current note reads:

Note

    The RFC "RTP Profile for Audio and Video Conferences with Minimal
    Control" [RFC3551] specifies an initial set "payload types".  This
    list maintains and extends that list.

The WG requests that this is change to:

Note

    The RFC "RTP Profile for Audio and Video Conferences with Minimal
    Control" [RFC3551] specifies an initial set "payload types".  This
    list maintains and extends that list.

    The registry is closed, see RFC 3551.  No additional registrations
    will be done. The payload types that have a static mapping are the
    below ones (0-34).

    The "Reserved for RTCP conflict avoidance" in this table is not up
    to date. [RTCP Control Packet types (PT)] below lists the RTCP
    types that has actually been registered. Subtract 128 from the
    RTCP Packet Type value to find the corresponding PT value with
    collision risk. For further information see RFC 5761.

    If you seek guidance on which PT values to use for assigning
    dynamic payload types, then that is present in RFC 3551 (Section 3)
    and RFC 5761 (Section 4).

Note, if possible I would request that "[RTCP Control Packet types
(PT)]" is made into ling with the following URL:

http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-parameters-4

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 5 Mar 2014 17:09:46 +0000

WG,

I received some feedback on this from Stephen Casner, so I have proposed
some changes. This merges the first and second paragraph and addresses
the tenses.

The current note reads:

Note

Note

    The RFC "RTP Profile for Audio and Video Conferences with Minimal
    Control" [RFC3551] specified an initial set "payload types".  This
    registry maintained that list. The registry is now closed, see
    RFC 3551. No additional registrations will be done. The payload
    types that have a static mapping are the below ones (0-34).

-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 5 Mar 2014 18:35:43 +0000

WG,

Got word smithed text from Stephen Casner:

    The RFC "RTP Profile for Audio and Video Conferences with Minimal
    Control" [RFC3551] specified an initial set "payload types".  This
    registry maintained that list. The registry is now closed, see RFC
    3551. No additional registrations will be done.  The payload types
    that have a static mapping are the ones listed below (0-34).

    The set of types marked "Reserved for RTCP conflict avoidance" in
    this table may not be kept current.  [RTCP Control Packet types
    (PT)] below lists the RTCP types that have actually been
    registered.  Subtract 128 from the RTCP Packet Type value to find
    the corresponding PT value with collision risk.  For further
    information see RFC 5761.

    If you seek guidance on which PT values to use for assigning
    dynamic payload types, see RFC 3551 (Section 3) and RFC 5761
    (Section 4).

Thanks,

Magnus

-- 

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 10 Mar 2014 17:32:22 +0100

WG,

For your information I have submitted this request. It might be some
time (weeks) before this goes in to the registry. In my conversation
with IANA they indicated that they likely will make this a IESG
management item. This means that it will go in front of the IESG for
approval. Slight overkill from my perspective, but I do understand IANA
wanting to ensure that there is one decision to point at if someone
questions the change.

cheers

Magnus

-- 

Magnus Westerlund