WebRTC SDP 学习笔记

SDP(Session Description Protocol) 是一种会话描述协议，基于文本，其本身并不属于传输协议，需要依赖其它的传输协议（比如 SIP 和 HTTP, WebSocket）来交换必要的媒体信息，用于两个会话实体之间的媒体协商。

WebRTC 的 Offer 和 Answer 包含了 SDP，WebRTC 使用 Offer-Answer 模型交换 SDP。相关的 RFC 包括：

• 1998, RFC2327
• 2006, RFC4566

SDP 描述了媒体会话，网络信息、安全特性、传输策略等，下图中的每一个 SDP 属性都在不同的应用场景下发挥着不同的作用。

SDP 描述分为两部分：
1.session level

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

2.media level

m= (media name and transport address)
c=* (connection information -- optional if included at session level)
a=* (zero or more media attribute lines)

3.Stream Direction
媒体流的方向有四种，分别是 sendonly、recvonly、sendrecv、inactive，它们既可以出现在会话级别描述中也可以出现在媒体级别的描述中。

• sendonly 表示只发送数据，比如客户端推流到 SFU，那么会在自己的 Offer(or Answer) 中携带 senonly 属性
• revonly 表示只接收数据，比如客户端向 SFU 订阅流，那么会在自己的 Offer(or Answer) 中携带 recvonly 属性
• sendrecv 表示可以双向传输，比如客户端加入到视频会议中，既要发布自己的流又要订阅别人的流，那么就需要在自己的 Offer(or Answer) 中携带 sendrecv 属性
• inactive 表示禁止发送数据，比如在基于 RTP 的视频会议中，主持人暂时禁掉用户 A 的语音，那么用户 A 的关于音频的媒体级别描述应该携带 inactive 属性，表示不能再发送音频数据。
  媒体流方向的四个属性很重要，在组装 SDP 时要仔细校验，保证流方向的正确性。

4. SDP 和 Candidate 都是通过信令交换的。

a=ice-options:trickle
trickle 说明 SDP 中没有包含 candidate 信息，Candidate 是通过信令单独交换的，这样可以做到 Connectivity checks 和 Candidate harvesting 并行处理，提高会话建立的速度。

5. Plan B 和 Unified Plan
   Plan B和Unified Plan，就是为了解决如何在同一个SDP中描述多个媒体流支持。Plan B, 仅仅支持一条音频mline, 和一条视频m line, 音频和视频的媒体流的标识（mid）分别被设置成audio和video；如果同个媒体包括多个发送流，那么在m line下，可以列出多行a=ssrc属性；Unified Plan, 一个m line表示一个发送或者接收流，每条m line都可以独立标识mid; 如果存在多个流，那么可以创建出多个条mline。关于Plan B和Unified Plan在发送多个audio流的SDP对比：

Plan B offer
...
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
Unified Plan offer
...
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

通过上面的例子可以看出：
Mid ，Plan B 仅仅有一条m line,且“a=mid:audio”；Unified Plan 有两条m Line, 第一个“a=mid:0”，第二条“a=mid:1”；
Msid，Plan B 每个不同的ssrc 都对应一个随机的 msid，例如 a=ssrc:10 msid:stream-id-1 track-id-1; Unified Plan不需要通过msid来区分流, msid 用“-”来表示；
媒体属性，Plan B由于在同一个m line中描述不同的流，这些流都具有相同的属性;Unified Plan 不同的流放在不同的m line 中，他们的属性可以相同也可以不同，比如rtp 扩展头信息等；
连接端口，Plan B 的多个流都共用相同的连接信息，因此不需要为每条流都单独分配独立连接端口；Unified Plan, 虽然不同的m Line可以有不同的candidate信息，但是在实际使用场景下，大部分时候可以通过BUNDLE 来把不同的流对应到相同的连接端口上，“a=group:BUNDLE 0 1”
通过以上的分析，我们还是可以看出Unified Plan相对于Plan B在灵活性上具有优势。

6.SDP信息详解

• 6.1 来源（o=）
  o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>
  会话所有者有关的参数（Owner/creator and session identifier）。

   <username> 会话发起者的名称。如果不提供则用"-"表示，用户名不能包含空格；
   <sess-id> 主叫方的会话标识符；
   <sess-version> 会话版本号。用0标识的居多；
   <nettype> 网络类型。IN表示Internet网络类型，目前仅定义该网络类型；
   <addrtype> 地址类型。目前支持IPV4和IPV6两种地址类型；
   <unicast-address> 会话发起者的IP地址。
  

