PSA: usage of rtp payload types in the range 35-65 in webrtc.org/chrome
Philipp Hancke
tl;dr: the range 96-127 of dynamic RTP payload types is exhausted
The RTP protocol uses a number between 0 and 127 as payload type to identify which codec is used to encode the media. While some codecs like G.711 have statically assigned payload types (0 for PCMU and 8 for PCMA), most modern codecs get their payload types assigned from what is referred to as the “dynamic range” from 96-127. See https://tools.ietf.org/html/rfc3550#section-5.1 for the details.
WebRTC requires only a few codecs as mandatory to implement:
G.711 and opus for audio
VP8 and H264 for video
However, Chrome goes a bit beyond that and implements the following codecs:
G.711, G.722, ISAC and opus for audio
VP8, VP9 and H.264 for video
In addition to that there are some mechanisms like DTMF, comfort noise, forward error correction, retransmission and redundancy. Mechanisms like RTX require a payload type per codec they work for and some codecs like VP9 and H264 support different configurations, each of which requires its own payload type to be negotiated.
See this fiddle which enumerates all payload types (including one for the RTP datachannels which are going away soon) on your machine.
On some platforms like Windows which support three H264 profiles (in two packetization modes) this has led to a situation where the dynamic range was exhausted, i.e. all numbers from 96 to 127 were assigned to a codec in the payload. This meant no new codecs could be added or they could not be negotiated. Or that unit tests would break which is how this came to our attention.
Thankfully the wise people writing the IETF specifications provided an escape hatch, specified in RFC 3551:
This profile reserves payload type numbers in the range 96-127
exclusively for dynamic assignment. Applications SHOULD first use
values in this range for dynamic payload types. Those applications
which need to define more than 32 dynamic payload types MAY bind
codes below 96, in which case it is RECOMMENDED that unassigned
payload type numbers be used first. However, the statically assigned
payload types are default bindings and MAY be dynamically bound to
new encodings if needed. Redefining payload types below 96 may cause
incorrect operation if an attempt is made to join a session without
obtaining session description information that defines the dynamic
payload types.
Over the years things got a bit more complicated (e.g. because of RTCP-MUX) so the IANA is showing us a registry of allowed payload types we can potentially use:
https://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-parameters-1
Unfortunately it turned out that the WebRTC implementation in Chrome did not understand any non-static payload type with a payload type less than 96. While that was easy to fix (done here) it will take time for this to be widely deployed as it is an interoperability problem. If a new version of Chrome offered a codec in the newly available “lower” range 35-63 an old version of Chrome would not recognize this codec and could not negotiate the codec.
Assigning a payload type in the lower range to new codecs will just work however:
Old versions of Chrome that do not understand the lower payload type range do not understand the new codec anyway.
New versions of Chrome which support the new codec will also be able to negotiate codecs in the lower payload type range.
See https://bugs.chromium.org/p/webrtc/issues/detail?id=12194 for more information.
This landed in M89 and shouldn’t cause interoperability issues on its own but please test.
Kudos to Harald, Jonathan and Taylor for helping getting this fixed.
Philipp
Tristan Matthews
reading it seems like the "new" range is [35,63] inclusive, not up to
65 (as per the subject).
Philipp Hancke
--
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAN8HRDnVzY9n9DfW%3DehfGpic8%3DtLVBDxdb3vtbX%3D8MMt6cFEKg%40mail.gmail.com.