sdp 结构简析

参考：

1. 概述

SDP(Session Description Protocol，会话描述协议) 的具体标准定义在了 rfc4566 中。本篇文章主要以 rfc4566 为基础，通过 webrtc offer/answer 协商中的 sdp 为例进行记录，然后会对比与 sip 呼叫中 sdp 的一些异同。

2. 结构

sdp 是一行一行的文本，每一行之间使用 \n 或者 \r\n 来分割，所以如果要解析 sdp，那么代码需要兼容这两种分割方式。除开分隔符，其他都是可打印字符。
每一行中，采用 type=value 的结构，即使用 = 号进行分割。其中，type 必须为单个字符，而 value 则较为复杂，可以有多种不同格式，= 号之间不能存在空格。

2.1 总体结构

sdp 多个行之间会一起描述一个结构功能，sdp 是结构化的。简单来说，主要分为会话级别描述(session level)和媒体级别描述(media level)，会话级别描述只有一个，媒体级别描述可以有多个(下面示例出自 rfc4566)：

Session description（会话级别描述）
         v=  (protocol version)
         o=  (originator and session identifier)
         s=  (session name)
         c=* (connection information -- not required if included in all media)
         One or more Time descriptions ("t=" and "r=" lines; see below)
         a=* (zero or more session attribute lines)
         Zero or more Media descriptions

Time description
         t=  (time the session is active)

Media description（媒体级别描述）, if present
         m=  (media name and transport address)
         c=* (connection information -- optional if included at session level)
         a=* (zero or more media attribute lines)

2.2 会话级别描述(Session description level)

会话描述总是在 sdp 的开头，是必须存在的结构。以下面的会话描述为例，说明常见的每个字段：

v=0
o=- 1044094566052576507 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1
a=msid-semantic: WMS g4n21yfXiVM9K1CrtoSZMNxoNI7kBbY9rHgp

2.2.1 v(protocol version)

会话协议版本，rfc4566 固定了版本号为 0，即：

v=0

2.2.2 o(originator and session identifier)

会话发起者标识：

o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>

username：发起者的用户名，不允许存在空格，如果应用不支持用户名，则为 -。
sess-id：会话id，由应用自行定义，规范的建议是 NTP(Network Time Protocol) 时间戳。
sess-version：会话版本，用途由应用自行定义，只要会话数据发生变化时(比如编码)，sess-version 随着递增就行。同样的，规范的建议是 NTP 时间戳。
nettype：网络类型，比如 IN 表示 Internet。
addrtype：地址类型，比如 IP4、IV6。
unicast-address：域名，或者 IP 地址。

2.2.3 s(session name)

会话名，没有具体设置可为 -：

s=-

2.2.4 t(timing)

声明会话的开始时间和结束时间：

t=<start-time> <stop-time>

如果开始和结束时间都为 0，那么意味着这次会话是永久的。

2.2.5 a(attribute)

a 开头的表示附加属性，用于扩展 sdp，有如下两种格式：

a=<attribute>
a=<attribute>:<value>

a 开头的行不仅会出现在 session level 中，也会出现在 media level 中(后文将展示)。

2.3 媒体级别描述(Media description level)

会话描述结束后，接着是媒体描述。在sdp中，可能有多个媒体描述，每个媒体描述由 m= 行开始。不同于 session level，media level 中的一些不同行，会有明确的先后关系，不能乱序，而 session level 中的大部分行可以任意排列。以下面的媒体描述为例，说明常见的字段：

m=audio 9 UDP/TLS/RTP/SAVPF 111 103
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:Fyzi
a=ice-pwd:/NDZTbh8NX+BTFjRyZy7Heqc
a=ice-options:trickle
a=fingerprint:sha-256 60:DF:D2:8E:AC:1B:7C:DB:DA:36:39:57:AA:DD:1A:C2:43:58:36:09:80:56:CA:18:F4:85:6B:9F:B1:8F:78:13
a=setup:actpass
a=mid:0
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=sendonly
a=msid:g4n21yfXiVM9K1CrtoSZMNxoNI7kBbY9rHgp 13eb9491-262e-4982-9aea-1c6af9e8ef22
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:103 ISAC/16000
a=ssrc:724846199 cname:wJobAtYmVV7u5Y3x
a=ssrc:724846199 msid:g4n21yfXiVM9K1CrtoSZMNxoNI7kBbY9rHgp 13eb9491-262e-4982-9aea-1c6af9e8ef22
a=ssrc:724846199 mslabel:g4n21yfXiVM9K1CrtoSZMNxoNI7kBbY9rHgp

