谈谈 WebRTC 的 SDP Unified Plan

前言
今年2月份，webrtc M89 的正式发布，在Release note 提出了一个重要更新，即废webrtc Plan B SDP 语义，推荐使用标准SDP格式：Unified Plan。WebRTC1.0 已经正式成为 W3C 标准，主流浏览器基本都支持UnifiedPlan SDP。Webrtc将于21年开始逐步废弃Plan B SDP，直到移除，后续时间计划如下：

M89 (2021.02)：在开发者控制台增加废弃警告
M93 (2021.08): Plan B 被移除掉, 但是增加了选项，可以延长移除的截止日期
M96 (2022.01): Plan B 将彻底移除
那么，什么是Unified Plan，和Plan B有什么差异，会在什么场景下用到？我们今天来谈谈 SDP 以及 Unified Plan。

01 SDP介绍

在一些音视频多媒体交换方案中，比如点播HTTP-FLV、直播RTMP，由于音视频会话建立需要的信息都是确定的，他们有预先约定的音视频格式来支持音视频，建立会话的双方无需进行能力协商，但是这样会降低或者说没有充分发挥端到端的音视频能力。而一些松耦合多媒体通讯系统的建立过程中，对会话双方能力的描述，特别是对于媒体信息的描述是非常重要的，必须要有一种标准规范的形式来进行会话描述，这样才能保证会议创建者和参与者能够对一个会话描述有一致的认识，比如多媒体通讯系统的双方，都必须明确知道对方的媒体能力，例如，如何建立连接通道，采用何种编码格式，使用哪些RTP扩展，SDP(Session Description Protocol)就是这样一种会话描述协议。1998年4月在IETF RFC2327中定义了SDP标准，并随后在2006年7月出版的新的修订规范RFC4566作为RFC2327的更新。当前SDP被广泛用于SAP, RTSP, SIP等多媒体通讯协议中，包括webrtc也是以RFC4566（SDP）为基本蓝本，然后配合RFC3264关于offer/answer交互模式来进行媒体协商。

02 SDP 格式

SDP是基于文本，其本身并不属于传输协议，仅仅是对会话进行文本描述，SDP的协商和交换通常需要依赖其它的传输协议（比如 SIP 和 HTTP），我们先看一个典型的webrtc SDP：

v=0
o=- 6027151064452464111 2 IN IP4 127.0.0.1
s=-
t=0 0
a=msid-semantic: WMS 32776
m=audio 60016 RTP/AVPF 111
c=IN IP4 192.168.3.69
a=rtcp:9 IN IP4 0.0.0.0
a=candidate:2881305691 1 udp 2122260223 192.168.3.69 60016 typ host generation 0 network-id 1 network-cost 50
a=ice-ufrag:187458893310337024
a=ice-pwd:GFRpXLO0g2pQ7YpWXIXmPFmH
a=ice-options:trickle
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:5 http://www.ietf.org/id/draft-...
a=sendrecv
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptim
e=10;useinbandfe
c=1
a=ssrc:2878130877 cname:FjkQJG2DE02h2dGv
a=ssrc:2878130877 msid:32776 audio-default
a=ssrc:2878130877 mslabel:32776
a=ssrc:2878130877 label:audio-default
SDP 会话描述包含若干行以下形式的文本：<type>=<value>；<type>是大小写敏感的单个字符，<value>一个结构化的文本字符串，其格式依赖于<type>，通常 <value> 或者是若干以单个空格分界的字段，或者是一个自由格式的字符串。

通常一个SDP主要包括以下内容：

会话描述；由会话级部分组成，以“v=”行开头，并继续到第一个媒体级;
媒体描述；媒体描述以“m=”行开始，直到下一个媒体描述或整个会话描述的结束。
在这个webrtc SDP中，我们可以看到关于会话描写信息的细节，有会话的版本（v=），发起人和会话标识符（o=）, 会话名称(s=)，会话处于活动状态的时间说明（t=）等。值得特别指出的是会话属性行a=msid-semantic:WMS 32776，这个是webrtc提出的一个关于跨会话流标识标准草案，主要用途是用于关联不同媒体描述行中的多个rtp ssrc，在audio媒体描述的ssrc属性，可以看到a=ssrc:2878130877 msid:32776 audio-default, 使用了会话属性定义的msid 32776。

这里媒体描述仅有一条audio m Line, 通过SDP可以了解到关于audio的具体细节，如传输协议(RTP/AVPF)，媒体格式(opus/48000/2)，多播或远端（单播地址和端口（192.168.3.69:60016）, 可信赖的接洽信息（a=candidate）, ice协商过程中的安全验证信息，以及发送RTP流的SSRC等信息。

其中媒体描述中涉及到ICE 连接描述规范可以参考RFC5245;Rtcp-mux在单个端口复用RTP和RTCP可以参考RFC5761；而关于rtp扩展头extmap 标准定义，又需要参考其他相关RFC标准或者草案。

由此，我们发现SDP协议格式本身其实比较简单，由于基于文本，可读性比较强，但是由于不同的应用场景（比如传统 SIP 视频会议或者 RTC 场景）下扩展出的众多纷繁复杂的属性及其含义，这些属性散落在众多的 RFC 以及草案之中，需要很好的理解一个SDP就需要花大量时间来对标准进行研究。

03 SDP Plan B 和 Unified Plan

在一些类似于视频会议场景下，媒体会话参与者需要接收或者发送多个流，例如一个源端，同时发送多个左右音轨的音频，或者多个摄像头的视频流；在2013年，提出了2个不同的SDP IETF草案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
通过这例子，我们可以看到Plan B和Unified Plan的一些差异

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在灵活性上具有优势。虽然webrtc会在最近废弃PlanB，但是对于一些webrtc native客户端的支持，以及对老版本chrome浏览器的支持，可能对于媒体后台MCU，SFU 对Plan B的支持还需要在很长一段时间内存在。

拍乐云打造的基于PaaS平台的音视频云服务，除了提供桌面端、移动端原生SDK和多种跨平台SDK外，也提供Web端的支持。关注我们，我们会在后续的文章中持续分享音视频、实时通信的技术知识，陪你一起成长为技术专家。