在前面[《01 | 原来通过浏览器访问摄像头这么容易》](https://time.geekbang.org/column/article/107948)[《04 | 可以把采集到的音视频数据录制下来吗？》](https://time.geekbang.org/column/article/109105)等文章中，我向你讲解了 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处理过程图： 如上图所示，两个客户端/浏览器进行1对1通话时，首先要进行信令交互，而**交互的一个重要信息就是 SDP 的交换**。 交换 SDP 的目的是为了让对方知道彼此具有哪些**能力**，然后根据双方各自的能力进行协商，协商出大家认可的音视频编解码器、编解码器相关的参数（如音频通道数，采样率等）、传输协议等信息。 举个例子，A 与 B 进行通讯，它们先各自在 SDP 中记录自己支持的音频参数、视频参数、传输协议等信息，然后再将自己的SDP信息通过信令服务器发送给对方。当一方收到对端传来的SDP信息后，它会将接收到的 SDP 与自己的SDP进行比较，并取出它们之间的交集，这个交集就是它们协商的结果，也就是它们最终使用的音视频参数及传输协议了。 ## 标准 SDP 规范 了解了 SDP 是什么，接下来我们看一下 SDP 规范。其实单论 SDP 规范它并不复杂，但 WebRTC 使用时又对其做了不少修改，所以当你初见完整的 WebRTC 的 SDP 时，可能会一脸茫然。 不过没关系，万事总有头。在本文中，我先带你了解 SDP 的标准规范，然后再一步步深入，相信通过本文的学习，最终你将能基本读懂 WebRTC 所产生的 SDP 信息，从而为后面学习 WebRTC打下坚实的基础。 [标准SDP规范](https://tools.ietf.org/html/rfc4566#page-24)主要包括**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 规范做了一些调整，更详细的信息可以看[这里](https://www.ietf.org/archive/id/draft-nandakumar-rtcweb-sdp-08.txt)，它将SDP按功能分成几大块： - Session Metadata，会话元数据 - Network Description，网络描述 - Stream Description，流描述 - Security Descriptions，安全描述 - Qos Grouping Descriptions， 服务质量描述 下面这张图清晰地表达了它们之间的关系： 通过上图我们可以看出，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 中如何设置音视频的传输码率呢？ 欢迎在留言区与我分享你的想法，也欢迎你在留言区记录你的思考过程。感谢阅读，如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友。