在前面 《01 | 原来通过浏览器访问摄像头这么容易》 《04 | 可以把采集到的音视频数据录制下来吗？》 等文章中，我向你讲解了 WebRTC 如何采集音视频数据，以及如何将它们录制成文件等相关内容。但那些知识不过是个“ 开胃菜”，WebRTC 真正核心的知识将从本文开始陆续向你展开。不过从本文开始，知识的难度会越来越高，你一定要做好心理准备。
说到 WebRTC 运转的核心，不同的人可能有不同的理解：有的人认为 WebRTC 的核心是音视频引擎，有的人认为是网络传输，而我则认为 WebRTC 之所以能很好地运转起来，完全是由 SDP 驱动的，因此 SDP 才是 WebRTC 的核心。
掌握了这个核心，你就知道 WebRTC 都支持哪些编解码器、每次通话时都有哪些媒体（通话时有几路音频 / 视频）以及底层网络使用的是什么协议，也就是说你就相当于拿到了打开 WebRTC 大门的一把钥匙。
由此可见，SDP 在 WebRTC 中是何等重要。下面就让我们正式进入正题吧！
SDP 是什么
在正式讲解 SDP 之前，你首先要弄清楚 SDP 是什么？SDP（Session Description Protocal）说直白点就是用文本描述的各端（PC 端、Mac 端、Android 端、iOS 端等）的 能力。这里的 能力 指的是各端所支持的音频编解码器是什么，这些编解码器设定的参数是什么，使用的传输协议是什么，以及包括的音视频媒体是什么等等。
下面让我们来看一个真实的 SDP 片段吧！
v=0
o=- 3409821183230872764 2 IN IP4 127.0.0.1
...
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
...
a=rtpmap:111 opus/48000/2
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
...
如上面的 SDP 片段所示，该 SDP 中描述了一路音频流，即 m=audio，该音频支持的 Payload ( 即数据负载 ) 类型包括 111、103、104 等等。
在该 SDP 片段中又进一步对 111、103、104 等 Payload 类型做了更详细的描述，如 a=rtpmap:111 opus/48000/2 表示 Payload 类型为 111 的数据是 OPUS 编码的音频数据，并且它的采样率是 48000，使用双声道。以此类推，你也就可以知道 a=rtpmap:104 ISAC/32000 的含义是音频数据使用 ISAC 编码，采样频率是 32000，使用单声道。
交换 SDP 信息
下面是 1 对 1 WebRTC 处理过程图：
WebRTC 处理过程图
如上图所示，两个客户端 / 浏览器进行 1 对 1 通话时，首先要进行信令交互，而 交互的一个重要信息就是 SDP 的交换。
交换 SDP 的目的是为了让对方知道彼此具有哪些 能力，然后根据双方各自的能力进行协商，协商出大家认可的音视频编解码器、编解码器相关的参数（如音频通道数，采样率等）、传输协议等信息。
举个例子，A 与 B 进行通讯，它们先各自在 SDP 中记录自己支持的音频参数、视频参数、传输协议等信息，然后再将自己的 SDP 信息通过信令服务器发送给对方。当一方收到对端传来的 SDP 信息后，它会将接收到的 SDP 与自己的 SDP 进行比较，并取出它们之间的交集，这个交集就是它们协商的结果，也就是它们最终使用的音视频参数及传输协议了。
标准 SDP 规范
了解了 SDP 是什么，接下来我们看一下 SDP 规范。其实单论 SDP 规范它并不复杂，但 WebRTC 使用时又对其做了不少修改，所以当你初见完整的 WebRTC 的 SDP 时，可能会一脸茫然。
不过没关系，万事总有头。在本文中，我先带你了解 SDP 的标准规范，然后再一步步深入，相信通过本文的学习，最终你将能基本读懂 WebRTC 所产生的 SDP 信息，从而为后面学习 WebRTC 打下坚实的基础。
标准 SDP 规范 主要包括 SDP 描述格式 和 SDP 结构，而 SDP 结构由 会话描述 和 媒体信息描述 两个部分组成。
其中，媒体信息描述是整个 SDP 规范中最重要的知识，它又包括了：
- 媒体类型
- 媒体格式
- 传输协议
- 传输的 IP 和端口
下面我们就以上这些知识逐一进行讲解。
1. SDP 的格式
SDP 是由多个 <type>=<value> 这样的表达式组成的。其中， <type> 是一个字符， <value> 是一个字符串。需要特别注意的是， “=” 两边是不能有空格的。如下所示：
v=0
o=- 7017624586836067756 2 IN IP4 127.0.0.1
s=-
t=0 0
...
SDP 由一个会话级描述（session level description）和多个媒体级描述（media level description）组成。
- 会话级（session level）的作用域是整个会话，其位置是 从 v= 行开始到第一个媒体描述为止。
- 媒体级（media level）是对单个的媒体流进行描述，其位置是 从 m= 行开始到下一个媒体描述（即下一个 m=）为止。
另外，除非媒体部分重新对会话级的值做定义，否则会话级的值就是各个媒体的缺省默认值。让我们看个例子吧。
v=0
o=- 7017624586836067756 2 IN IP4 127.0.0.1
s=-
t=0 0
// 下面 m= 开头的两行，是两个媒体流：一个音频，一个视频。
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 126
...
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 122 127 121 125 107 108 109 124 120 123 119 114 115 116
...
上面是一个特别简单的例子，每一行都是以一个字符开头，后面紧跟着 等于号（=），等于号后面是一串字符。
从“v=”开始一直到“m=audio”，这之间的描述是会话级的；而后面的两个“m=”为媒体级。从中可以看出，在该 SDP 描述中有两个媒体流，一个是音频流，另一个是视频流。
2. SDP 的结构
了解了 SDP 的格式，下面我们来看一下 SDP 的结构，它由 会话描述 和 媒体描述 两部分组成。
（1）会话描述
会话描述的字段比较多，下面四个字段比较重要，我们来重点介绍一下。
第一个，v=（protocol version，必选）。例子：v=0 ，表示 SDP 的版本号，但不包括次版本号。
第二个，o=（owner/creator and session identifier，必选）。例子： o=<username> <session id> <version> <network type> <address type> <address>，该例子是对一个会话发起者的描述。其中，
- o= 表示的是对会话发起者的描述；
<username>：用户名，当不关心用户名时，可以用 “－” 代替 ；<session id>：数字串，在整个会话中，必须是唯一的，建议使用 NTP 时间戳；<version>：版本号，每次会话数据修改后，该版本值会递增；<network type>：网络类型，一般为“IN”，表示“internet”；<address type>：地址类型，一般为 IP4；<address>：IP 地址。
第三个，Session Name（必选）。例子： s=<session name>，该例子表示一个会话，在整个 SDP 中有且只有一个会话，也就是只有一个 s=。
第四个，t=（time the session is active，必选）。例子： t=<start time> <stop time>，该例子描述了会话的开始时间和结束时间。其中， <start time> 和 <stop time> 为 NTP 时间，单位是秒；当 <start time> 和 <stop time> 均为零时，表示持久会话。
（2）媒体描述
媒体描述的字段也不少，下面我们也重点介绍四个。
第一个，m=（media name and transport address，可选）。例子： m=<media> <port> <transport> <fmt list>，表示一个会话。在一个 SDP 中一般会有多个媒体描述。每个媒体描述以“m=”开始到下一个“m=”结束。其中，
<media>：媒体类型，比如 audio/video 等；<port>：端口；<transport>：传输协议，有两种——RTP/AVP 和 UDP；<fmt list>：媒体格式，即数据负载类型 (Payload Type) 列表。
第二个，a=*（zero or more media attribute lines，可选）。例子： a=<TYPE>或 a=<TYPE>:<VALUES>， 表示属性，用于进一步描述媒体信息；在例子中， 指属性的类型， a= 有两个特别的属性类型，即下面要介绍的 rtpmap 和 fmtp。
第三个，rtpmap（可选）。例子： a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encodingparameters>]。
- rtpmap 是 rtp 与 map 的结合，即 RTP 参数映射表。
<payload type>：负载类型，对应 RTP 包中的音视频数据负载类型。<encoding name>：编码器名称，如 VP8、VP9、OPUS 等。<sample rate>：采样率，如音频的采样率频率 32000、48000 等。<encodingparameters>：编码参数，如音频是否是双声道，默认为单声道。
第四个，fmtp。例子： a=fmtp:<payload type> <format specific parameters>。
- fmtp，格式参数，即 format parameters；
<payload type>，负载类型，同样对应 RTP 包中的音视频数据负载类型；< format specific parameters>指具体参数。
以上就是 SDP 规范的基本内容，了解了上面这些内容后，下面我们来看一下具体的例子，你就会对它有更清楚的认知了。
v=0
o=- 4007659306182774937 2 IN IP4 127.0.0.1
s=-
t=0 0
// 以上表示会话描述
...
// 下面的媒体描述，在媒体描述部分包括音频和视频两路媒体
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
...
a=rtpmap:111 opus/48000/2 // 对 RTP 数据的描述
a=fmtp:111 minptime=10;useinbandfec=1 // 对格式参数的描述
...
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
...
// 上面是音频媒体描述，下面是视频媒体描述
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 122 127 121 125 107 108 109 124 120 123 119 114 115 116
...
a=rtpmap:96 VP8/90000
...
从上面的例子中，你可以清楚地看到在这段 SDP 片段里包括 会话信息 与 媒体信息。在媒体信息中又包括了 音频流信息 和 视频流信息。
在音频流和视频流信息中，通过 rtpmap 属性对它们做了进一步的说明。如音频流支持 OPUS 和 ISAC 编码，OPUS 编码的采样率是 48000，双声道，而 ISAC 编码的采样率可以是 16000 或 32000， 它们都是单声道。视频流支持 VP8，采样率是 90000 。
WebRTC 中的 SDP
WebRTC 对标准 SDP 规范做了一些调整，更详细的信息可以看 这里，它将 SDP 按功能分成几大块：
- Session Metadata，会话元数据
- Network Description，网络描述
- Stream Description，流描述
- Security Descriptions，安全描述
- Qos Grouping Descriptions， 服务质量描述
下面这张图清晰地表达了它们之间的关系：
WebRTC 使用的 SDP 结构图
通过上图我们可以看出，WebRTC 按功能将 SDP 划分成了五部分，即会话元数据、网络描述、流描述、安全描述以及服务质量描述。WebRTC SDP 中的会话元数据（Session Metadata）其实就是 SDP 标准规范中的 会话层描述； 流描述、网络描述 与 SDP 标准规范中的 媒体层描述 是一致的；而 安全描述 与 服务质量描述 都是新增的一些属性描述。下图我们来看一个具体的例子：
...
//======= 安全描述 ============
a=ice-ufrag:1uEe // 进入连通性检测的用户名
a=ice-pwd:RQe+y7SOLQJET+duNJ+Qbk7z// 密码，这两个是用于连通性检测的凭证
a=fingerprint:sha-256 35:6F:40:3D:F6:9B:BA:5B:F6:2A:7F:65:59:60:6D:6B:F9:C7:AE:46:44:B4:E4:73:F8:60:67:4D:58:E2:EB:9C //DTLS 指纹认证，以识别是否是合法用户
...
//======== 服务质量描述 =========
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 goog-remb // 使用 google 的带宽评估算法
a=rtcp-fb:96 transport-cc // 启动防拥塞
a=rtcp-fb:96 ccm fir // 解码出错，请求关键帧
a=rtcp-fb:96 nack // 启用丢包重传功能
a=rtcp-fb:96 nack pli // 与 fir 类似
...
上面的 SDP 片段是摘取的 WebRTC SDP 中的安全描述与服务质量描述，这两块描述在标准 SDP 规范中没有明确定义，它更多属于 WebRTC 业务的范畴。
其中，安全描述起到两方面的作用，一方面是进行网络连通性检测时，对用户身份进行认证；另一方面是收发数据时，对用户身份的认证，以免受到对方的攻击。从中可以看出 WebRTC 对安全有多重视了
服务质量描述指明启动哪些功能以保证音视频的质量，如启动带宽评估，当用户发送数据量太大超过评估的带宽时，要及时减少数据包的发送；启动防拥塞功能，当预测到要发生拥塞时，通过降低流量的方式防止拥塞的发生等等，这些都属于服务质量描述的范畴。
为便于你更好地理解和使用 SDP，接下来我再分享一个真实的例子。
下面这段 SDP 是我从一个真实的 1 对 1 场景中截取出来的 WebRTC SDP 的片段。我在这段 SDP 上做了详细的注释，通过上面知识的学习，现在你应该也可以看懂这段 SDP 的内容了。
//============= 会话描述 ====================
v=0
o=- 7017624586836067756 2 IN IP4 127.0.0.1
s=-
t=0 0
...
//================ 媒体描述 =================
//================ 音频媒体 =================
/*
* 音频使用端口 1024 收发数据
* UDP/TLS/RTP/SAVPF 表示使用 dtls/srtp 协议对数据加密传输
* 111、103 ... 表示本会话音频数据的 Payload Type
*/
m=audio 1024 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 126
//============== 网络描述 ==================
// 指明接收或者发送音频使用的 IP 地址，由于 WebRTC 使用 ICE 传输，这个被忽略。
c=IN IP4 0.0.0.0
// 用来设置 rtcp 地址和端口，WebRTC 不使用
a=rtcp:9 IN IP4 0.0.0.0
...
//============== 音频安全描述 ================
//ICE 协商过程中的安全验证信息
a=ice-ufrag:khLS
a=ice-pwd:cxLzteJaJBou3DspNaPsJhlQ
a=fingerprint:sha-256 FA:14:42:3B:C7:97:1B:E8:AE:0C2:71:03:05:05:16:8F:B9:C7:98:E9:60:43:4B:5B:2C:28:EE:5C:8F3:17
...
//============== 音频流媒体描述 ================
a=rtpmap:111 opus/48000/2
//minptime 代表最小打包时长是 10ms，useinbandfec=1 代表使用 opus 编码内置 fec 特性
a=fmtp:111 minptime=10;useinbandfec=1
...
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
...
//================= 视频媒体 =================
m=video 9 UDP/TLS/RTP/SAVPF 100 101 107 116 117 96 97 99 98
...
//================= 网络描述 =================
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
...
//================= 视频安全描述 =================
a=ice-ufrag:khLS
a=ice-pwd:cxLzteJaJBou3DspNaPsJhlQ
a=fingerprint:sha-256 FA:14:42:3B:C7:97:1B:E8:AE:0C2:71:03:05:05:16:8F:B9:C7:98:E9:60:43:4B:5B:2C:28:EE:5C:8F3:17
...
//================ 视频流描述 ===============
a=mid:video
...
a=rtpmap:100 VP8/90000
//================ 服务质量描述 ===============
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack // 支持丢包重传，参考 rfc4585
a=rtcp-fb:100 nack pli
a=rtcp-fb:100 goog-remb // 支持使用 rtcp 包来控制发送方的码流
a=rtcp-fb:100 transport-cc
...
从上面这段 SDP 中你应该可以总结出： SDP 是由一个会话层和多个媒体层组成的；而对于每个媒体层，WebRTC 又将其细划为四部分，即媒体流、网络描述、安全描述和服务质量描述。
并且在上面的例子中有两个媒体层——音频媒体层和视频媒体层，而对于每个媒体层，也都有对应的媒体流描述、网络描述、安全描述及服务质量描述，是不是非常清晰？
小结
本文为你详细描述了 SDP 的标准规范以及 WebRTC 对 SDP 规范的修改，为便于你理解，还通过一系列实际的例子，向你展示了在 WebRTC 中使用的 SDP 是什么样子。
总结起来就是，SDP 是由一个会话层与多个媒体层组成，每个媒体层又分为媒体流描述、网络描述、安全描述和服务质量描述，而每种描述下面又是一堆细节的知识点。
当然，通过本篇文章你也许不能一下将 SDP 的所有细节都了解清楚。但有了这个基础之后，通过后面不断地积累，最终你将在大脑中形成一个 SDP 的知识图谱，到那时你再看 SDP 时就游刃有余了。
思考时间
学习完上面的正文后，现在请你思考一下，在 SDP 中如何设置音视频的传输码率呢？
欢迎在留言区与我分享你的想法，也欢迎你在留言区记录你的思考过程。感谢阅读，如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友。
