一、介绍

SDP（Session Description Protocal）以文本描述各端（PC 端、Mac 端、Android 端、iOS 端等）的能力，
这里的能力指的是各端所支持的：

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

例子：

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>：采样率，如音频的采样率频率 32000、48000 等。
<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 又将其细划为四部分，即媒体流、网络描述、安全描述和服务质量描述。
并且在上面的例子中有两个媒体层——音频媒体层和视频媒体层，而对于每个媒体层，也都有对应的媒体流描
述、网络描述、安全描述及服务质量描述。

SDP协议基本分析（RTSP、WebRTC使用）相关推荐

rtsp协议c语言,RTSP协议
RTSP简介 RTSP(Real Time Streaming Protocol)是由Real Network和Netscape共同提出的如何有效地在IP网络上传输流媒体数据的应用层协议.RTSP对流 ...
RTSP协议实例分析
1. 前言互联网上关于RTSP的文章很多,但是大多数都是抽象的理论介绍,本文将从实际例子解说RTSP协议,不求面面俱到,但求简单易懂.RTSP(Real-Time Streaming Protoco ...
SDP 协议分析 http://www.cnblogs.com/qingquan/archive/2011/08/02/2125585.html
SDP 协议分析一.SDP协议介绍 SDP 完全是一种会话描述格式 ― 它不属于传输协议 ― 它只使用不同的适当的传输协议,包括会话通知协议(SAP).会话初始协议(SIP).实时流协议(RTSP) ...
RTSP协议基本分析
目录一.介绍二.RTSP与HTTP 三.RTSP推流基本过程 1.OPTION 查询服务器端可用方法 1.1.Client 请求 1.2.Server 回复 2.ANNOUNCE 发送媒体描述信息 ...
转--SDP 协议分析
原文地址:http://www.cnblogs.com/qingquan/archive/2011/08/02/2125585.html 一.SDP协议介绍 SDP 完全是一种会话描述格式 ― 它不属 ...
流媒体服务器之rtp协议，rtcp协议，rtsp协议，sdp协议，sip协议简析
0.前言流媒体服务器做音视频媒体传输主要就两件事:媒体回话协商,媒体数据传输:下面这几种协议就围绕着这两个需求而产生. 1.rtp协议 rtp的全称是实时传输协议RTP(Real-time Tran ...
智能终端会议系统（20）---网络视频传输协议--RTP/RTCP/RTSP/SIP/SDP 之间关系
网络视频传输协议--RTP/RTCP/RTSP/SIP/SDP 之间关系 RTP/RTCP/RTSP/SIP/SDP 关系 1. RTP Real-time Transport Protocol,是用 ...
WebRTC源码-信令之六：SDP协议与协商流程
一.SDP协议概述 SDP(Session Description Protocol)是一个用来描述多媒体会话的应用层控制协议, 它是一个基于文本的协议,用于会话建立过程中的媒体类型和编码方案的协商等 ...
rtsp和sdp协议简介
RTSP 是由Real network 和Netscape共同提出的如何有效地在IP网络上传输流媒体数据的应用层协议 . 实时流协议(RTSP)建立并控制一个或几个时间同步的连续流媒体,如音频和视 ...

SDP协议基本分析（RTSP、WebRTC使用）

目录