WebRTC技术文档 -- 4.SDP（笔记）

SDP：Session Description Protocol，会话描述协议。

4.1 SDP的标准规范

4.1.1 SDP的组织结构

在整个SDP中，只能有一个会话描述，可以有多个媒体描述。

SDP以<type>=<value>的格式描述会话内容。<type>表示描述的目标，它由单个字符构成；<value>是对<type>的解释或约束。

会话包含的<type>有v（protocol version，协议版本）、o（owner/creator and session identifier，会话的创建者）、s（session name，会话名）、t（time the session is active，会话时长）。媒体包含的<type>主要是m（media，媒体）。公共的<type>有c（connection information，网络信息）、a（attribute，属性）等。

4.1.2 SDP字段含义及格式

4.2 WebRTC中的SDP

WebRTC引入SDP来描述媒体信息，用于媒体协商时决定双方是否可以进行通信。WebRTC对媒体描述中的内容做了大幅增加以满足自身的需求。

4.2.1 m=

格式：m=<media> <port> <transport> <fmt list> ...

<media>表示媒体类型，可以是audio、video等。

<port>表示该媒体使用的端口号。WebRTC不使用SDP中描述的网络信息，该端口号对其没有意义。

<transport>表示使用的传输协议，可以是UDP、TCP等。

例如UDP/TLS/RTP/SAVFP表示：传输时底层使用UDP；UDP之上使用DTLS协议交换证书；证书交换好后，由RTP传输媒体数据，保证传输的可靠性；媒体数据的安全性由SRTP负责，即对RTP包中的Body部分进行加密；传输时使用RTCP的feekback机制对传输信息进行实时反馈（SAVPF，SRTP Audio Video Profile Feedback），以便进行拥塞控制。

<fmt list>表示媒体数据类型，一般为PayloadType列表，其具体含义用"a=rtpmap"阐述。

4.2.2 a=rtpmap

表示PayloadType与编码器的映射，每个PayloadType对应一个编码器。

格式：a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encodingparameters>]

示例：a=rtpmap:111 opus/48000/2

表示PayloadType值为111的编码器是Opus，其时钟频率（采样率）为48000Hz，音频通道数为2。

4.2.3 a=fmtp

fmtp（format parameters）用于指定媒体数据格式。

格式：a=fmtp:<format> <format specific parameters>

示例：a=fmtp:111 minptime=10;useinbandfec=1

表示PayloadType值为111的数据（Opus数据）：以10ms长的音频数据为一帧，且数据经FEC（Forward Error Correction，前向纠错）编码。

4.2.4 rtx

示例：a=rtpmap:97 rtx/90000

          a=fmtp:97 apt=96

rtx表示丢包重传，apt（associated payload type）的值为96，说明96和97是关联在一起的，PT=97是PT=96的补充。当WebRTC使用的媒体数据类型（PayloadType）为96，如果出现丢包需要重传，重传数据包的PayloadType为97。

4.2.5 red

red（Redundant coding，冗余代码）是一种在WebRTC中使用的FEC算法，用于防止丢包。默认情况下WebRTC会将VP8/H264等编码器编码后的数据再交由red模块编码，生成带一些冗余信息的数据包，当传输中某个包丢了，可以通过其他包将其恢复回来，而不用重传丢失的包。

4.2.6 a=ssrc

SSRC（Synchronization Source，同步源标识）是媒体源的唯一标识，每一路媒体流都有唯一的SSRC来标识。

4.2.7 a=setup

格式：a=setup:<role>

用来设置使用DTLS协议时通信双方的角色。role包括：active（客户端）、passive（服务端）和actpass（既可以是客户端又可以是服务端，由另一端决定）。

一般情况下，第一个加入房间的终端默认为actpass，后面加入的终端为active。

4.2.8 a=ice-ufrag和a=ice-pwd

用于验证WebRTC客户端是否有效。通信双方可以从彼此的SDP中获取对方的ice-ufrag和ice-pwd信息，用这两个信息来验证用户的合法性。

4.2.9 a=fingerprint

用于验证加密证书的有效性。通过DTLS协议交换证书前，各端会先给各自的证书生成一个指纹（fingerprint），将指纹放到SDP中通过信令交换给对方。通过DTLS协议交换证书后，双方拿到证书重新生成指纹跟SDP中的指纹对比是否一致。

4.2.10 a=extmap

表示RTP Header扩展映射表，该属性在RFC 8285中做了详细说明。RTP的扩展头是以32位的整数倍增加的，即每个扩展头最小是4个字节。

格式：a=extmap:<value> <URI> <extensionattributes>

4.2.11 a=rtcp-fb

用来描述服务质量。在WebRTC中，rtcp-fb（rtcp feedback）有两层含义：一是指RTCP消息中专门反馈信息的一类消息；二是指SDP中使用的"a=rtcp-fb"属性，该属性可以用来设置WebRTC终端支持哪些rtcp feedback消息。

4.3 WebRTC的安全机制

4.3.1 应用级防护

用户在使用音视频通信产品时，一般要先进行注册，然后通过用户名/密码的方式登录到应用系统，这一级别的防护称为应用级防护，不属于WebRTC范畴。

4.3.2 信令级防护

用户通过第一级防护后，可以获得WebRTC信令服务器的地址，通过信令服务器进行媒体协商。媒体协商成功后，通信双方可以从彼此的SDP中获取对方的用户名/密码，即ice-ufrag和ice-pwd信息，用这两个信息来验证用户的合法性。

通信双方彼此发送STUN Binding请求（携带ice-ufrag和ice-pwd），当对方收到请求后，验证请求中的ice-ufrag和ice-pwd与自己SDP中的是否一致。

4.3.3 媒体数据加密

当二级防护通过后，通信双方还会使用DTLS协议彼此交换证书，证书中保存的最重要的信息就是公钥。例如ClientA向ClientB发送媒体数据，ClientA用ClientB的公钥对数据加密，然后再打包成SRTP发送给ClientB。ClientB使用自己的私钥将加密的数据解密。

4.4 PlanB与UnifiedPlan

目前WebRTC中的SDP包含PlanB和UnifiedPlan两种规格。PlanB由标准SDP演化而来，UnifiedPlan则是代替PlanB的SDP新规格。

它们之间最大的区别是：

在PlanB规格中只有两个媒体描述，即音频媒体描述（m=audio......）和视频媒体描述（m=video......），如果要传输多路视频需要通过SSRC来区分。

在UnifiedPlan中可以有多个媒体描述，如果要传输多路视频可将其拆成多个视频媒体描述（多行m=video......）。

4.5 ORTC

ORTC（Object Real-Time Communication）为开发基于WebRTC的应用程序提供了强大的API，其底层不再使用SDP，同时不再需要Offer/Answer机制，而是将原来SDP中的内容分别放到Sender、Receiver、Transport对象中，通过对象完成之前的工作。

ORTC的推出对WebRTC来说是一场重大变革，很多WebRTC的概念都会消失，比如WebRTC的对象RTCPeerConnection在ORTC中将不再存在。