2.3.1 m=(Media Descriptions)

媒体描述起始行：

m=<media> <port> <proto> <fmt> ...

media：媒体类型。支持包括 video、audio、text、application(bfcp) 等。
port：流媒体传输端口。具体含义取决于使用的网络类型（在 c= 中声明）和使用的协议(proto，在 m= 中声明)。
proto：流媒体传输协议。具体含义取决于 c= 中定义的地址类型，比如 c= 是 IP4，那么这里的传输协议运行在 IP4 之上。以 UDP/TLS/RTP/SAVPF 为例：
- UDP：传输层协议是UDP。
- TLS：加密传输基于 DTLS 协议。
- RTP：使用 rtp 协议传输媒体。
- SAVPF：使用 SRTP 协议对 RTP 媒体负载进行加密。如果是 AVPF 或 AVP，表示不对 RTP 中的媒体负载进行加密。AVPF与AVP的区别，见 rfc4585 文档(webrtc 一般用 AVPF，sip 一般用 AVP)。
fmt：媒体格式的描述，可能有多个。根据 proto 的不同，fmt 的含义也不同。比如 proto 为 RTP/AVP 时，fmt 表示 RTP payload 的类型。如果有多个，表示在这次会话中，多种 payload 类型都可能会用到。

2.3.2 c=(Connection Data)

会话连接信息。此字段也可以只出现在 session level 中，或者只在 media level 中，也可以都出现：

c=<nettype> <addrtype> <connection-address>

nettype：网络类型，比如IN，表示 Internet。
addrtype：地址类型，比如IP4、IP6。
connection-address：如果是广播，则为广播地址组；如果是单播，则为单播地址。

2.4 group bundle 与 mid

在 webrtc 中，a=group:BUNDLE 行用于绑定不同的 media level，而每个 media level 都会有一个 mid 字段，用于媒体行标识：

// Session Description
a=group:BUNDLE 0 1
...
// Audio Media Description
a=mid 0
...
// Video Media Description
a=mid 1
...

每个媒体行都可以创建一个自己的网络连接，用于传递音视频和 rtcp 数据。会话绑定媒体行的意义是，不同媒体行可以复用同一个网络连接进行数据传输。

2.5 ICE(Interactive Connectivity Establishment)

媒体协商完成后，webrtc 双方要做的第一件事就是建立网络连接，而 ice 协议(参考 rfc5245)定义了 webrtc 建立网络连接的方式，反应在 sdp 中，有如下字段：

...
a=ice-ufrag:Fyzi
a=ice-pwd:/NDZTbh8NX+BTFjRyZy7Heqc
a=ice-options:trickle
a=ice-lite
...

ice-ufrag 和 ice-pwd 用于 ice 中 stun 消息的认证
ice-options:trickle 表明本端支持独立发送 candidates 和 sdp，参考 https://tools.ietf.org/id/draft-ietf-ice-trickle-16.html
ice-lite 表明本端不会做连通性检查(本端只会回应 stun binding response)

这些 ice 字段可以出现在所有的 media level 中，如果 sdp 指定了 group:bundle，则绑定的 media level 中，ice 字段应该都相同。

2.5.1 candidate(地址候选项)

地址候选项可以出现在 sdp 中，也可以单独通过 http、websocket 等类似发送 sdp 的方式发送给对端(来自 rfc5245 15.1，更改了排列格式，SP 表示空格)：

candidate-attribute="candidate:" foundation SP component-id SP transport SP priority SP connection-address SP port SP "typ" SP cand-type [SP rel-addr] [SP rel-port] *(SP extension-att-name SP extension-att-value)

