【网络通信 -- 直播】网络通信协议简介 -- RTP 协议的 WebRTC 扩展

【网络通信 -- 直播】网络通信协议简介 -- RTP 协议的 WebRTC 扩展

【1】RTP 首部扩展格式

【2】RFC-5285 中 RTP 首部扩展

One-byte Header

• 0XBEDE 表示 one-byte 扩展
• length = 3 表示 header extension 的总长度为 3 * 32 bit = 96 bit = 12 byte
• 每个扩展头首先以一个 byte 开始，前 4 位是这个扩展头的 ID， 后四位是 data 的长度 -1
  • 注意，第二个扩展头其后没有紧跟第三个扩展头，而是添加了 2 个 byte 的全 0 的 data，作填充对齐

Two-bytes Header

• 开头为 0x100 + 0x0 表示 two-bytes 扩展
• length = 3 表示接下来有 3 个 32bit 长度
• 接下来的就是扩展头和数据
  • 扩展头 ID 和 L 相对于 one-byte header 从 4bits 变成了 8bits
  • two-bytes 中 L 表示了真实的长度，不同于 one-byte 中需要进行 +1 计算

【3】SDP 中的 RTP 首部扩展信息

• <value> 对于扩展的本地标识 (ID)，是一个在有效范围内的整数，0 作为 padding 数据，15 作为停止标识
• <direction> 有效类型为 “sendonly”, “recvonly”, “sendrecv”, “inactive” 表示传输方向
• <URI> 头部扩展的 URI 描述
  • 在 IANA 注册的 URI 格式为 urn:ietf:params:rtp-hdrext:avt-example-metadata
  • 没有在 IANA 注册的 URI 格式为 http://example.com/082005/ext.htm#example-metadata

示例

a=extmap:1 http://example.com/082005/ext.htm#ttime
a=extmap:2/sendrecv http://example.com/082005/ext.htm#xmeta

【4】WebRTC 中的 RTP 首部扩展信息

URI

urn:ietf:params:rtp-hdrext:sdes:mid

urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id

urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id

http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time

http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01

urn:ietf:params:rtp-hdrext:framemarking

urn:ietf:params:rtp-hdrext:ssrc-audio-level

urn:3gpp:video-orientation

urn:ietf:params:rtp-hdrext:toffset

• urn:ietf:params:rtp-hdrext:sdes:mid
  • 在 unified SDP 描述中 ‘a=mid’ 是每个 audio/video line 的必要元素，这个 header extension 将 SDP 中 ‘a=mid’ 后信息保存，用于标识一个 RTP packet 的 media 信息，可以作为一个 media 的唯一标识
• urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
  • Media Source 等同于 WebRTC 中 Track 的概念，在 SDP 描述中可以使用 mid 作为唯一标识
  • RTP Stream 是 RTP 流传输的最小流单位，例如在 Simulcast 或 SVC 场景中，一个 Media Source 中包含多个 RTP Stream，这时 SDP 中使用 ‘a=rid’ 来描述每个 RTP Stream
• urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
  • 用于声明重传时使用的 rid 标识
• http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
  • abs-send-time 为 一个 3 bytes 的时间数据
  • REMB 计算需要 RTP 报文扩展头部 abs-send-time 的支持，用以记录 RTP 数据包在发送端的绝对发送时间
• http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01

•  
  • 有效数据只有 16 bit，记录了一个 sequence number 称为 transport-wide sequence number
  • 发送端在发送 RTP 数据包时，在 RTP 头部扩展中设置传输层序列号 TransportSequenceNumber；
  • 数据包到达接收端后记录该序列号和包到达时间，然后接收端基于此构造 TransportCC 报文返回到发送端；
  • 发送端解析该报文并执行 SendSide-BWE 算法，计算得到基于延迟的码率；
  • 最终和基于丢包率的码率进行比较得到最终目标码率
• urn:ietf:params:rtp-hdrext:framemarking
  • 由于 WebRTC 中 RTP payload 通过 SRTP 进行加密，这样导致 RTP packet 在经过交换节点或转发节点时，有些场景下需要知道当前 RTP packet 的编码信息，framemarking 用于给定该编码信息
• urn:ietf:params:rtp-hdrext:ssrc-audio-level

•  
  • 用于音量调节
• urn:3gpp:video-orientation

• • C = Camera: indicates the direction of the camera used for this video stream. It can be used by the MTSI client in receiver to e.g. display the received video differently depending on the source camera.
    • 0: Front-facing camera, facing the user. If camera direction is unknown by the sending MTSI client in the terminal then this is the default value used.
    • 1: Back-facing camera, facing away from the user.
  • F = Flip: indicates a horizontal (left-right flip) mirror operation on the video as sent on the link.
    • 0: No flip operation. If the sending MTSI client in terminal does not know if a horizontal mirror operation is necessary, then this is the default value used.
    • 1: Horizontal flip operation
  • R1, R0 = Rotation: indicates the rotation of the video as transmitted on the link. The receiver should rotate the video to compensate that rotation. E.g. a 90° Counter Clockwise rotation should be compensated by the receiver with a 90° Clockwise rotation prior to displaying.
•  urn:ietf:params:rtp-hdrext:toffset

•  
  • 传输时间偏移 (Transmission Time Offset)，offset 为 RTP packet 中 timestamp 与 实际发送时间的偏移

参考致谢
本博客为博主的学习实践总结，并参考了众多博主的博文，在此表示感谢，博主若有不足之处，请批评指正。

【1】WebRTC RTP Header Extension 分析