SDP协议介绍

一、SDP协议介绍
SDP 完全是一种会话描述格式 ― 它不属于传输协议 ― 它只使用不同的适当的传输协议，包括会话通知协议（SAP）、会话初始协议（SIP）、实时流协议（RTSP）、MIME 扩展协议的电子邮件以及超文本传输协议（HTTP）。SDP协议是也是基于文本的协议，这样就能保证协议的可扩展性比较强，这样就使其具有广泛的应用范围。SDP 不支持会话内容或媒体编码的协商，所以在流媒体中只用来描述媒体信息。媒体协商这一块要用RTSP来实现．

二、SDP协议格式
SDP描述由许多文本行组成，文本行的格式为<类型>=<值>，<类型>是一个字母，<值>是结构化的文本串，其格式依<类型>而定。

＜type＞=[CRLF]

常见的fields有：

三、SDP协议例子：
下面是一个helix 流媒体服务器的RTSP协议中的SDP协议：

v=0 //SDP version

// o field定义的源的一些信息。其格式为：o=

o=- 1271659412 1271659412 IN IP4 10.56.136.37 s=

i= //session的信息

c=IN IP4 0.0.0.0 //connect 的信息，分别描述了：网络协议，地址的类型，连接地址。

c=IN IP4 0.0.0.0

t=0 0 //时间信息，分别表示开始的时间和结束的时间，一般在流媒体的直播的时移中见的比较多。

a=SdpplinVersion:1610641560 //描述性的信息

a=StreamCount:integer;2 //用来描述媒体流的信息，表示有两个媒体流。integer表示信息的格式为整数。

a=control:*

a=DefaultLicenseValue:integer;0 //License信息

a=FileType:string;”MPEG4” 用来描述媒体流的信息说明当前协商的文件是mpeg4格式的文件

a=LicenseKey:string;”license.Summary.Datatypes.RealMPEG4.Enabled”

a=range:npt=0-72.080000 //用来表示媒体流的长度

m=audio 0 RTP/AVP 96 //做为媒体描述信息的重要组成部分描述了媒体信息的详细内容：表示session的audio是通过RTP来格式传送的，其payload值为96传送的端口还没有定。

b=as:24 //audio 的bitrate

b=RR:1800

b=RS:600

a=control:streamid=1 //通过媒体流1来发送音频

a=range:npt=0-72.080000 //说明媒体流的长度。

a=length:npt=72.080000

a=rtpmap:96 MPEG4-GENERIC/32000/2 //rtpmap的信息，表示音频为AAC的其sample为32000

a=fmtp:96 profile-level-id=15;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1210 //config为AAC的详细格式信息

a=mimetype:string;”audio/MPEG4-GENERIC”

a=Helix-Adaptation-Support:1

a=AvgBitRate:integer;48000

a=HasOutOfOrderTS:integer;1

a=MaxBitRate:integer;48000

a=Preroll:integer;1000

a=OpaqueData:buffer;”A4CAgCIAAAAEgICAFEAVABgAAAC7gAAAu4AFgICAAhKIBoCAgAEC”

a=StreamName:string;”Audio Track”

下面是video的信息基本和audio的信息相对称，这里就不再说了。

m=video 0 RTP/AVP 97

b=as:150

b=RR:11250

b=RS:3750

a=control:streamid=2

a=range:npt=0-72.080000

a=length:npt=72.080000

a=rtpmap:97 MP4V-ES/2500

a=fmtp:97 profile-level-id=1;

a=mimetype:string;”video/MP4V-ES”

a=Helix-Adaptation-Support:1

a=AvgBitRate:integer;300000

a=HasOutOfOrderTS:integer;1

a=Height:integer;240 //影片的长度

a=MaxBitRate:integer;300000

a=MaxPacketSize:integer;1400

a=Preroll:integer;1000

a=Width:integer;320 //影片的宽度

a=OpaqueData:buffer;”AzcAAB8ELyARAbd0AAST4AAEk+AFIAAAAbDzAAABtQ7gQMDPAAABAAAAASAAhED6KFAg8KIfBgEC”

a=StreamName:string;”Video Track”

SDP协议学习笔记

在SIP协议的包含的内容是SDP时，应该把Content-Type设置成application/sdp。

SDP:Session Description Protocol

