​问题背景：

无论你是用微信进行视频电话还是开Zoom视频会议，按照OSI网络七层参考模型，我们进行这些活动之前一般都要先建立一组会话。在建立会话的过程中，我们需要描述下会话的一些信息，描述这种会话能力时用到了SDP协议，也就是会话描述协议Session Description Protocol，协议详细内容在RFC4566中规定。

这么说可能不够直白，大白话解释就是：由于Web端、IOS、Android、PC、MAC端的差异性导致它们对音视频的支持能力不同，所以我们进行一些音视频会话之前，需要交互下彼此的音视频编解码能力、网络带宽和传输协议等信息，这些需要协商的信息需要用SDP来描述。

注意的是SDP虽然具备这些能力参数信息的描述功能，但是SDP并不是传输协议，需要用RTSP、SIP、HTTP等协议进行承载传输、交换，如果大家协调好了之后，就可以建立会话，完成真实的音视频码流传输，再完成解码和播放。

这篇文章主要讲下SDP协议格式和规范、具备哪些描述能力、最后再通过在RTSP和基于SIP的国标协议进行实例分析下，当然目前比较火的WebRTC在建立音视频会话前也是通过这套协议描述会话信息的。SDP应用在任何场景和行业标准中，一般都进行了裁剪和进一步的规范，如果你要了解所有的SDP信息，你可以参考RFC4566文档，如果需要了解在WebRTC中使用可以参考链接：https://www.ietf.org/archive/id/draft-nandakumar-rtcweb-sdp-08.txt

SDP格式和规范

SDP场景：

SDP一般用在媒体会话建立之前，可以适用于实时流媒体、点播、直播等领域，特别在音视频通话、视频会议、VoIP、视频监控等领域应用较多。媒体码流一般基于RTP传输，服务质量用RTCP协议保障。

但是SDP的交互不是所有音视频会话建立时都是必须的，假如双方提前约定好这些音视频会话创建需要的信息就不用这个步骤来交互彼此的SDP信息，比如HTTP-FLV、RTMP-FLV直播和点播方案，因为一旦采用了这套方案，这些音视频会话建立需要的信息都是确定的，但是这样会降低或者说没有充分发挥端到端的音视频能力，协商显得更加灵活点。

SDP作用：

SDP作用包括以下一些方面1)建立会话的详细信息，包括名称，网络，带宽等信息3)包含在会话中的媒体信息，包括： 媒体类型(video, audio, etc) 传输协议(RTP/UDP/IP, H.320, etc) 媒体格式(H.261 video, MPEG video, etc) 多播或远端（单播）地址和端口4)为接收媒体而需的信息5)使用的带宽信息6)可信赖的接洽信息

如果拓展，还可以描述会话的安全方案信息、服务质量信息等，其中WebRTC就在SDP的基础上进行了继续拓展，可以参考：

https://www.ietf.org/archive/id/draft-nandakumar-rtcweb-sdp-08.txt。

SDP格式：

标准的SDP规范主要包括SDP描述格式和SDP结构，其中SDP结构里面最重要的两项内容是会话描述信息和媒体描述信息。

说了这么多，先上个SDP的示例，有个SDP的直观认识：

SDP是由多个<type>=<value>这样的表达式组成，其中是基于文本描述，这样做的好处是便于问题排查和调试，同时type是一个字符，value是一个字符串，=两边没有空格。

整个SDP 由这样一行行的key-value字符串组成，同时整个字符串组成了会话信息描述和多个媒体级别描述。至于会话信息和媒体信息描述的key和value到底怎么定义需要继续分析下各个字段，其中有些字段是必须的有些是可选项。

会话描述和媒体描述，一般会话级描述从v=开始一直到第一个媒体描述为止，媒体描述是从m=开始一直到下一个媒体描述m=的位置之前。也就是说SDP里面一般先从会话信息v=开始，然后后面跟几个m=的媒体描述组成。

1. 会话级的作用域是整个会话，其位置从v=开始到第一个媒体描述m=为止；

