深圳市宝安区华美居

0086-18665301040

完整SIP/SDP媒体协商概论-SDP基础-会话描述说明

完整SIP/SDP媒体协商概论-SDP基础-会话描述说明

在上一章节 SDP基础-使用和要求的章节中,笔者讨论了关于SDP的使用场景和一些SDP语法构建。这里,我们根据SDP的规范说明,重点介绍SDP具体的会话描述和媒体描述参数。


5

SDP规范标准

总体来说,SDP会话描述的语法由五个核心部分构成,它们分别是:会话元数据,流媒体,服务保障,网络和安全。

完整SIP/SDP媒体协商概论-SDP基础-会话描述说明


Session metadata(会话元数据)描述了会话本身所需要的数据标识,包括SDP协议版本,会话发起方描述,会话身份确认描述和会话活动时间。


Stream description包含了媒体功能的描述细节和参数。


QoS描述包含了所有媒体流性能参数,它可能通过其他信息的调用对多媒体流打包支持带宽和其他资源的优化。


Network description可能包括各种传输协议(TCP,UDP等)和网络协议以便支持多媒体会议参与方之间的媒体收发。


Security 描述包括了密钥,签权,认证,不可否认性,完整性内容。


一个SDP会话描述通过媒体类型标识为:”application/sdp”。SDP会话描述完全是一种文本格式,其格式遵从UTF-8解码规范。其基本的语法规范是:

<type>=<value>
这里,type必须是一个大小写敏感的字符,value是一种具有一定结构的文本,value的格式完全取决于type的取值。通常情况下,value可以是多个值域或者一个自由文本格式。如果value包含多个值域的话,通过单空格隔离。注意,“=”两边决定不能使用空格。


SDP会话描述由会话级描述紧接着零或多个媒体级的描述构成。其中,会话级描述以”v=”行开始,一直继续到第一个媒体级的”m=”行之前结束。媒体级会话描述以“m=”行开始,然后继续到下一个媒体级或整个会话描述结束。通常来说,除非媒体级的值覆盖默认设置,一般来说,对所有媒体来说,会话级的设置是默认的。会话描述行分为必要设置和可选设置两个部分,其会话描述文本格式必须按照固定顺序呈现,这样可以方便处理,避免语法错误。其中,可选会话描述设置带一个”*”字符作为标识。
v=(protocol version) // "v" 开始o=(originator 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, 这里可能无媒体会话


媒体描述示例:

m=(media name and transport address) // "m" 开始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)


接下来,笔者重点介绍几个常用的会话描述设置,主要包括会话级参数,时间和媒体级参数设置。其他的会话描述在后续具体章节中再做阐述。


Protocol Version (“v=”),其语法格式为:

v=0

“v”定义了SDP版本。此规范定义的是0,没有子版本。


Origin (“o=”),其语法格式为:

o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>

“o=” 定义了会话发起方名称,sess-id 是一个数值字符串,通过用户名称,sess-id,nettype,addrtype,和unicast-address构成了一个全局唯一认证ID,<sess-version>是此会话描述的版本号,<nettype>是一个文本字符串,表示网络类型,初始设置是”IN”表示Internet。<addrtype>是一个文本字符串地址,表示是IP4或IP6,也可能使用其他的值。<unicast-address>,此地址是一个创建此会话的机器地址。


Session Name (“s=”), 其语法格式为:

s=<session name>

“s=”定义了文本会话名称,这里必须是仅一个会话名称,此名称不能为空,其字符串应该包含ISO 10646字符。


Session Information (“i=”), 其语法格式为:

i=<session description>
“i=” 提供了关于此会话的文本信息,每个会话描述必须有一个”i=”,一个媒体至少有一个”i=”。如果出现了”a=charset”属性的话,它会设定“i=”的字符设置。如果没有出现“a=charset”的话,“i=”必须包含用UTF-8解码的ISO 1646字符。单个“i=”也可以使用在每个媒体定义中。在媒体定义中,“i=”的主要目的是为了标注媒体流。因此,这种标注方式对单会话环境中有同一媒体类型,它需要支持完全不同的媒体流时非常有用。例如,两个不同的白板功能,一个白板是支持自己的幻灯片播放,另外一个白板支持问题答疑和回复处理。


URI (“u=”),其语法格式为:

u=<uri>
URL是WWW用户使用的处理方式,URL应该指向一个针对此会话的其他另外资源地址。此描述是可选描述。但是,如果它出现的话,它必须出现在第一个媒体前面。在每个会话描述中不允许第二个URL出现


Email Address 和 Phone Number (“e=” 和 “p=”),其语法格式为:

e=<email-address>p=<phone-number>
“e=” 和 “p=”定义了负责会议的联系人信息。是否包含”e=” 和 “p=”是可选的。这两个会话描述使用不是非常广泛。但是,如果出现了邮箱和电话号码的话,它们必须出现在第一个媒体域前面。一个会话可以支持一个或者多个邮箱或者电话号码。电话号码的格式必须按照ITU-T推荐格式来定义,号码前加一个”+“前缀,并且使用”-“分离电话号码,方便用户阅读。例如:
p=+1 617 555-6011

如果是电子邮件的话,两种格式都可以支持:

e=j.doe@example.com (Jane Doe)或者e=Jane Doe <j.doe@example.com>


Connection Data (“c=”), 其语法格式为:

c=<nettype> <addrtype> <connection-address>
它包含一些连接数据。在会话描述中,媒体描述必须至少包含一个“c=”行,或者在会话级包含一个单个”c=”行。在某些应用场景中,预设的媒体设置可以覆盖默认的设置会话级的参数。因此,在每个媒体会话中,c=”可以包含一个单个的会话级的c=”和其他另外的子c=”行。这里的<nettype>和<addrtype>值和前面介绍的一样,读者参考前面的介绍。<connection-address>是一个连接地址,在连接地址后可以增加另外的子项,这些子项取决于<addrtype>类型(是IP4还是IP6地址)。如果会话在多播方式做工作,连接地址必须是一个多播地址组,如果会话在单播方式工作,则广播地址是单播地址。如果会话使用的是一个多播IP4类型的话,多播连接地址必须支持存活时间(TTL),TTL取值范围在0-255之间(例如:c=IN IP4 224.2.36.42/127,TTL是127)。注意,IP6没有使用TTL,因此也没有TTL设置,TTL肯定不会出现在IP4中。IP6使用的是一种继承或层级方式来实现连接地址的处理(例如:c=IN IP6 FF15::101, 无TTL)。


Bandwidth (“b=”),其语法格式为:

b=<bwtype>:<bandwidth>  // kilobits per second
它是一个可选会话描述,表示对会话或者媒体建议使用的带宽。带宽类型子项是以字母方式表示(我们这里讨论的是支持两种类型:CT和AS,还有可能出现TIAS),针对后面的带宽数值描述。CT和AS在创建使用上有明显的不同。CT(Conference Total)表示多会话广播中会话或者媒体使用的最大带宽建议值,CT值相当于所有会话带宽值。AS(Application-Specific)是指具体某个应用程序所占用的总带宽建议值,相当于最大应用程序带宽值,它仅值单媒体在单点所占用的带宽。如果读者对AS有兴趣的话,可以阅读RFC3550-6,RFC3556-2中的RS/PR收发带宽修改机制和RFC3890关于Bandwidth Modifier的规范说明。

Timing (“t=”),其语法格式为:

t=<start-time> <stop-time>
它设置了启动和停止会话的时间。如果在非正常周期时间段启动会话,此会话需要增加多“t=”行。每个“t=”支持另外一个时间段表示会话在此时间段是活动状态。如果会话使用在正常时间周期,“t=”后面加了一个”r=”行表示重复次数。这两个时间标识使用的是NTP的十进制的方式表示,以秒为单位。此时间规范在RFC1305中有非常明确的发明,此时间不是UNIX定义的时间,用户可以参考转换方式来进一步了解如何转换。 如果<stop-time>设置为0,则表示会话不受限,除非<start-time>后,此会话才会被启动。如果<start-time>设置为0,则表示此会话是一个永久会话。通常情况下,规范不建议在用户接口或者其他应用控制界面设置这两个时间取值,这样会导致会话时间错乱,会话控制失效。


Repeat Times (“r=”),其语法规则为:

r=<repeat interval> <active duration> <offsets from start-time>

它定义了对此会话的时间重复次数。“r=”行的取值是根据前面的“t=”决定的。


Time Zones (“z=”), 其语法格式为:

z=<adjustment time> <offset> <adjustment time> <offset> ....
会话时差处理。为了对重复的会话(此会话贯穿一个白天晚上到标准时间的修改流程,或者相反处理)进行定时处理,有必要对标准时间设定一个偏移时间数值。这样就要求针对不同的时间对应不同的时间标准。每个国家可能都有自己的时差日期基准。因此,为了保证对同一会话在不同时期进行定时处理,必须对数据双方双方明确设定一个时间基准和偏移值。


Encryption Keys (“k=”),其语法结构如下:

k=<method>k=<method>:<encryption key>
如果传输消息需要通过一个安全的传输方式进行的话,SDP可以用来传输密钥。“k=” 行提供了一个简单的密钥交换机制。为什么说是简单的交换机制?因为当初设计”k=”行的主要目的是考虑和旧部署规范的兼容性支持,也不是规范所推荐的使用方式。“k=”本身不具有拓展性,支持不了更多传输参数和密钥管理功能,一些比较新的密钥交换机制也逐步使用在了SDP会话描述中。“k=”使用仍然在更新中,一些语法和内容相对比较旧(例如缺少安全协议中要求的两个密钥的支持:confidentiality 和integrity),因此,笔者不打算在这里再展开讨论。关于“k=”具体的使用方式,用户可以通过RFC 4567规范和RFC4568做更加详细的理解,这两个规范中增加了更多对SDP的拓展支持。这些交换机制和密钥管理也会使用在一些新的应用场景中。


Attributes (“a=”),其语法格式为:

a=<attribute>a=<attribute>:<value>
Attributes 表示拓展的SDP的基本含义,我们这里翻译为特征属性。特征属性参数可以定义在会话级和媒体级。媒体描述中可以定义多个“a=”行来定义具体的媒体特性。“a=”可以出现在第一个媒体描述前,这是会话级的属性参数,这样的属性是针对整个会议会议定义的,不是针对单独媒体定义的属性。特征Attributes属性可以支持两种属性格式:
"a=<flag>."  // 例如:"a=recvonly." "a=<attribute>:<value>. // 例如 "a=orient: landscape."
特征属性的取值取决于使用的媒体工具。特征属性的值除了0x00 (Null),0x0A (LF),和 0x0D (CR)以外,可以是任何octet字符串。默认取值解析为ISO-10646字符形式,通过UTF-8解码取值。如果接收方不理解已接收的特征属性值,接收方必须忽略此特征属性值。


Media Descriptions (“m=”): 其语法格式为:

m=<media> <port> <proto> <fmt> ...

一个会话描述中可以包含多个媒体描述。每个媒体描述以”m=”开始,媒体描述结束以下一个媒体描述开始或者以会话描述结束来结尾。一个媒体描述包含几个媒体描述子项:


<media>,它表示媒体类型,目前定义的媒体类型包括语音,视频,应用程序,和消息。未来可能还有其他类型,用户需要密切关注。


<port>,它是一个传输端口,媒体发送到此端口。此端口依赖于”c=”行定义的网络传输协议。其他被媒体应用程序使用的端口,例如RTCP端口需要根据其基准端口来设定相应的端口,或者分开特征属性设置。如果使用了非连续端口或者没有遵从偶数-RTP端口,奇数-RTCP端口的规则处理的话,必须增加一个”a=rtcp:”行。应用程序被发送到一个端口,此端口是一个奇数端口,并且出现”a=rtcp:”行时,此媒体一定不能从RTP端口减一,应用程序必须发送RTP数据到<port>指定的端口,并且发送RTCP到”a=rtcp”属性设定的端口。对于某些应用程序,它们的媒体流通过层级解码发送到单播地址时,它们有必要设定多个传输端口。使用语法和多播地址的方式类似: m=<media> <port>/<number of ports> <proto> <fmt> …。这种场景中,使用的端口依赖于传输协议类型。一些读者可能明白,通常默情况下,RTP使用偶数端口传输数据,它的RTCP使用高一位数的奇数端口控制RTP会话。<number of ports>表示RTP会话数量。例如:

        

m=video 49170/2 RTP/AVP 31
这里,媒体会话将设定一个视频媒体类型,端口从49170开始计算,包括两对RTP媒体会话,其中第一对媒体会话是49170端 口(RTP)和 49171 端口(RTCP)。第二对是从49172(RTP)和49173端 口(RTCP)端口。RTP/AVP是传输协议,31是媒体格式(fmt,H261)。以上介绍的是默认环境中使 用的连续端口,如果端口使用的是非连续的端口,需要增加属 性“a=rtcp:” 分开独立的端口属性。

<proto>,它是传输协议。这里的传输协议依赖于”c=”行定义的地址类型。目前支持的主要的几个类型包括:UDP,RTP/AVP,RTP/SAVP。这里专门针对媒体格式设定不同的传输协议是因为同一网络协议时,标准的媒体格式可以通过不同的传输协议来进行传输。这样的设定可以支持不同的网络传输和满足不同检测工具部署。


<fmt>,它表示一种媒体格式描述。前面第四个子项或者其他后续子项都表示媒体格式。媒体格式描述的解析依赖于<proto>子项的值。如果<proto> 子项是”RTP/AVP”或者”RTP/SAVP,媒体格式描述会包含RTP payload 类型号码。当给定了一个payload类型列表时(静态方式,从96-127),这表示所有的媒体格式可以适用于此会话中,但是,通常列表中的第一个格式应该作为此会话默认支持格式。如果payload类型列表是动态的payload类型列表的话,SDP使用”a=rtpmap:”属性来执行一个映射(从RTP payload 类型号码到媒体解码名称),通过媒体类型号码到媒体解码名称的对应关系来确认payload格式。”a=fmtp:” 行可以用来设定具体的媒体格式参数。在很多应用场景中,用户可以看到动态payload不匹配导致的问题,例如Asterisk或者FreeSWITCH的运行环境中,我们经常看到类似的错误:
Unsupported payload type received


关于动态payload的规范定义,用户可以查阅RFC3551-6。


6

SDP属性说明/IANA/ABNF

除了我们前面介绍的会话描述和媒体描述说明以外,SDP以支持了特征属性的拓展,通过拓展的属性可以支持更多的属性参数。SDP属性支持了会话级和媒体级属性两种。会话级属性顾名思义,它是针对会话层级的属性。媒体级属性针对媒体属性设置所设置的属性。大家经常遇到的也是一些在应用场景中常见的属性设置,我们这里也不可能做一个非常完整的归纳。因此,因为篇幅所限,笔者只能介绍一下其基本的语法构成:


a=tool:<name and version of tool>

具体在一般场景中看到的例如:

a=ptime:<packet time>
此特征属性表示一个数据包中的媒体打包时长的特征属性。如果使用RTP映射的话,使用的语法为:
a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encodingparameters>]


另外,为了规范SDP会话描述中的语法格式,读者也需要了解几个相关的规范,这些规范定义了SDP的语法规则。IANA和ABNF是在SDP规范中需要了解的基本语法,其中,ABNF规定了一些基本的规则,包括空格,大小写,分割行和各种会话描述,媒体描述以及特征属性的完整说明。


7

总结

在本章节中,笔者重点介绍了关于SDP规范细节的会话描述部分以及相关的拓展属性介绍。笔者通过三个子章节的篇幅,基本介绍了SDP的使用方式和要求,增加针对SDP会话描述和媒体描述的规范细节做了充分说明和拓展介绍,并且对SDP的特征属性已经IANA和ABFN做了一些简单介绍。以上内容都相对比较抽象,读者需要在实际生产环境中不断练习,不断解决排查问题,才能对这些内容有进一步的了解。

到此为止,笔者已经完整介绍了SDP的基础和核心语法。这些基础的内容为我们后续章节的介绍打下了一个比较好的基础。在接下来的章节中,我们将首先完整介绍SDP的协商模式。

再次说明,因为很多约定用语需要翻译成中文的含义,本文中的翻译风格或者理解不同可能有一些出入,希望读者谅解。



参考链接:

https://www.rfc-editor.org/rfc/rfc3556

https://www.rfc-editor.org/rfc/rfc3890

https://www.rfc-editor.org/rfc/rfc4567




完整SIP/SDP媒体协商概论-SDP基础-会话描述说明
完整SIP/SDP媒体协商概论-SDP基础-会话描述说明



关注微信公众号:asterisk-cn,获得有价值的Asterisk行业分享
Asterisk freepbx FreeSBC技术文档: www.freepbx.org.cn
融合通信/IPPBX商业解决方案:www.hiastar.com
如何使用FreeSBC,qq技术分享群:334023047, www.freesbc.cn



联系电话-18665301040
客服-3
客服-2
客服-1