WebRTC SDP协议，WebRTC SDP格式详解

什么是WebRTC SDP协议

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

下面这个链接展示了一个完整的SDP例子:

[一个不错的 WebRTC 的 SDP 例子分析https://webrtchacks.com/sdp-anatomy/](https://webrtchacks.com/sdp-anatomy/)

为什么需要SDP

会话就会话呗，为什么需要描述呢？因为参与会话的各个成员的能力不对等、用户环境与配置不一致等。比如有人可能想到使用所有人都支持的媒体格式。我们暂且不讨论是否存在这样的一种格式，我们试想一下 如果参与本次会话的成员都支持更高质量的通话格式，那么使用通用的、普通质量的格式是不是影响了体验？既然无法使用固定的格式配置，那么会话信息的描述就很有必要了。

也就是说一次会话使用何种配置并不是由某一个成员说了算，必须所有人的意见达成一致，这样才能确保所有人都能参与会话，所以这里就涉及一个协商的问题，我们需要SDP协商出兼容最优的解决方案。

WebRTC SDP格式

SDP使用的是<type>=<value>的格式。SDP是由若干行<type>=<value>的文本组成。

其中<type>必须是一个区分大小写的字符，<value>是结构化文本，其格式取决于<type>。通常，<value>是由单个空格字符或自由格式字符串分隔的多个字段，并且是区分大小写的 ，除非特定字段另有定义。”=” 符号的两边不能有空格。

对于比较复杂的行还会在空格等级的基础上继续拓展使用分号 ; 作为各个参数之间的分隔符，例如:

a=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f

下面举例简单说一下SDP的行内容解析，更多详细的SDP行内容表示的意思学者可以通过上面给的链接例子自行查阅资料学习，这样才能加深印象：

v= 所在行，代表版本，目前一般是`v=0`.

m= 所在行是media line（媒体行，又叫m line）。两个m line之间或者最后一个m line到结尾的行都是用来描述一种媒体数据的（叫media section），
包括数据格式、网络传输等信息。例如，m=audio 开头的描述的是音频信息，以m=video开头的描述的是视频数据的信息。

a=candidate所在的行描述了这个media section将要用到的ICE Candidate。

a=recvonly 所在的行描述了这个media section的方向，可选值有receonly（只接收）、sendonly（只发送）、sendrecv（同时接收和发送）。

a=rtpmap 所在的行描述了这个media section所支持的格式。

WebRTC中的SDP总体上可以分为以下几个部分：

• session metadata:描述整个会话的基本信息，行开头为v=、o=、t=等；
• network description：描述网络传输的信息，行开头为c=、a=candidate等；
• stream description：描述媒体流信息，行开头为m=、a=rtpmap、afmtp、a=sendrecv等；
• security description：描述数据加密，身份认证等相关信息，行开头为a=crypto、a=ice-frag、a=ice-pwd、a=fingerprint等。
• DTSL角色描述:行开头为a=setup等。
• ICE策略描述：行开头为a=ice-options:trickie、a=ice-lite、a=ice-option:renomination等。
• Qos，grouping description：描述服务质量，传输层复用相关信息，行开头为a=rtcp-fb、a=group、a=rtcpmux等。

SDP的两种Plan

SDP的两种Plan是指在传输多路同类型媒体流时两种SDP的格式，多路同类型媒体流的例子有”录屏+相机”或者多个相机的情景。这两种SDP格式分别是Plan B和Unified Plan，目前WebRTC标准采纳的是nified Plan，并且代码已经支持。

Plan B:同类型媒体只有一个m line，同类型的多个媒体流之间通过msid区分；

Unified Plan：每个媒体流都有一个m line，比如有两路视频，就会有两个video m line。

ORTC

ORTC说白了就是WebRTC中使用SDP的主要替代方案或者说是SDP的规范版。

既然已经有了SDP，而且目前已经在WebRTC中有了相关的支持，为什么还需要ORTC呢？这就要从SDP的弊端说起了。

首先WebRTC刚开始搞的还不是很火，至于谷歌和firefox在搞，其他一些主流的浏览器厂商并不是很配合，所以自然而然地就缺少了一个相关的规范。随着这几年WebRTC开始火起来，一些巨头们看到WebRTC这个趋势，就想加入进来了，但是又不想全由谷歌一家说了算，所以就开始挑战WebRTC，挑刺搞规范了。

其中SDP被挑的几个主要问题就是：

1，sdp格式晦涩难懂,这确实是事实，内容多还不说，每次使用还得像查字典一样去查。

2，太多高层次的API，以及没有严格的标准规范，火狐和chome一些写法还搞得不一样。

3，无法真正解决历史遗留系统的兼容性问题。

4，要求没有得到应答。

更多关于ORTC的相关知识：www.ortc.org

关注我，一起进步，人生不止coding！！！