SDP格式:
Session description
v= (protocol version)
o= (owner/creator and session identifier)
s= (session name)
i=* (session information)
u=* (URI of description)
e=* (email address)
p=* (phone number)
c=* (connection information - not required if included in all media)
b=* (zero or more bandwidth information lines)
One or more time descriptions (“t=” and “r=” lines, see below)
z=* (time zone adjustments)
k=* (encryption key)
a=* (zero or more session attribute lines)
Zero or more media descriptions

  Time description
     t=  (time the session is active)
     r=* (zero or more repeat times)

  Media description, if present
     m=  (media name and transport address)
     i=* (media title)
     c=* (connection information - optional if included at
          session-level)
     b=* (zero or more bandwidth information lines)
     k=* (encryption key)
     a=* (zero or more media attribute lines)

以上带”*”号的是可选的,其余的是必须的。一般顺序也按照上面的顺序来排列。

a=*是sdp协议扩展属性定义，除上面以外的，分解时其它的都可以扔掉。
a=charset属性指定协议使用的字符集。一般的是ISO-10646。

示例：
v=
其中：nettype是IN,代表internet,addrtype是IP4或IP6。unicast-address任务创建计算机的地址。
整个这个属性，是唯一表示一个任务。

e=123@126.com 或 p=+1 616 555-6011
对于一个任务只能两者之中的一个，表示会议控制者的联系方式。邮件地址可以是[email]j.doe@example.com[/email] (Jane Doe)形式，括号里面的是描述联系人的名称，或者Jane Doe <[email]j.doe@example.com[/email]>，前面的是联系人的名称。

c=
这个连接数据，可以是传话级别的连接数据，或者是单独一个媒体数据的连接数据。在是多播时，connection-address就该是一个多播组地址，当是单播时，connection-address就该是一个单播地址。对于addrtype是IP4的情况下，connection-address不仅包含IP地址，并且还要包含a time to live value(TTL 0-255)，如：c=IN IP4 224.2.36.42/128，IP6没有这个TTL值。还允许象这样的[/]/格式的connection-address。如：c=IN IP4 224.2.1.1/127/3等同于包含c=IN IP4 224.2.1.1/127, c=IN IP4 224.2.1.2/127, c=IN IP4 224.2.1.3/127三行内容。

b=: bwtype可以是CT或AS，CT方式是设置整个会议的带宽，AS是设置单个会话的带宽。缺省带宽是千比特每秒。
t= ，这个可以有行，指定多个不规则时间段，如果是规则的时间段，则r=属性可以使用。start-time和stop- time都遵从NTP(Network Time Protocol),是以秒为单位，自从1900以来的时间。要转换为UNIX时间，减去2208988800。如果stop-time设置为0,则会话没有时间限制。如果start-time也设置为0，则会话被认为是永久的。

r= 重复次数在时间表示里面可以如下表示：
d - days (86400 seconds)
h - hours (3600 seconds)
m - minutes (60 seconds)
s - seconds (allowed for completeness)
z= ….
k=
k=:
a=
a=:
m= …
m= / …
其中：可以是，”audio”,”video”, “text”, “application” and “message”。是媒体传送的端口号，它依赖于c=和。 可以是，udp，RTP/AVP和RTP/SAVP。

a=cat:分类，根据分类接收者隔离相应的会话
a=keywds:关键字，根据关键字隔离相应的会话
a=tool:创建任务描述的工具的名称及版本号
a=ptime:在一个包里面的以毫秒为单位的媒体长度
a=maxptime:以毫秒为单位，能够压缩进一个包的媒体量。
a=rtpmap: / [/]
a=recvonly
a=sendrecv
a=sendonly
a=inactive，
a=orient:其可能的值，”portrait”, “landscape” and “seascape” 。
a=type:,建议值是，”broadcast”, “meeting”, “moderated”, “test” and “H332”。
a=charset:
a=sdplang:指定会话或者是媒体级别使用的语言
a=framerate:设置最大视频帧速率
a=quality:值是0-10
a=fmtp:

在SIP协议的包含的内容是SDP时，应该把Content-Type设置成application/sdp。

SDP（Session Description Protocol）模型介绍
如果有哪里描述有误，或不准确，欢迎各位网友指正，可以及时讨论并修正。

情态动词术语解释：

“MUST”，必须、一定要；

“MUST NOT”，禁止；

“REQUIRED”，需要；

“SHALL”、”SHOULD”，应该；

“SHALL NOT”、”SHOULD NOT”，不应该；

“RECOMMENDED”，推荐；

“MAY”，可以

以上情态动词术语可参考RFC2119[3]，这些动词要求我们在产品实现时，需要遵守或灵活变更约束。

术语