2. 媒体级描述 是对单个媒体流即音频流、视频流和字幕流等的单个媒体描述，如果有多个流则用多组媒体级描述。其中每个媒体级描述就是从m=开始到下一个媒体描述m=为止。

SDP结构：

上面了解了SDP的基本信息，下面看下各个字段含义，当然字段非常多，只看一些常用和必须的，对于有些场景下的字段你需要参看SDP的RFC4566文档进一步了解，同时了解下各个行业的标准对这一块的规定，后面示例分析会介绍完整的应用字段解释。

会话描述部分：

1. v=

v就是protocol version，必选字段，表示了SDP的版本号但是不包含子版本号，一般就是v=0。2. o=

o是owner，必选字段，对会话发起者的一个信息描述，其中包含了用户名、会话ID、网络地址等信息。格式是：

o=<username> <session id> <version> <network type> <address >

3. s=

s即session name，表示的会话名称，必选字段。在整个SDP里面只有一个会话名称，有且仅有一个这样的字段。

4. t=

t即time the session is active，必选字段，表示的是该会话的开始到结束时间，如果是持久会话，则时间值填0，这样的时间是NTP时间，单位是秒，格式是 ：

t=<start time> <stop time>。

媒体描述部分：

这部分字段非常多，也重点介绍几个，其余字段用到需要参考RFC文档和后面的示例分析：1. m=

m就是media name and transport address，可选字段，但是一般音视频会话至少有音频流或者视频流，所以一般也是都会有的，如果多个流则有多个，一般就是从这个m=到下个媒体会话m=结束，格式：

m=<media type> <port> <transport> <fmt list>

<media tyoe>：媒体类型， audio或者video

<port>：媒体端口，要么是收流端口，要么是发流端口，这样我们就知道从哪个端口进行发流和收流。

<transport>：传输协议，表示码流的传输协议是什么，如果UDP则为RTP/AVP代表码流用RTP Over UDP，要么是TCP/RTP/AVP即RTP Over TCP，表示用TCP传输RTP码流。

<fmt list>:媒体格式，这里表示的负载类型，一般表示的视频的H.264 H.265等,音频则是 G7xx、AAC、Opus等类型。

2. a=

a是attribute，可选字段，表示的媒体的属性，进一步的描述媒体信息，可以有多个属性，其中比较重要的属性就是rtpmap和fmtp，格式是：

a=<type>

a=<type>:<value>

rtpmap属性，表示媒体流传输协议的RTP具体内容：

a=rtpmap:<payload type> <encoding name>/<clock rate>[/encoding parameters]

rtpmap:是rtp map即RTP参数映射表

<payload type>：负载类型，对应表示RTP包中的音视频数据负载类型，比如RTP的数据类型是H.264，那么这里就是96。

<encoding name>:编码器名称，这里主要指的RTP承载音视频编码数据类型，当然可以是标准数据也可以私有数据，如VP8 VP9 H.264等。

<sample rate>:采样率，音视频里面都有时间戳的概念，所以这里表示的音视频的采样率，对音视频同步非常重要。比如视频的90000，音频的8000、48000等。

<encoding parameters>：编码参数，可以表示视频的分辨率，帧率，音频的单声道双声道等信息。

fmtp属性，在rtpmap基础上进一步描述音视频具体编码参数信息：

格式：

a=fmtp:<payload type> <format specific parameters>

fmtp，格式参数，即 format parameters；

<payload type>：负载类型，同样对应 RTP 包中的音视频数据负载类型；

< format specific parameters>：指具体参数，或者说对音视频编码信息的一次处理。该信息从编码器得到，比如视频的SPSPPS等，用于解码端的播放器初始化。

SDP的字段非常多，在不同场景下约束不同，下面看下在RTSP、国标SIP协议、WebRTC中的具体示例。

示例分析：

RTSP中的SDP：

