RTP header extension

RTP Header

In the RTP protocol, the RTP Header (header) includes a fixed header (Fixed Header) and a header extension (Header extension, optional).

The RTP Fixed Header structure is as follows, where the first 12 bytes must be included in each RTP packet.

 But the information carried by the Fixed Header cannot meet more complex needs. So the RTP Header Extension is introduced, which can carry more information.

RTP Header Extension

If the field in the RTP Fixed Header Xis 1, it means that it is followed by the RTP Header Extension. The RTP Header Extension structure is as follows:

• defined by profile : decide which Header Extension to use: one-byte or two-byte header
• length : Indicates the length of the Header Extension: length x 4 bytes

 The first is the beginning of the 0xBEDE fixed field, and then the length is 3, indicating that it is followed by 3x4the header extension of the byte length. For the first header extension: L=0, it means that the data length is 1 byte. For the second header extension: L=1, it means that the data length is 2 bytes. Since it is aligned by 4 bytes, padding data with a value of 0 follows. The last header extension: L=3, indicates that the data length is 4 bytes.

WireShark packet capture analysis

The following is an RTP packet structure of WireShark capturing WebRTC video stream analysis:

 Defined by profileThe field is 0xBEDE, which means One-Byte Header, Extension lengthand 1, which means the length of Header Extension is 1x4bytes. For Header Extension: ID is 3, Lengh is 2

• The construction related code is located RtpPacket::AllocateRawExtensionin
• The parsing related code is located RtpPacket::ParseBufferin

• Two-Byte Header

  The "defined by profile" field has the following structure:

• 

The structure of each extension element that follows is as follows:

 

• ID : local identifier
• length : Indicates the length of the extension data, ranging from 1 to 255
• The following is an example of Two-Byte Header
• 

 

First, the "defined by profile" field is 0x1000, the length is 3, followed by 3x4byte length extension, for the first header extension: L=0, the data length is 0, for the second header extension: L=1, the data length is 1, followed by padding Data, for the third header extension: L=4, followed by 4-byte length data.

Since the default in WebRTC is One-Byte Header.

Common RTP Header Extension

Many RTP Header Extensions are defined in WebRTC, the most common one is the Transport-CC extension for bandwidth estimation, which records a serial number of the transport layer: , and each RTP TransportSequenceNumberpacket has this extension by default.

Of course, there are AudioLevel extensions that record the volume, AbsoluteSendTime extensions that record the sending time, and so on.

Look at the several Header Extensions currently supported by WebRTC:

enum RTPExtensionType : int {
kRtpExtensionNone,
kRtpExtensionTransmissionTimeOffset,
kRtpExtensionAudioLevel,
kRtpExtensionInbandComfortNoise,
kRtpExtensionAbsoluteSendTime,
kRtpExtensionAbsoluteCaptureTime,
kRtpExtensionVideoRotation,
kRtpExtensionTransportSequenceNumber,
kRtpExtensionTransportSequenceNumber02,
kRtpExtensionPlayoutDelay,
kRtpExtensionVideoContentType,
kRtpExtensionVideoLayersAllocation,
kRtpExtensionVideoTiming,
kRtpExtensionRtpStreamId,
kRtpExtensionRepairedRtpStreamId,
kRtpExtensionMid,
kRtpExtensionGenericFrameDescriptor00,
kRtpExtensionGenericFrameDescriptor = kRtpExtensionGenericFrameDescriptor00,
kRtpExtensionGenericFrameDescriptor02,
kRtpExtensionColorSpace,
kRtpExtensionVideoFrameTrackingId,
kRtpExtensionNumberOfExtensions
};

SDP

m=video 9 UDP/TLS/RTP/SAVPF 127 97 98 99 100 101 125 121 124 120 123
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:XQ5X
a=ice-pwd:ROZxiR4lwF7PvysKHFDcEYdq
a=ice-options:trickle
a=fingerprint:sha-256 FE:D2:E8:F9:2B:CD:7C:03:12:2E:91:40:E4:F2:D1:32:79:76:98:5D:36:4F:3A:9F:47:BD:15:23:36:80:F4:89
a=setup:actpass
a=mid:1
a=extmap:14 urn:ietf:params:rtp-hdrext:toffset
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:13 urn:3gpp:video-orientation
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:12 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:11 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type
a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
a=extmap:8 http://www.webrtc.org/experiments/rtp-hdrext/color-space
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:6 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=sendrecv
a=msid:stream_id video_label
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:127 VP8/90000
a=rtcp-fb:127 goog-remb
a=rtcp-fb:127 transport-cc

In SDP, the beginning of a=extmap is the RTP Header Extension.

For the RTP Header Extension defined in RFC, the SDP format is as follows:

a=extmap:<value> urn:ietf:params:rtp-hdrext:<extensionattributes>

For the custom RTP Header Extension in WebRTC, the SDP format is as follows:

a=extmap:<value> <URI>