a617867a45
This reverts commit 0f2ce5cc1c779f9bf33f51f29bfffbcbe105d1b1. Reason for revert: Downstream infrastructure should be ready now Original change's description: > Revert "Migrate WebRTC documentation to new renderer" > > This reverts commit 3eceaf46695518f25bef43f155f82ed174827197. > > Reason for revert: > > Original change's description: > > Migrate WebRTC documentation to new renderer > > > > Bug: b/258408932 > > Change-Id: Ib96f39fe0c3912f9746bcc09d079097a145d6115 > > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290987 > > Reviewed-by: Harald Alvestrand <hta@webrtc.org> > > Commit-Queue: Artem Titov <titovartem@webrtc.org> > > Cr-Commit-Position: refs/heads/main@{#39205} > > Bug: b/258408932 > Change-Id: I16cb4088bee3fc15c2bb88bd692c592b3a7db9fe > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291560 > Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> > Owners-Override: Artem Titov <titovartem@webrtc.org> > Commit-Queue: Artem Titov <titovartem@webrtc.org> > Cr-Commit-Position: refs/heads/main@{#39209} Bug: b/258408932 Change-Id: Ia172e4a6ad1cc7953b48eed08776e9d1e44eb074 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291660 Owners-Override: Artem Titov <titovartem@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Artem Titov <titovartem@webrtc.org> Cr-Commit-Position: refs/heads/main@{#39231}
57 lines
2.9 KiB
Markdown
57 lines
2.9 KiB
Markdown
<!-- go/cmark -->
|
|
<!--* freshness: {owner: 'hta' reviewed: '2021-06-03'} *-->
|
|
|
|
# RTP in WebRTC
|
|
|
|
WebRTC uses the RTP protocol described in
|
|
[RFC3550](https://datatracker.ietf.org/doc/html/rfc3550) for transporting audio
|
|
and video. Media is encrypted using [SRTP](./srtp.md).
|
|
|
|
## Allocation of payload types
|
|
|
|
RTP packets have a payload type field that describes which media codec can be
|
|
used to handle a packet. For some (older) codecs like PCMU the payload type is
|
|
assigned statically as described in
|
|
[RFC3551](https://datatracker.ietf.org/doc/html/rfc3551). For others, it is
|
|
assigned dynamically through the SDP. **Note:** there are no guarantees on the
|
|
stability of a payload type assignment.
|
|
|
|
For this allocation, the range from 96 to 127 is used. When this range is
|
|
exhausted, the allocation falls back to the range from 35 to 63 as permitted by
|
|
[section 5.1 of RFC3550][1]. Note that older versions of WebRTC failed to
|
|
recognize payload types in the lower range. Newer codecs (such as flexfec-03 and
|
|
AV1) will by default be allocated in that range.
|
|
|
|
Payload types in the range 64 to 95 are not used to avoid confusion with RTCP as
|
|
described in [RFC5761](https://datatracker.ietf.org/doc/html/rfc5761).
|
|
|
|
## Allocation of audio payload types
|
|
|
|
Audio payload types are assigned from a table by the [PayloadTypeMapper][2]
|
|
class. New audio codecs should be allocated in the lower dynamic range [35,63],
|
|
starting at 63, to reduce collisions with payload types
|
|
|
|
## Allocation of video payload types
|
|
|
|
Video payload types are allocated by the
|
|
[GetPayloadTypesAndDefaultCodecs method][3]. The set of codecs depends on the
|
|
platform, in particular for H264 codecs and their different profiles. Payload
|
|
numbers are assigned ascending from 96 for video codecs and their
|
|
[associated retransmission format](https://datatracker.ietf.org/doc/html/rfc4588).
|
|
Some codecs like flexfec-03 and AV1 are assigned to the lower range [35,63] for
|
|
reasons explained above. When the upper range [96,127] is exhausted, payload
|
|
types are assigned to the lower range [35,63], starting at 35.
|
|
|
|
## Handling of payload type collisions
|
|
|
|
Due to the requirement that payload types must be uniquely identifiable when
|
|
using [BUNDLE](https://datatracker.ietf.org/doc/html/rfc8829) collisions between
|
|
the assignments of the audio and video payload types may arise. These are
|
|
resolved by the [UsedPayloadTypes][4] class which will reassign payload type
|
|
numbers descending from 127.
|
|
|
|
[1]: https://datatracker.ietf.org/doc/html/rfc3550#section-5.1
|
|
[2]: https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/media/engine/payload_type_mapper.cc;l=25;drc=4f26a3c7e8e20e0e0ca4ca67a6ebdf3f5543dc3f
|
|
[3]: https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/media/engine/webrtc_video_engine.cc;l=119;drc=b412efdb780c86e6530493afa403783d14985347
|
|
[4]: https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/pc/used_ids.h;l=94;drc=b412efdb780c86e6530493afa403783d14985347
|