foundation：多个 candidates 之间通过此字段来区分是否是同一种候选地址
component-id：1 表示用于传输 rtp 的候选地址，2 表示用于传输 rtcp 的候选地址，如果启用了 rtcp-mux，那么都为 1 即可
transport：网络传输类型，udp 或 tcp
priority：此 candidate 的优先级，用于生成 check-list pair 的时候，谁最先发起连通性检查
connection-address：候选地址，可以是 ipv4、ipv6、域名(如果是域名，接收端需要进行 dns 解析)
port：候选端口
cand-type：host、srflx、prflx、relay 之一
extension-att-name，extension-att-value：扩展属性

如下是一个 sdp 中的 candidate 示例(只能出现在 media level 中，不能出现在 session level 中，多个不同 media level 中的 candidate 可以相同)：

  a=candidate:0 1 udp 2130706431 192.168.0.106 8090 typ host generation 0

foundation 为 0
component-id 为 1，表明是用于 rtp 传输的候选地址，如果 sdp 启用了 rtcp-mux，则 rtcp 传输也复用这个候选地址
网络传输使用 udp
优先级为 2130706431，详细计算公式参考 rfc5245
候选 ipv4 地址为 192.168.0.106
候选 port 为 8090
候选地址类型为 host，这种地址要么本端拥有公网 ip，要么与对端在同一个局域网中
generation 0 是扩展属性

注意以下是一个 janus 通过信令发送的 trickle candidate 示例：

 {"janus":"trickle","candidate":{"candidate":"candidate:3805835391 1 udp 2122260223 192.168.0.107 53792 typ host generation 0 ufrag icRG network-id 1","sdpMid":"0","sdpMLineIndex":0},"transaction":"jIToQHjOgntu","session_id":52}

其中，必须指明此 candidate 属于哪个 media stream(这里通过 mid 和 m-line index 进行指定，显然，即使是 ice trickle 模式，也必须先发送 sdp 然后再发送 local candidate，参考 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-trickle-ice-02#section-9.2)。

2.6 DTLS

ICE 连接建立完成后，接着就是 DTLS 握手协商出用于 SRTP 媒体加密的密钥，DTLS 握手在 sdp 中的字段如下：

a=fingerprint:sha-256 60:DF:D2:8E:AC:1B:7C:DB:DA:36:39:57:AA:DD:1A:C2:43:58:36:09:80:56:CA:18:F4:85:6B:9F:B1:8F:78:13
a=setup:actpass

其中，fingerprint 即握手中的指纹信息(用于自签证书验证)，setup 表明本端在握手中的角色：

active：主动发起 DTLS 握手。
passive：被动等待接受 DTLS 握手消息。
actpass：既可以主动发起，也可以被动接受。当 offer 一方为 actpass 时，answer 一方必须指定为 active 或 passive。

2.7 Stream Direction

此属性在 a= 中，如 a=sendonly，在不同 media level 中，可以有不同，以表明不同的媒体收发支持：

sendonly：本端只支持发送媒体，不接收媒体，因此对端返回的 sdp 可以不携带 ssrc 信息。
recvonly：本端只支持接收媒体，不发送媒体，因此本端 sdp 可以不携带 ssrc 信息。
sendrecv：本端支持收发媒体
inactive：用在某个 media level 协商失败的回应中

2.8 Codec Parameters(编解码格式参数)

编解码参数用于描述媒体编解码格式信息(使用此格式进行编解码)，一个 media level 可以支持多个编解码格式，具体最终使用哪个或哪些取决于媒体协商的结果。
offer 中的编解码格式表明 offer 端支持发送接收带这些媒体格式的 rtp 包，answer 中的编解码格式只能从这些给定的编解码格式中进行协商。

2.8.1 rtpmap

a=rtpmap 是编解码格式参数的起始行：

a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding parameters>]

payload type：rtp payload 值，必须是 m line 中支持的某个值
encoding name：编解码格式名称，如 H264、opus、vpx 等
clock rate：时钟频率
encoding parameters：可选项

2.8.2 fmtp(format specific param)

用于对 rtpmap 指定的编码格式做进一步描述：

a=fmtp:<format> <format specific parameters>