RTSP即Real Transport Stream Protocol实时流媒体传输协议，一般和RTP、RTCP搭配使用，该协议用来进行媒体的控制和会话的建立，比如开始、暂停、倍速控制媒体文件的播放，RTP协议用来进行码流的传输，RTCP保障服务的Qos质量。该协议的应用场景在视频监控最多，一般的视频监控产品如摄像机、NVR等都原生支持RTSP协议，同时该协议在一些智能家居方面如智能音箱也有所使用，比如AWS Alexa在进行视频投屏时就支持该协议。

这里只探讨下RTSP协议的创建媒体会话时，用SDP交互会话信息时的情况，顺便给大家一个测试地址，然后用VLC播放视频抓包就可以学习RTSP、RTP协议，RTSP协议默认端口554，测试地址：

rtsp://http://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mov

这是抓包在DESCRIBE信令的SDP信息：

会话描述协议：

v=0

解释：版本号，一般默认是0；

o=- 1422341101 1422341101 IN IP4 3.84.6.190

解释：会话发起者信息会话名称 网络类型 IP地址等信息；

s=BigBuckBunny_115k.mov

解释：会话名称

c=IN IP4 3.84.6.190

解释：

格式：c=<networktype> <address type> <connection address>

链接信息，包含网络类型和IP地址等信息；

a=range:npt=0- 596.48

解释：用来表示媒体流的长度为596.48秒

音频媒体描述信息：

m=audio 0 RTP/AVP 96

解释：表示该路会话的的audio是通过RTP来格式传送的，其payload值为96但是传送的端口还没有定。

a=rtpmap:96 mpeg4-generic/12000/2

解释：rtpmap的信息，表示音频为AAC的其sample采样率为12000双通道音频，其中mpeg4-generic代表了AAC的互联网媒体类型。

a=fmtp:96 profile-level-id=1;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1490

解释：这里面是AAC的详细编码和封装信息：

profile-level-id=1;mode=AAC-hbr;

profile中指定1表示低复杂度类型，mode=AAC-hbr代表编码模式；

sizelength=13;indexlength=3;indexdeltalength=3

涉及到AAC的AU Header,如果一个RTP包则只包含一个AAC包，则没有这三个字段,有则说明是含有AU Header字段，具体参考RTP对音频AAC的封装。

AU-size由sizeLength决定表示本段音频数据占用的字节数

AU-Index由indexLength决定表示本段的序号, 通常0开始

AU-Index-delta由indexdeltaLength 决定表示本段序号与上一段序号的差值

;config=1490十六进制：1490

二进制：0001 0100 1001 0000

十进制：2、9、2

分别代表aac的profile是2、9代表采样率是12000，通道个数是2立体声，具体参考AAC的ADTS头定义。

a=control:trackID=1

解释：通过媒体流1来发送音频；

视频媒体描述信息：

m=video 0 RTP/AVP 97

解释：表示该路会话的的audio是通过RTP来格式传送的，其payload值为97但是传送的端口还没有定。

a=rtpmap:97 H264/90000

解释：表示该路会话的的Video是通过RTP来格式传送的，其payload值为97,编码器是H264，采样率90000。

a=fmtp:97 packetization-mode=1;profile-level-id=42C01E;sprop-parameter-sets=Z0LAHtkDxWhAAAADAEAAAAwDxYuS,aMuMsg==

解释：这里面包含一些RTP封包模式，视频质量等级，视频的SPS、PPS等信息。

表示该路会话的的audio是通过RTP来格式传送的，其payload值为97。

当 packetization-mode 的值为 1 时RTP打包H.264的NALU单元必须使用非交错(non-interleaved)封包模式.

当 profile-level-id的值为 42C01E 时， 第一个字节0x42表示 H.264 的 profile_idc类型Baseline profile , 第二字节代表profile_iop,各个Bit代表视频序列遵循的条款，第三个字节表示 H.264 的 Profile 级别，0x1E即30代表了levle_idc为3，即30/3，具体信息参考H.264的SPS PPS即可。

sprop-parameter-sets是SPS和PPS的的Base64之后的字符串，中间以逗号分割，后面会专门写篇文章介绍下，主要描述了编码器的参数信息，对初始化播放器有帮助；