媒体流（Media Stream），或称为媒体类型（Media Type），即我们通常所说的音频流、视频流等，所有通信实体要进行媒体交互之前都必须进行媒体注的协商

媒体格式（Media Format），每种媒体流都有不同的编码格式，像音频有G711、G712编码，视频有H261、H264等，像现在所谓的高清视频采用是720P、1070P等。

单一会话（Unitcast Session）

多会话（Multicast Sessions）

单一媒体流（Unitcast Streams）

多媒体流（Multicast Streams）

SDP（Session Description Protocol）

SDP（会话描述协议），用于两个会话实体之间的媒体协商，并达成一致，属信令语言族，采用文本（字符）描述形式。rfc3264协议[1]主要概述一个请求/响应模型（offer/answer，以下叙述采用英文），包括请求/响应的实体和不同阶段的操作行为，如初始协商过程和重协商过程，并简单介绍消息中各种参数的含义。具体各个参数的详细说明见rfc2327协议[2]。本文主要参照3264协议，大部分为直译，附加自己经验和理解。

图1 SDP模型组网图

1实体、消息
Offer/Answer模型包括两个实体，一个是请求主体Offerer，另外一个是响应实体Answerer，两个实体只是在逻辑上进行区分，在一定条件可以转换。例如，手机A发起媒体协商请求，那么A就是Offerer，反之如果A为接收请求则为Offerer。

Offerer发给Answerer的请求消息称为请求offer，内容包括媒体流类型、各个媒体流使用的编码集，以及将要用于接收媒体流的IP和端口。

Answerer收到offer之后，回复给Offerer的消息称为响应，内容包括要使用的媒体编码，是否接收该媒体流以及告诉Offerer其用于接收媒体流的IP和端口。

2 SDP各个参数简单介绍
下面示例摘自3264协议[1]

v=0

o=carol 28908764872 28908764872 IN IP4 100.3.6.6 //会话ID号和版本

s=- //用于传递会话主题

t=0 0 //会话时间，一般由其它信令消息控制，因此填0

c=IN IP4 192.0.2.4 //描述本端将用于传输媒体流的IP

m=audio 0 RTP/AVP 0 1 3 //媒体类型 端口号 本端媒体使用的编码标识（Payload）集

a=rtpmap:0 PCMU/8000 //rtpmap映射表，各种编码详细描述参数，包括使用带宽（bandwidth）

a=rtpmap:1 1016/8000

a=rtpmap:3 GSM/8000

a=sendonly //说明本端媒体流的方向，取值包括sendonly/recvonly/sendrecv/inactive

a=ptime:20 //说明媒体流打包时长

m=video 0 RTP/AVP 31 34

a=rtpmap:31 H261/90000

a=rtpmap:34 H263/90000

3 实体行为、操作过程
3.1 初始协商的Offer请求

实体A <-> 实体B，实体首先发起Offer请求，内容如2节所示，对于作何一个媒体流/媒体通道，这时实体A必须：

a. 如果媒体流方向标为recvonly/sendrecv，即a=recvonly或a=sendrecv，则A必须（MUST）准备好在这个IP和端口上接收实体B发来的媒体流；

b. 如果媒体流方向标为sendonly/inactive，即a=recvonly或a=sendrecv，则A不需要进行准备。

3.2 Answer响应

实体B收到A的请求offer后，根据自身支持的媒体类型和编码策略，回复响应。

a. 如果实体B回复的响应中的媒体流数量和顺序必须（MUST）和请求offer一致，以便实体A进行甄别和决策。即m行的数量和顺序必须一致，B不能（MUST NOT）擅自增加或删除媒体流。如果B不支持某个媒体流，可以在对应的端口置0，但不能不带这个m行描述。

b. 对于某种媒体，实体B必须（MUST）从请求offer中选出A支持且自己也支持的该媒体的编码标识集，并且可以（MAY）附带自己支持的其它类型编码。

c. 对于响应消息中各个媒体的方向：

如果请求某媒体流的方向为sendonly，那么响应中对应媒体的方向必须为recvonly；

如果请求某媒体流的方向为recvonly，那么响应中对应媒体的方向必须为sendonly；

如果请求某媒体流的方向为sendrecv，那么响应中对应媒体的方向可以为sendrecv/sendonly/recvonly/inactive中的一种；

如果请求某媒体流的方向为inactive，那么响应中对应媒体的方向必须为inactive；