format：等于其上最近一个 rtpmap 的 payload 值，所以 a=fmtp 行必须在 a=rtpmap 行的后面，有顺序之分
format specific parameters：对 rtpmap 编解码格式的进一步描述

如对 h264 编解码格式：

a=rtpmap:102 H264/90000
a=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f

level-asymmetry-allowed：指定
packetization-mode：
profile-level-id：16进制

2.8.3 rtcp-fb(rtcp feedback)

rtpmap 编解码格式支持的 rtcp 反馈消息类型，如：

a=rtcp-fb:102 goog-remb
a=rtcp-fb:102 transport-cc
a=rtcp-fb:102 ccm fir
a=rtcp-fb:102 nack
a=rtcp-fb:102 nack pli

goog-remb：Receiver Estimated Max Bitrate 接收端码率反馈，参考 https://tools.ietf.org/html/draft-alvestrand-rmcat-remb-03
transport-cc：传输层拥塞控制，参考 https://tools.ietf.org/html/draft-holmer-rmcat-transport-wide-cc-extensions-01
ccm fir：Full Intra Request，关键帧请求，主要用于发送端刚加入会议时，接收端传递此消息，让发送端尽快发送关键帧。fir 在 rfc5104(新的定义，一般用这种)和 rfc2032(旧的定义，不加 ccm 标识) 中进行了定义
nack：Negative Acknowledgement，nack 实际上分为 RTPFB 和 PSFB，在 rtcp 的 FMT 字段进行区分。这里指 rtp 包丢失重传，参考 rfc4585
nack pli：nack Picture Loss Indication，当丢 rtp 包太多时，接收端发送此消息，让发送端尽快发送新的关键帧过来

2.8.4 rtx

当 rtp 丢包重传时，可以直接重传原始包，也可以将待重传包的 rtp payload type 填入新的负载类型值，用于表明这是一个重传包。新的负载类型值即 sdp 中的 rtx rtpmap。rtx 依赖于某个非重传的 rtpmap 编解码格式，表示此 rtx 专门用来重传所属的编解码格式：

a=rtpmap:123 H264/90000
a=rtcp-fb:123 nack
a=rtcp-fb:123 nack pli
a=fmtp:123 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=64001f
a=rtpmap:118 rtx/90000
a=fmtp:118 apt=123

如上，重传 rtpmap 的 encoding name 为 rtx，pt 值为 118，如何与其上的 rtpmap:123 H264 相关联呢？答案是借助 a=fmtp:118 apt=123，apt= 的值即此 rtx 所属的非重传编解码格式。
注意，rtx 不需要双向协商，即只要本端的 sdp 中出现 rtx 即表明本端重传 rtp 时，以 rtx 的方式重传。
rtx 重传包也会拥有自己独立的 ssrc，rtx 的 ssrc 参见下文。

2.9 extmap

rtp 头部扩展，参考 rfc5285：

a=extmap:<value>["/"<direction>] <URI> <extensionattributes>

如一个 audio level 支持的头部扩展：

a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
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

value 和 url 可以自定定义。如上，offer 中的 extmap 表明 offer 端支持发送接收带这些扩展头的 rtp 包，answer 中的 extmap 只能从这些给定的 extmap 进行协商。

2.10 ssrc

ssrc 即 media level 的源同步标识，参考 rfc5576：

a=ssrc:<ssrc-id> <attribute>
a=ssrc:<ssrc-id> <attribute>:<value>

ssrc-id 是一个在 [0, 2^32-1] 之间的随机值，如某个 audio level 的 ssrc：

a=ssrc:724846199 cname:wJobAtYmVV7u5Y3x
a=ssrc:724846199 msid:g4n21yfXiVM9K1CrtoSZMNxoNI7kBbY9rHgp 13eb9491-262e-4982-9aea-1c6af9e8ef22
a=ssrc:724846199 mslabel:g4n21yfXiVM9K1CrtoSZMNxoNI7kBbY9rHgp
a=ssrc:724846199 label:13eb9491-262e-4982-9aea-1c6af9e8ef22

a=ssrc:724846199 出现了多次，但是 attribute 都不同。