a=cliprect:0,0,160,240

解释：一些offer和answer的加密属性；

a=framesize:97 240-160

解释：RTP负载类型97，帧宽和高分别为240*160

a=framerate:24.0

解释：最大帧率速度为24帧/s

a=control:trackID=2

解释：通过媒体流1来发送视频；

---

基于SIP协议国标GB28181中的SDP：

国标协议也是基于SIP协议开发的，所以这里的SDP协议是在给前端设备下发INVITE信令的回复中带上来的，这里的SDP主要是为了不同的厂家，使用 GB 对接的时候，上级要能正常看下级推送过来的摄像头的视频，回放，以及球机控制等等的功能。

现在看一个抓包文件中INVITE回复携带的SDP描述信息：

会话信息描述国标的规定：

1. v=0

v字段给出了 SDP 的版本，当前规范版本是 0，这个版本没有小号版本。

2. o=

源（客户端的SIP编号）<用户名><会话 ID><会话版本><网络类型><地址类型><单播地址>

如 32028100001320000001 0 0 IN IPV4 192.168.0.101

各个字段解释：

<用户名> 用户登录的源主机名字，如果不能提供则用"-"表示，用户名不能包含空格。这

里一般是摄像机的国标 ID

<会话 ID> 是一个字符串，<用户名><会话 ID><网络类型><单播地址>这个组合形成该会话

的唯一标识。用 0 标识的居多

<会话版本> 会话版本号，推荐使用 NTP 时间戳。用 0 标识的居多

<网络类型> 目前是 IN 代表 internet，未来可能会有其他值。

<地址类型> 目前只有 IPV4 和 IPV6 两种，目前主要是 IPV4,。

<单播地址> 创建会话的主机地址。一般为媒体服务器的地址。

注意：有时候处于某种原因，用户名和 IP 不想明确表示，只要保证 o 字段全球唯一，用户名和 IP 可以随机。

3. s=

请求媒体流的操作类型，play 代表实况；playback 代表回放。download 代表下载，Talk

代表语音。

4. u=

行应填写视音频文件的 URI。 该 URI 取值有两种方式: 简捷方式和普通方式。

简捷方式常用 摄像机 ID：其他参数格式。如 32028100001320000001:10111

普通方式采用 http://存储设备 ID[/文件夹]* /文件名, [/文件夹]* 为 0-N 级文件夹。

简捷方式中冒号后面文件类型，如果s=playback时，则0有时代表的全天录像，1代表事件录像等，一般默认为3.有些海康平台这里进行了区分，如果值填错会导致回放录像失败。

5. c=

<网络类型><地址裂类型><链接地址>

如 IN IPV4 192.168.0.100

6.t=

t字段在回放和下载时，t 行值为开始时间和结束时间。使用的时间为 UNIX 时间戳，需要

用 UNIX 时间戳转为北京时间。如果是直播则是0.

媒体信息描述国标的规定：

1. m=

m 字段描述媒体类型，媒体端口，媒体协议，以及媒体负载方式

例：

m=video 6000 RTP/AVP 96------媒体类型视频或视音频，传输端口 6000，RTP over UDP，负载

类型 96

m=video 6000 TCP/RTP/AVP 96------媒体类型视频或视音频，传输端口 6000，RTP over TCP，负

载类型 96

m=audio 6000 RTP/AVP 8------媒体类型为音频，传输端口 6000，RTP over UDP，负载类型 8

2. a=

a=rtpmap: <payload type> <encoding name>/<clockrate> [/<encoding parameters> ] 中的<encoding name>这里参考RTSP分析即可，要说的一点是这里可以携带设备厂商的编码类型，如果发现这里不是标准的，则解码和播放一般都存在问题；

a=downloadspeed: 下载倍速(取值为整型) ；

a=filesize: 文件大小(单位:Byte) , a 字段可携带文件大小参数, 用于下载时的进度计算。

