一、介绍

SDP(Session Description Protocal)以文本描述各端(PC 端、Mac 端、Android 端、iOS 端等)的能力,
这里的能力指的是各端所支持的:

  1. 音频编解码器是什么,这些编解码器设定的参数是什么
  2. 使用的传输协议是什么
  3. 以及包括的音视频媒体是什么等等。

例子:

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,使用单声道。

1 对 1 WebRTC 处理过程图:
在这里插入图片描述
如上图所示,两个客户端 / 浏览器进行 1 对 1 通话时,首先要进行信令交互,而交互的一个重要信息就是
SDP 的交换。
交换 SDP 的目的是为了让对方知道彼此具有哪些能力,然后根据双方各自的能力进行协商,协商出大家认可
音视频编解码器、编解码器相关的参数(如音频通道数,采样率等)、传输协议等信息。
如上图所示,阿花 与 阿强进行通讯,它们先各自在 SDP 中记录自己支持的音频参数、视频参数、传输协议等
信息,然后再将自己的 SDP 信息通过信令服务器发送给对方。当一方收到对端传来的 SDP 信息后,它会将接
收到的 SDP 与自己的 SDP 进行比较,并取出它们之间的交集,这个交集就是它们协商的结果,也就是它们最
终使用的音视频参数及传输协议了。

二、标准 SDP 规范

标准 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
...
v=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>:采样率,如音频的采样率频率 3200048000 等。
<encodingparameters>:编码参数,如音频是否是双声道,默认为单声道。

第四个,fmtp。例子:a=fmtp:<payload type> <format specific parameters>。
fmtp,格式参数,即 format parameters;
<payload type> ,负载类型,同样对应 RTP 包中的音视频数据负载类型;
< format specific parameters>指具体参数。

具体的例子:

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 中的会话元数据(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‐rsiz
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 类似
...
//============= 会话描述 ====================
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

上面的 SDP 片段是摘取的 WebRTC SDP 中的安全描述与服务质量描述,这两块描述在标准 SDP 规范中没有
明确定义,它更多属于 WebRTC 业务的范畴。
其中,安全描述起到两方面的作用,一方面是进行网络连通性检测时,对用户身份进行认证;另一方面是收发
数据时,对用户身份的认证,以免受到对方的攻击。从中可以看出 WebRTC 对安全有多重视了
服务质量描述指明启动哪些功能以保证音视频的质量,如启动带宽评估,当用户发送数据量太大超过评估的带
宽时,要及时减少数据包的发送;启动防拥塞功能,当预测到要发生拥塞时,通过降低流量的方式防止拥塞的
发生等等,这些都属于服务质量描述的范畴。

为便于你更好地理解和使用 SDP,接下来看一个真实的例子。
下面这段 SDP 是我从一个真实的 1 对 1 场景中截取出来的 WebRTC 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 又将其细划为四部分,即媒体流、网络描述、安全描述和服务质量描述。
并且在上面的例子中有两个媒体层——音频媒体层和视频媒体层,而对于每个媒体层,也都有对应的媒体流描
述、网络描述、安全描述及服务质量描述。

Logo

致力于链接即构和开发者,提供实时互动和元宇宙领域的前沿洞察、技术分享和丰富的开发者活动,共建实时互动世界。

更多推荐