2.10.1 ssrc-group

定义一组相关联的 ssrc：

a=ssrc-group:<semantics> <ssrc-id> ...

semantics：可以取值为 FID(Flow Identification)、FEC(Forward Error Correction)
ssrc-id：可以有多个，表明是一组相关联的 ssrc
在 rtx 的语义中，rtx 重传包不仅有不同于被重传包的 pt 值，也有不同的 ssrc 值，rtx ssrc 在 ssrc-group 字段中，如下是 video media level 示例：

a=ssrc-group:FID 3473705511 683075964
a=ssrc:3473705511 cname:wJobAtYmVV7u5Y3x
a=ssrc:3473705511 msid:g4n21yfXiVM9K1CrtoSZMNxoNI7kBbY9rHgp 0befb6f8-46a8-4890-9955-b53689962daf
a=ssrc:3473705511 mslabel:g4n21yfXiVM9K1CrtoSZMNxoNI7kBbY9rHgp
a=ssrc:3473705511 label:0befb6f8-46a8-4890-9955-b53689962daf
a=ssrc:683075964 cname:wJobAtYmVV7u5Y3x
a=ssrc:683075964 msid:g4n21yfXiVM9K1CrtoSZMNxoNI7kBbY9rHgp 0befb6f8-46a8-4890-9955-b53689962daf
a=ssrc:683075964 mslabel:g4n21yfXiVM9K1CrtoSZMNxoNI7kBbY9rHgp
a=ssrc:683075964 label:0befb6f8-46a8-4890-9955-b53689962daf

其中，semantics 为 FID，ssrc-id 有两个，第一个是正常 media level 的 ssrc，第二个 ssrc 即 rtx 的重传 ssrc。

2.11 示例解释

下面是一个 offer 示例，将逐行解释，前文没有描述的字段，在这里进行描述：

