谈谈 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：

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 和 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 端的支持。关注我们，我们会在后续的文章中持续分享音视频、实时通信的技术知识，陪你一起成长为技术专家。