• 6.2 会话名称（s=）
  s=<session name>
  本次会话的标题或会话的名称（Session name）。

• 6.3 计时（t=）
  t=<start-time> <stop-time>

  会话的起始时间和结束时间（Time session starts and stops）。

• 6.4 媒体说明（m=）
  m=<media> <port>/<number of ports> <proto> <fmt> ...
  媒体行，描述了发送方所支持的媒体类型等信息（Media information）。

  <media> 媒体名称（audio/video）。表示包含音频类型或视频类型；
  <port>/<number of ports> 流传输端口号。表示在本地端口xxxx上发送音频/视频流；
  <proto> 流传输协议。举例说明：
  
  🌰RTP/SAVPF 表示用UDP传输RTP包；
  🌰TCP/RTP/SAVPF 表示用TCP传输RTP包；
  🌰UDP/TLS/RTP/SAVPF 表示用UDP来传输RTP包，并使用TLS加密；
  最后的 SAVPF 还有其他几种值：AVP, SAVP, AVPF, SAVPF。
  1. AVP 意为 AV profile
  2. S 意为 secure
  3. F 意为 feedback
  <fmt> 从第四位开始都是媒体格式描述。
  

• 6.5 连接数据（c=）
  c=<nettype> <addrtype> <connection-address>
  媒体的连接信息（Connection information）。每个媒体描述中至少包含一个 c = 字段，或者在会话描述中包含一个 c = 字段。

  <nettype> 网络类型。IN表示Internet网络类型，目前仅定义该网络类型；
  <addrtype> 地址类型。目前支持IPV4和IPV6两种地址类型；
  <unicast-address> 会话发起者的IP地址。
  

• 6.6 属性（a=）
  a=<attribute> | <attribute>:<value>
  属性（attribute）是扩展SDP的主要手段，分为会话级属性和媒体级属性:
  会话级属性：添加在第一个媒体描述之前，传达的信息适用于整个会议而不是单个媒体。

  
  🌰a=group:BUNDLE audio video 通过mid标识符把多个媒体属性连接起来；
  🌰a=msid-semantic: WMS ma 表示是webrtc媒体流（Webrtc Media Streams）；
  媒体级属性：媒体描述中添加有关媒体流的信息。
  
  🌰a=mid:audio 上述BUNDLE中用到的媒体标识；
  🌰a=msid:ma ta 连接不同的媒体描述，使用相同的MediaStreams；
  🌰a=sendonly 表示媒体发送端，其他类型：recvonly,sendrecv,inactive；
  🌰a=rtcp:9 IN IP4 0.0.0.0 用来传输rtcp地地址和端口；
  🌰a=rtcp-mux 表示rtp,rtcp包使用同一个端口来传输；
  🌰a=ice-xxx:xxx ice协商过程中的安全验证信息；
  🌰a=fingerprint:xxx 表示dtls协商过程中需要的认证信息；
  🌰a=setup:actpass 表示本客户端在dtls协商过程中，可以做客户端也可以做服务端；
  🌰a=rtpmap:111 opus/48000/2 负载类型111，编码格式opus，48000是时钟，2是通道数；
  🌰a=rtcp-fb:111 nack 支持丢包重传；
  🌰a=rtcp-fb:111 nack pli 支持关键帧丢包重传；
  🌰a=rtcp-fb:111 transport-cc 表示opus编码支持使用rtcp来控制拥塞；
  🌰a=fmtp:111 minptime=10;useinbandfec=1;maxplaybackrate=16000 对opus编码可选的补充说明,minptime代表最小打包时长是10ms，useinbandfec=1代表使用opus编码内置fec特性；
  🌰a=ssrc:1370113029 cname:NMediaAudio cname用来标识一个数据源，ssrc当发生冲突时可能会发生变化，但是cname不会发生变化，也会出现在rtcp包中SDEC中，用于音视频同步；
  🌰a=candidate:1 1 udp 2013266431 x.x.x.x 43342 typ host generation 0 表示候选人的传输地址。
  
  

reference: https://segmentfault.com/a/1190000038272539