下面可以参考IETF RFC4571的规定，解析setup connection recvonly等属性：

a=setup:TCP 连接方式(表示本 SDP 发送者在 RTP over TCP 连接建立时是主动还是被动发

起 TCP 连接, “active”为主动, “passive”为被动)

a=connection:new (表示采用 RTP over TCP 传输时新建或重用原来的 TCP 连接, 可固定采

用新建 TCP 连接的方式)

a=recvonly 只接受（收流端）只用于媒体，不用于控制协议

a=sendonly 只发送（发流端）只用于媒体，不用于控制协议

y 字段：由 10 位十进制整数组成的字符串，表示 SSRC 值

第一位为 0 代表实况，为 1 则代表回放， 第二位至第六位由监控域 ID 的第 4 位到第 8 位组成,最后 4 位为不重复的 4 个整数 ；

有了以上基础分析国标SIP中的SDP信息就非常简单了，不再赘述。

---

WebRTC中的SDP：

WebRTC中的SDP信息比较关键，是分析代码流程和驱动整个业务运转起来的关键，同时WebRTC规范也对SDP的RFC4566规范进行了进一步的规范，也已经成为SDP草案，具体参考：https://www.ietf.org/archive/id/draft-nandakumar-rtcweb-sdp-08.txt

其中SDP包含了下面几个板块的内容，比RTSP和SIP中的更丰富更强大：

其中会话描述、网络描述、媒体流描述和SDP的RFC4566规范是一致的，同时增加了安全描述和服务质量QOS描述，我们进行了P2P抓包：

WebRTC中的SDP 是由一个会话层和多个媒体层组成的， 而对于每个媒体层，WebRTC 又将其细划为四部分，即媒体流、网络描述、安全描述和服务质量描述。

其中，安全描述起到两方面的作用，一方面是进行网络连通性检测时，对用户身份进行认证；另一方面是收发数据时，对用户身份的认证，以免受到对方的攻击；

服务质量描述指明启动哪些功能以保证音视频的质量，如启动带宽评估，当用户发送数据量太大超过评估的带宽时，要及时减少数据包的发送；启动防拥塞功能，当预测到要发生拥塞时，通过降低流量的方式防止拥塞的发生等等，这些都属于服务质量描述的范畴。

总结起来就是，SDP 是由一个会话层与多个媒体层组成，每个媒体层又分为媒体流描述、网络描述、安全描述和服务质量描述，而每种描述下面又需要你参考草案来解析和理解。

总结：

这篇文章主要介绍了下SDP协议的内容、格式和规范，以及通过RTSP、SIP、WebRTC中三个例子分析了下SDP中各个字段和应用。平时学习时有这个整体框架就行，一些文中没出现的字段需要你查标准的RFC文档进行学习和理解。

同时在GB28181协议中，由于各个厂家对有些字段理解不规范，导致有歧义经常会出现连接摄像头失败，拉流失败等问题，需要在实践中解决和兼容。

---

往期文章回顾:

周末活动回顾：视频质量主观评价、实时RTC和AV1

视频监控摄像头的互联网化实践思路

在HTML5上开发音视频应用的五种思路

音视频封装：MP4结构概述和分析工具

音视频解封装：MP4核心Box详解及H264&AAC打包方案

音视频基础知识-时间戳的理解

音视频封装格式：AAC音频基础和ADTS打包方案详解

从人类的第一次直播聊聊视频监控行业

音视频压缩：H264码流层次结构和NALU详解

音视频传输：RTP协议详解和H.264打包方案

音视频封装：FLV格式详解和打包H264、AAC方案（下）

音视频封装：FLV格式详解和打包H264、AAC方案（上）

音视频常见问题分析和解决：延时和抖动

---

今天就说这么多，祝您工作顺利！

如果有疑问，你可以在公众号后台发消息咨询我。

---

个人转载内容至朋友圈和群聊天，无需特别申请版权许可。

引用转载该订阅号文章，注明文章来源即可。

记得右下角点“在看”，还可以关注该订阅号，防止遗漏推送哦