WebRTC中SDP的整体结构
知道了 SDP 标准规范之后，接下来介绍 WebRTC 中的 SDP，看看它与标准 SDP 有什么区别。
实际上，WebRTC 为了实现音视频实时通信，对标准 SDP 做了很大调整，其整体结构如图 7.2 所示。从图中可以看到，WebRTC 中的 SDP 并没有打破标准 SDP 的结构，它同样包括会话描述和媒体描述两大部分。所不同的是，它对媒体描述中的内容做了大幅增加以满足自身的需求。由于 WebRTC 中 SDP 的会话描述格式与标准 SDP 的会话描述格式是一致的，因此以下我们仅对 WebRTC 中 SDP 的媒体描述进行详细介绍。我们可以按功能将 WebRTC 中 SDP 的媒体描述内容划分成四大类：媒体信息、网络描述、安全描述以及服务质量描述。
媒体信息
属于标准 SDP 中媒体描述的内容，同时也是 SDP 中最核心的内容。其最重要的是 “m=” 行描述。在 “m＝” 行中描述了媒体类型、传输类型、PayloadType 等信息。对于每种媒体数据（音频数据、视频数据），可以选择多种编解码器（Opus、iLBC、H264……）对其进行编解码。每种编解码器的详细参数可以通过 “a=rtpmap” 属性进一步解释。
网络描述
属于标准 SDP 中媒体描述的内容。它记录了传输媒体数据时使用的网络信息，如IP地址、端口号、连接复用等信息。对于 WebRTC 而言，其网络传输是由另外一套复杂的机制实现的，所以标准网络描述中的 “c=” 属性会被 WebRTC 忽略。其他几个属性是 WebRTC 增加的。其中 “a=candidate” 属性是老版 WebRTC 增加的，但在新版的 WebRTC 中又将其废弃了。不过需要注意的是，在一些流媒体服务器上，为了方便，依然使用 “a=candidate” 属性，WebRTC对其是兼容的。“a=group：BUNDLE” 属性用于指明哪些媒体数据可以复用同一个传输通道。这里所谓的复用传输通道是指多种类型的媒体数据使用同一条网络连接传输数据，这样做可以节约 ICE 资源。“rtcp-mux” 属性用于指明 RTCP 是否与 RTP 复用同一端口，同样它也是出于节约 ICE 资源的目的。“a=sendrecv” 属性用于指明媒体数据的传输方向是双向的（WebRTC 终端既可以接收数据，也可以发送数据）。除此之外，在设置数据传输方向时，还可以选择 sendonly（仅发送）、recvonly（仅接收）、inactive（不进行传输）这几个值。“ice-options” 属性用于指明 WebRTC 收集 ICE Candidate 的策略。新版 WebRTC 默认使用 Trikle-ICE 模式，这样可以加快通信双方连接的速度。除此之外，还可以将其设置为 renominotion 模式。“a=extmap” 属性用于指明 RTP 使用的扩展头，关于这部分内容将在 7.6 节做详细介绍。rtcp-resize 属性用于指明缩减 RTCP 包的大小，具体缩减的时机是根据用户带宽大小来决定的。
安全描述
这部分内容是 WebRTC 增加到 SDP 规范中的，也属于标准 SDP 中媒体描述的内容。由于在浏览器上进行一对一通信需要很好的安全性，而标准 SDP 在这方面的约束又比较薄弱，因此 WebRTC 自己定义了一套安全机制。在这套安全机制中，安全描述的内容仅用于通信双方交换一些必要的信息。
服务质量描述
这部分内容也是 WebRTC 为 SDP 新增的，同样也属于标准 SDP 中媒体描述的内容。在 WebRTC 中，服务质量包含的内容非常多，SDP 只控制了其中一小部分服务质量的开关，这些服务质量的开关都是通过 “a=rtcp-fb” 属性设置的。在媒体协商时，发起协商一方的 Offer 中指明 WebRTC 开启哪些 RTCP 反馈，应答一方则在 Answer 中确认是否真的开启对应的 RTCP 反馈。
以上就是 WebRTC 中使用的 SDP 的整体结构，以及其与标准 SDP 的主要区别。从中可以看出，安全描述和服务质量是 WebRTC 根据自身要求添加进来的，这两块内容对于我们理解 WebRTC 是非常关键的。另外，WebRTC 的网络传输是一套单独的体系，SDP 中的网络描述只起到一些辅助作用。接下来对 WebRTC 中 SDP 的几个重要信息做详细介绍。