共计 4426 个字符，预计需要花费 12 分钟才能阅读完成。
前言
往年 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 端的反对。关注咱们，咱们会在后续的文章中继续分享音视频、实时通信的技术常识，陪你一起成长为技术专家。