// sdp版本号为0
v=0
// 用户名为空，会话id是 1044094566052576507，会话版本是2(会话重协商 sess-version 应加 1），地址类型为 IP4，地址为 127.0.0.1(可忽略)
o=- 1044094566052576507 2 IN IP4 127.0.0.1
// 会话名为空
s=-
// 实时会话
t=0 0
// mid=0 和 mid=1 的 media track 多路复用同一个网络连接
a=group:BUNDLE 0 1
// WMS 是 WebRTC Media Stram 的缩写，这里给 Media Stream 定义了一个唯一的标识符。一个 Media Stream 可以有多个 track(video track、audio track)，这些 track 就是通过这个唯一标识符关联起来的，具体见下面的媒体行(m=)以及它对应的附加属性(a=ssrc)
a=msid-semantic: WMS g4n21yfXiVM9K1CrtoSZMNxoNI7kBbY9rHgp
// 音频媒体描述，端口为9(可忽略)，采用 UDP 传输加密的 RTP 包，支持 RTCP 反馈，111、103 是 audio 可能采用的编码格式 payload type 值
m=audio 9 UDP/TLS/RTP/SAVPF 111 103
// 音频发送者的 IP4 地址，WebRTC 采用 ICE，这里的 0.0.0.0 可直接忽略
c=IN IP4 0.0.0.0
// RTCP 采用的端口、IP地址，因为下面的 a=rtcp-mux，这里可忽略
a=rtcp:9 IN IP4 0.0.0.0
// ice 协商认证字段
a=ice-ufrag:Fyzi
a=ice-pwd:/NDZTbh8NX+BTFjRyZy7Heqc
// 本端支持的 ice 类型是 trickle
a=ice-options:trickle
// dtls 握手指纹
a=fingerprint:sha-256 60:DF:D2:8E:AC:1B:7C:DB:DA:36:39:57:AA:DD:1A:C2:43:58:36:09:80:56:CA:18:F4:85:6B:9F:B1:8F:78:13
// dtls 握手角色，支持主动和被动
a=setup:actpass
// 本 audio 的 mid 为 0，对应前面的 a=group:BUNDLE 0 1
a=mid:0
// audio 支持的 rtp 扩展头
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
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
// audio 只支持发送 rtp，不支持接收 rtp。但是注意，仍然支持接收 rtcp
a=sendonly
// msid后面带两个id，第一个是 Media Stream 的 id，第二个是 audio track 的 id
a=msid:g4n21yfXiVM9K1CrtoSZMNxoNI7kBbY9rHgp 13eb9491-262e-4982-9aea-1c6af9e8ef22
// rtcp 多路复用 rtp 的网络通道
a=rtcp-mux
// opus 的 pt 值为 111，clock rate 为 48000，2 声道
a=rtpmap:111 opus/48000/2
// opus 编解码格式支持 transport-cc rtcp 反馈，注意，transport-cc rtcp 反馈需要 a=extmap:3 扩展头的支持
a=rtcp-fb:111 transport-cc
// 进一步描述 opus 编解码格式，支持带内 fec
a=fmtp:111 minptime=10;useinbandfec=1
// audio 也支持 ISAC 编解码格式
a=rtpmap:103 ISAC/16000
// audio 的 ssrc，cname用来唯一标识媒体的数据源
a=ssrc:724846199 cname:wJobAtYmVV7u5Y3x
// msid 与前面的 a=msid 字段相同
a=ssrc:724846199 msid:g4n21yfXiVM9K1CrtoSZMNxoNI7kBbY9rHgp 13eb9491-262e-4982-9aea-1c6af9e8ef22
// mslabel：audio track id
a=ssrc:724846199 mslabel:g4n21yfXiVM9K1CrtoSZMNxoNI7kBbY9rHgp
// label：webrtc media stream id
a=ssrc:724846199 label:13eb9491-262e-4982-9aea-1c6af9e8ef22
// 从下面开始是 video track 的媒体描述
m=video 9 UDP/TLS/RTP/SAVPF 96 97 102 121
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:Fyzi
a=ice-pwd:/NDZTbh8NX+BTFjRyZy7Heqc
a=ice-options:trickle
a=fingerprint:sha-256 60:DF:D2:8E:AC:1B:7C:DB:DA:36:39:57:AA:DD:1A:C2:43:58:36:09:80:56:CA:18:F4:85:6B:9F:B1:8F:78:13
a=setup:actpass
// 本 video 的 mid 为 1，对应前面的 a=group:BUNDLE 0 1
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=sendonly
a=msid:g4n21yfXiVM9K1CrtoSZMNxoNI7kBbY9rHgp 0befb6f8-46a8-4890-9955-b53689962daf
a=rtcp-mux
a=rtcp-rsize
// 支持 vp8 编解码格式
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
// 支持 h264 编解码格式
a=rtpmap:102 H264/90000
a=rtcp-fb:102 goog-remb
a=rtcp-fb:102 transport-cc
a=rtcp-fb:102 ccm fir
a=rtcp-fb:102 nack
a=rtcp-fb:102 nack pli
a=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f
// pt 值为 102 的 h264 编解码格式支持 rtp 丢包重传
a=rtpmap:121 rtx/90000
a=fmtp:121 apt=102
// video 发送媒体正常的 ssrc 和支持 rtx 重传的 ssrc
a=ssrc-group:FID 3473705511 683075964
a=ssrc:3473705511 cname:wJobAtYmVV7u5Y3x
a=ssrc:3473705511 msid:g4n21yfXiVM9K1CrtoSZMNxoNI7kBbY9rHgp 0befb6f8-46a8-4890-9955-b53689962daf
a=ssrc:3473705511 mslabel:g4n21yfXiVM9K1CrtoSZMNxoNI7kBbY9rHgp
a=ssrc:3473705511 label:0befb6f8-46a8-4890-9955-b53689962daf
a=ssrc:683075964 cname:wJobAtYmVV7u5Y3x
a=ssrc:683075964 msid:g4n21yfXiVM9K1CrtoSZMNxoNI7kBbY9rHgp 0befb6f8-46a8-4890-9955-b53689962daf
a=ssrc:683075964 mslabel:g4n21yfXiVM9K1CrtoSZMNxoNI7kBbY9rHgp
a=ssrc:683075964 label:0befb6f8-46a8-4890-9955-b53689962daf