d. 响应answer里提供IP和端口，指示Offerer本端期望用于接收媒体流的IP和端口，一旦响应发出之后，Offerer必须（MUST）准备好在这个IP和端口上接收实体A发来的媒体流。

e. 如果请求offer中带了ptime（媒体流打包间隔）的a行或带宽的a行，则响应answer也应该（SHOULD）相应的携带。

f. 实体B Offerer应该（SHOULD）使用实体A比较期望的编码生成媒体流发送。一般来说对于m行，如m=video 0 RTP/AVP 31 34，排充越靠前的编码表示该实体越希望以这个编码作为载体，这里示例31(H261)，34（H263）中H261为A更期望使用的编码类型。同理，当实体A收到响应answer后也是这样理解的。

3.3 实体收到响应后的处理

当实体A收到B回复的响应后，可以（MAY）开始发送媒体流，如果媒体流方向为sendonly/sendrecv，

a. 必须（MUST）使用answer列举的媒体类型/编码生成媒体发送；

b. 应该（SHOULD）使用answer中的ptime和bandwidth来打包发送媒体流；

c. 可以（MAY）立即停止监听端口，该端口为offer支持answer不支持的媒体所使用的端口。

4 修改媒体流（会话）
修改媒体流的offer-answer操作必须基于之前协商的媒体形式（音频、视频等），不能（MUST NOT）对已有媒体流进行删减。

4.1 删除媒体流

如果实体认定新的会话不支持之前媒商的某个媒体，新的offer只须对这种媒体所在m行的端口置0，但不能不描述这种媒体，即不带对应m行。当answerer收到响应之后，处理同初始协商一样。

4.2 增加媒体流

如果实体打算新增媒体流，在offer里只须加上描述即可或者占用之前端口被置0的媒体流，即用新的媒体描述m行替换旧的。当answerer收到offer请求后，发现有新增媒体描述，或者过于端口被置0的媒体行被新的媒体描述替换，即知道当前为新增媒体流，处理同初始协商。

4.3 修改媒体流

修改媒体注主要是针对初始协商结果，如果有变更即进入修改流程处理，可能的变更包括IP地址、端口，媒体格式（编码），媒体类型（音、视频），媒体属性（ptime，bandwidth，媒体流方向变更等）。

参考文档
[1] RFC3264，An Offer/Answer Model with the Session Description Protocol (SDP)

[2] RFC2327，SDP: Session Description Protocol

[3] RFC2119，Key words for use in RFCs to Indicate Requirement Levels

SDP: Session Description Protocol(会话描述协议)
(RFC2327)
1. 概述
SDP也是MMUSIC工作组的一个产品,在MBONE内容中用得很多。其目的就是在媒体会话中，传递媒体流信息，允许会话描述的接收者去参与会话。 SDP基本上在internet上工作。他定义了绘画描述的统一格式,但并不定义多播地址的分配和SDP消息的传输,也不支持媒体编码方案的协商,这些功能均由下层传送协议完成.典型的会话传送协议包括:SAP(Session Announcement Protocol 会话公告协议),SIP,RTSP,HTTP,和使用MIME的E-Mail.(注意:对SAP只能包含一个会话描述,其它会话传诵协议的SDP可包含多个绘画描述)
SDP包括以下一些方面：
1） 会话的名称和目的
2） 会话存活时间
3） 包含在会话中的媒体信息，包括：
媒体类型(video, audio, etc)
传输协议(RTP/UDP/IP, H.320, etc)
媒体格式(H.261 video, MPEG video, etc)
多播或远端（单播）地址和端口
4） 为接收媒体而需的信息(addresses, ports, formats and so on)
5） 使用的带宽信息
6） 可信赖的接洽信息（Contact information）

1. 协议
   Session description //格式及举例
   v= (protocol version) //v=0
   o= (owner/creator and session identifier). //o=<用户名><会话id><版本><网络类
   //型><地址类型><地址>
   //o=sname 1234567890 0987654321 IN
   //IP4 126.15.64.3
   s= (session name) //会话名
   i=* (session information) //会话信息
   u=* (URI of description) //u=http://www.zte.com.cn/staff/sdp.ps
   e=* (email address) //e=zte@isi.edu(general text如：王生)
   //或e=Mr. Wang<[email]wang@zte.com[/email]>
   p=* (phone number) //p=+86-0755-26773000-7110(wang)
   //or p=+1 617 253 6011
   c=* (connection information -如已经包含在所有媒体中则该行不需要)
   //c=<网络类型><地址信息><连接地址>
   //多点会议包括TTL
   //连接地址: