SDP（Session Description Protocol）模型介绍(RFC3264)(转）

如果有哪里描述有误，或不准确，欢迎各位网友指正，可以及时讨论并修正。

 

情态动词术语解释：

"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

 

出处：http://blog.csdn.net/runningya/article/details/5978360