前言
往年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端的反对。关注咱们，咱们会在后续的文章中继续分享音视频、实时通信的技术常识，陪你一起成长为技术专家。