SDP模型介绍

情态动词术语解释

MUST必须、一定要;
MUST NOT禁止;
REQUIRED需要;
SHALLSHOULD应该;
SHALL NOTSHOULD 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协议,大部分为直译,附加自己经验和理解。

SDP模型介绍_第1张图片
SDP模型组网图

Offer/Answer模型包括两个实体,一个是 请求主体 Offerer,另外一个是 响应实体 Answerer,两个实体只是在逻辑上进行区分,在一定条件可以转换。例如,手机A发起媒体协商请求,那么A就是Offerer,反之如果A为接收请求则为Offerer。
Offerer发给 Answerer的请求消息称为 请求offer,内容包括媒体流类型、各个媒体流使用的编码集,以及将要用于接收媒体流的IP和端口。
Answerer收到offer之后,回复给 Offerer的消息称为 响应,内容包括要使用的媒体编码,是否接收该媒体流以及告诉 Offerer其用于接收媒体流的IP和端口。

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

实体行为、操作过程

初始协商的Offer请求

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

  • 如果媒体流方向标为recvonly/sendrecv,即a=recvonly或a=sendrecv,则A必须(MUST)准备好在这个IP和端口上接收实体B发来的媒体流;
  • 如果媒体流方向标为sendonly/inactive,即a=recvonly或a=sendrecv,则A不需要进行准备。
Answer响应

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

  • 如果实体B回复的响应中的媒体流数量和顺序必须(MUST)和请求offer一致,以便实体A进行甄别和决策。即m行的数量和顺序必须一致,B不能(MUST NOT)擅自增加或删除媒体流。如果B不支持某个媒体流,可以在对应的端口置0,但不能不带这个m行描述。
  • 对于某种媒体,实体B必须(MUST)从请求offer中选出A支持且自己也支持的该媒体的编码标识集,并且可以(MAY)附带自己支持的其它类型编码。
  • 对于响应消息中各个媒体的方向:
    如果请求某媒体流的方向为sendonly,那么响应中对应媒体的方向必须为recvonly
    如果请求某媒体流的方向为recvonly,那么响应中对应媒体的方向必须为sendonly
    如果请求某媒体流的方向为sendrecv,那么响应中对应媒体的方向可以为sendrecv/sendonly/recvonly/inactive中的一种;
    如果请求某媒体流的方向为inactive,那么响应中对应媒体的方向必须为inactive
  • 响应answer里提供IP和端口,指示Offerer本端期望用于接收媒体流的IP和端口,一旦响应发出之后,Offerer必须(MUST)准备好在这个IP和端口上接收实体A发来的媒体流。
  • 如果请求offer中带了ptime(媒体流打包间隔)的a行或带宽的a行,则响应answer也应该(SHOULD)相应的携带。
  • 实体B Offerer应该(SHOULD)使用实体A比较期望的编码生成媒体流发送。一般来说对于m行,如m=video 0 RTP/AVP 31 34,排充越靠前的编码表示该实体越希望以这个编码作为载体,这里示例31(H261),34(H263)中H261为A更期望使用的编码类型。同理,当实体A收到响应answer后也是这样理解的。
实体收到响应后的处理

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

  • 必须(MUST)使用answer列举的媒体类型/编码生成媒体发送;
  • 应该(SHOULD)使用answer中的ptime和bandwidth来打包发送媒体流;
  • 可以(MAY)立即停止监听端口,该端口为offer支持answer不支持的媒体所使用的端口。

修改媒体流(会话)

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

删除媒体流

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

增加媒体流

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

修改媒体流

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

你可能感兴趣的:(SDP模型介绍)