3. 协商失败

媒体协商可能失败，answer 端会检查每一个 media level，如果某个 media level 协商失败，answer 中的 sdp 如何表明呢？有两种方式：

m 行中的 port 字段为 0，如 m=video 0 UDP/TLS/RTP/SAVPF 96 97 102 121
media direction 字段为 inactive，如 a=inactive

4. PlanB and UnifiedPlan

webrtc 引入了 stream 和 track 的概念，一个 track 即一路音频或视频流，比如一个终端，可以发送屏幕共享一路流、摄像头一路流、麦克风音频一路流。每一路单独流是一个 track，集合在一起形成了一个 stream，每一路流通过 ssrc 来进行区分。
两路音频流 planb 的 sdp 格式：

...
a=group:BUNDLE audio
a=msid-semantic: WMS stream-id-2 stream-id-1
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
...
a=mid:audio...
a=rtpmap:103 ISAC/16000
...
a=ssrc:10 cname:cname
a=ssrc:10 msid:stream-id-1 track-id-1
a=ssrc:10 mslabel:stream-id-1
a=ssrc:10 label:track-id-1
a=ssrc:11 cname:cname
a=ssrc:11 msid:stream-id-2 track-id-2
a=ssrc:11 mslabel:stream-id-2
a=ssrc:11 label:track-id-2

两路音频流的 UnifiedPlan 格式：

...
a=group:BUNDLE 0 1
a=msid-semantic: WMS
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
...
a=mid:0
...
a=sendrecv
a=msid:- track-id-1
...
a=rtpmap:103 ISAC/16000
...
a=ssrc:10 cname:cname
a=ssrc:10 msid: track-id-1
a=ssrc:10 mslabel:
a=ssrc:10 label:track-id-1
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
...
a=mid:1
...
a=sendrecv
a=msid:- track-id-2
...
a=rtpmap:103 ISAC/16000
...
a=ssrc:11 cname:cname
a=ssrc:11 msid: track-id-2
a=ssrc:11 mslabel:
a=ssrc:11 label:track-id-2

可见，planb 格式中，audio 只有一个 media level，media level 中有多个 track 时不同 track 通过 ssrc 进行区分，不同 track 必须使用同一种编解码格式。
unified plan 格式中，audio 有两个 media level，每个 media level 对应一个 track，也对应一个 ssrc 进行区分，不同 track 可以使用不同的编解码格式。
planb 和 unified plan 格式的差异注意意义在于：不同音视频流可以支持不同的编解码格式。
当只有一路音频流和一路视频流时，两则一样。

5. sip 呼叫中的 sdp

sip 呼叫中的 sdp 与 webrtc 会有一些显著的区别，下面分别称述。

5.1 网络传输上的区别

sip 呼叫是一套完整的运行在 TCP/UDP 之上的协议，sdp 只是 sip 呼叫中的一部分；webrtc 中的 sdp 需要依赖其它协议(如 http、websocket等)由用户自定义传输。
webrtc 引入了 ICE 协议，致力于打通不同网络之间(如两个处于不同 NAT 下的设备)的连接；sip 呼叫则需要开发者根据网络拓扑类型自定义呼叫方式(如经由一个网关)，以实现不同网络类型的互通，sip 协议本身带来的跨网络连接能力有限(如自带 rport 功能)。
webrtc 一般不同 tracks 之间会复用一个网络链接；sip 中不同 tracks，每个 track 的 rtp、rtcp 都会有自己的网络连接。
webrtc 通过 candidates 传递网络连接信息；sip 的网络连接信息直接写在 sdp 中

// RTC
a=candidate:1 1 udp 2013266431 192.168.2.106 12345 typ host
// SIP
c=IN IP4 192.168.2.106
m=audio 3262 RTP/AVP 107 108 
m=video 3264 RTP/AVP 97 126

5.2 媒体流的区别

webrtc 支持任意路音视频流；sip 只支持一路音频流和一路视频流(通过 BFCP 协议可以扩展多一路屏幕共享视频流)

posted @ 2022-02-07 11:33 小夕nike 阅读(1801) 评论(0) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部

小夕nike