YD T 1936-2009 会话描述协议(SDP)技术要求.pdf

上传人:周芸 文档编号:171962 上传时间:2019-07-15 格式:PDF 页数:35 大小:767.21KB
下载 相关 举报
YD T 1936-2009 会话描述协议(SDP)技术要求.pdf_第1页
第1页 / 共35页
YD T 1936-2009 会话描述协议(SDP)技术要求.pdf_第2页
第2页 / 共35页
YD T 1936-2009 会话描述协议(SDP)技术要求.pdf_第3页
第3页 / 共35页
YD T 1936-2009 会话描述协议(SDP)技术要求.pdf_第4页
第4页 / 共35页
YD T 1936-2009 会话描述协议(SDP)技术要求.pdf_第5页
第5页 / 共35页
亲,该文档总共35页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述

1、ICS 3304030M 12 Y口中华人民共和国通信行业标准YD厂r 1 936-2009:千压l,白 描述协议(SDP)技术要求Technical Requirements for Session Description Protoco2009-06-1 5发布 2009-09-01实施中华人民共和国工业和信息化部发布目 次YD厂r 1 936-2009前言II1范l虱-一12规范性引用文件l3术语、定义和缩略语14基本要求及建议241 SDP的表示242媒体和传送信息24 3定时信息24 4私有会话245关于会话的更多信息34 6分类347国际通用性35 SDP基本内容351 SDP编码

2、-“352 SDP语法内容353对传真的支持16附录A(规范性附录)SDP语法20附录B(资料性附录)SDP的用途27附录C(资料性附录)安全考虑28附录D(资料性附录)SDP在T38传真的应用范例29参考文献31刖 吾YD厂r 1 936-2009本标准对应于IETF组织的RFC 4566会话描述协议,与其一致性程度为非等效,主要差异如下按照我国行标的要求对文档的编排格式做了修改,并根据需要对章节结构做了调整;增加了53节,“对传真的支持”,相应地,增加了相关扩展内容的ABNF语法:增加了a=modem属性。本标准的附录A为规范性附录,附录B、附录C和附录D为资料性附录。本标准由中国通信标准

3、化协会提出并归口。本标准起草单位:工业和信息化部电信研究院、上海贝尔阿尔卡特股份有限公司本标准主要起草人:吴宏建、陈靖会话描述协议(SDP)技术要求YD厂r 1 936-20091范围本标准定义了用于进行会话声明、会话邀请和其他形式的多媒体会话邀请的会话描述协议的基本技术内容。本标准适用于任何需要通过会话描述协议进行会话声明、会话邀请或其他形式的多媒体会话邀请的应用协议。2规范性引用文件下列文件中的条款通过本部分的引用而成为本部分的条款。凡是注日期的引用文件,其随后所有的修改单(不包括勘误的内容)或修订版均不适用于本部分。然而,鼓励根据本部分达成协议的各方研究是否可使用这些文件的最新版本。凡是

4、不注El期的引用文件,其最新版本适用于本部分。ISOIEC 106461信息技术统一多字节编码字符集(UCS)第l部分:架构和基础多语言平面ISOIEC 88591 信息技术八比特单字节编码图形字符集第l部分:1号拉丁字母表rrU-T H332 接收基于互联网的H323会议的多媒体终端RFC 1305 网络时间协议(版本3)规范及实现RFC 1890 具有最小控制的音频和视频会议的RTP模式RFC 2044 UTF-8,统一编码和ISO 10646的转换格式3术语、定义和缩略语31术语和定义下列术语和定义适用于本标准。311会议Conference两个或多个用户通过使用特定的软件进行通信。31

5、_2会话Session一个或多个多媒体的发送者和一个或多个接收者,以及从发送者流向接收者的数据流的组合。会议是会话的一种例子。313会话声明Session Announcement将会话描述主动传送给用户的一种机制,在这个过程中,用户并没有显式地请求会话描述。314会话描述Session Description一种充分定义的格式,用于传送能够发现并能加入到多媒体会话的足够的信息。YD厂r 1 936200932缩略语下列缩略语适用于本标准。SAP Session Annoucement Protocol 会话声明协议SDP Session Description Protocol 会话描述协议

6、SIP Session Initial Protocol 会话初始协议UDPTL Facsimile UDP Transport Layer(protoc01) 传真UDP传送层协议4基本要求及建议41 SDP的表示一个SDP的会话描述通常通过内容类型为“applicationsdp”的MIME来表示。42媒体和传送信息SDP包括下面的媒体信息:媒体类型(视频、音频等);传送(transport)协议(RTPUDPIP,H320等);媒体格式(H261视频,MPEG视频等)。除了媒体格式和传送协议外,SDP还应该传递详细的地址和端口信息。例如,对于组播会话,还应该传送下列信息:媒体的组播组地址

7、;媒体的传送端口。这里的地址和端口是指组播流(不管是发送的、接收的、还是双向的)的目的地地址和目的地端口。对于D单播会话,传送下列信息:媒体的远端地址;媒体的远端传送端口。这里所提的地址和端口的语义依赖于所定义的媒体和传送协议。默认情况下,指的是数据要发往的远端地址和远端端口。有些媒体类型可能会熏新定义这种行为,但是不建议这么做,因为这将会增大实现的难度。43定时信息会话在时间上可能有下限,也可能是没有下限。无论是否有下限,会话可能只在特定的时间内处于激活状态。SDP能够:传送会话开始或结束时间的列表;指明每一个时间界限的重复次数,如“每周三上午进行一个小时”。这个定时信息是全球保持一致的,与

8、本地时区和夏令时无关。44私有会话可以创建私有会话和公共会话。私有会话通常通过在分发过程中加密会话描述的方式来实现,加密的细节依赖于用来传送SDP的机制。在SAP和SIP环境中定义了这种机制,其他的方式待定。如果一个会话声明是私有的,使用私有的会话声明去传送每个会议媒体解码所必要的密钥,包括能够知晓每个媒体所使用的加密方案的足够信息。2YD厂r 1 936200945关于会话的更多信息会话描述应当传送关于是否决定加入一个会话的足够多的信息。SDP可以包含以统一资源标识(URI)形式出现的附加的指针,以提供更多的关于该会话的信息。46分类当大量的会话描述通过SAP或其他的公告机制分发的时候,人们

9、总是希望能够筛选出感兴趣的声明。SDP支持自动的分类机制(“a=cat:”属性,见第5章)。47国际通用性SDP规范建议采用UTF-8(RFC 2044)编码的ISO 10646字符集,以支持多种语言的表述。为了有助于支持简洁的表述,当需要时,SDP也允许使用其他字符集,如ISO 88591。这种国际通用的特性仅适用于自由文本(freetext)字段,如会话名称和背景信息等,而不是整个SDP。5 SDP基本内容51 SDP编码SDP完全是文本形式的,采用UTF-8(砌1c 2044)编码的ISO 10646字符集,SDP字段名和属性名只使用uTF8编码的USASCII子集,但是文本字段和属性值

10、可以采用整个ISO 10646字符集。文本形式不同于诸如ASN1或XDR的二进制编码。选用文本形式,是为了提高便携性和传送方式的多样性,例如,会话描述可通过MIME电子邮件传送。此外,还可以支持灵活的、基于文本的开发工具(如TclTk),用于生成和处理会话描述。然而,由于分配给SAP声明的带宽是严格受限的,所以编码会很简洁。此外,由于声明会通过不可靠的方式(如电子邮件)来传送,或是被中间缓存服务器损坏,所以编码在设计时,就具有非常严格的顺序和格式规则,这样,即使存在会导致声明的格式异常的错误,但也能轻而易举地检测出来并将其丢弃。接收方如果收到加密的声明,但没有密钥,也可以迅速地将其丢弃。52

11、SDP语法内容521 SDP语法结构一个SDP会话描述由多个形式为“=”的文本行组成。是一个大小写敏感的字符。是一个结构化的文本串,它的格式I扫决定,也是大小写敏感的,除非有特定的字段另作定义。“=”两边都不能有白空格(Whitespace)。一般来说,或者是多个由单空格字符分隔的字段,或者是一个任意格式的字符串。一个会话描述包含一个会话级的描述(应用于整个会话和所有媒体流)和多个可选的媒体级描述(仅应用于单个媒体流)。一个声明包含一个会话级部分,并尾随零个或多个媒体级部分。会话级部分以“v=”行开头,紧跟着是第一个媒体级部分。媒体描述以“m=”开头,后面跟着下一个媒体描述,或者是整个会话的结

12、尾。通常,会话级的值对于所有的媒体来说是缺省的,除非有一个相对应的媒体级部分定义了其他的值。当SDP由SAP来传送表达时,每一个包只允许有一个会话描述。当SDP由其他方式来传送表达时,多个会话描述可以串接在一起(指示一个会话描述开头的“v=”行,终结前一个会话描述)。522会话描述的文本行在每一个描述中,有些行是必须的,而有些是可选的。但所有的行必须严格按照表1、表2和表33YD厂r 1 936-2009中指定的顺序给出。固定的顺序可以增强检错能力和降低解码要求。表1给出了会话描述的所有可能的行,表2给出了时间描述的内容,表3给出了媒体级描述的行。表1会话描述行类型 含 义 可选性协议版本(p

13、rotocol version)会话发起者和会话标识(originator and scssmn identifier)会话名称(session name)会话信息(session information)会话描述的URIEmail地址p2 电话号码(phone number)连接信息(connection information)若所有媒体中都包含则不需要b2 带宽信息(bandwidth information)零个或多个带宽信息行一个或多个时间描述(见表2)时区校正(rime zone adjustments)k- 密钥(encryprion key)(零个或多个会话属性行) o零个或多

14、个媒体描述(见表3)其中,“时间描述”见表2。表2时间描述行类型 含 义 可选性t= 会话激活的时间r= 零个或多个重复次数如果有“媒体描述”,则“媒体描述”见表3。表3媒体描述行类型 含 义 可选性媒体名称和传送地址(media nalne andtransport address)媒体标题(media rifle)连接信息(connection information)若会话级已包含则可选b= 带宽信息(bandwidth informadon)k- 密钥(encryption key)(零个或多个媒体属性行)如果声明中含有SDP的解析器不能理解的“type”字母,SDP解析器必须完全忽略

15、这个声明。属性机制(“a=”,下文有说明)是扩展SDP的基本途径。通过扩展,可以使SDP适用于特定的应用和媒体。有些属性有特定的含义(如本文中列出的),其他属性可以加在特定的应用、媒体或会话基础之上。会话必须忽略任何它不认识的属性。会话级的连接(“c=”)和属性(“a=”)信息应用于该会话中所有的媒体,除非在媒体描述中有相同名称的连接信息或属性。例如,在下文给出的例子中,每个媒体按照“rccvonly”属性来实现。SDP描述示例:v-O4YD厂r 1 9362009o=mhandley 2890844526 2890842807 IN IP4 12616644s=SDP Seminari=A

16、Seminar on the session description protocolu=http:wwwCSuclacukstaffMHandleysdp03pse-mjhisiedu(Mark Handley)c=IN IP4 22421712127t=2873397496 2873404696a=recvonlym=audio 49170姗|舯0m=videO 51372 R!nVAVP 3lm=application 32416 udp wba=orient:portrait诸如会话名称和信息的文本字段,都是以字节字符串形式出现的,它包含除了0x00(Nul)、0xoa(AscII“L

17、F换行”)和OxOd(ASCH“CR回车”)之外的所有字节。CRLF(0xodoa)通常用来表示一条记录的结尾。解码器也应该能接受0xoa作为一条记录的结尾。缺省情况下,这些字节字符串包含在UTF-8编码的ISO 10646字符集中。可通过“charset”属性更改字符集。会话描述可以在“o=”、“u=”、“e=”、“c=”和“am”行中包含域名。在SDP中使用的任何一个域名必须遵从RFc 1034和RFC 1035的要求。国际域名(IDN,RFc 3490)必须用ASCII兼容编码(ACE)形式表述,而且不能用UTF-8或其他编码直接表述。5221 协议版本v=0“v_”字段给出了SDP协议

18、的版本。本标准定义了版本0,目前没有更小的版本。5222会话发起者“会话发起者”行的语法格式如下:o=“o=”行给出了会话发起者的用户名、用户主机的地址,并附上会话标识和会话版本号等。是用户登录到始发主机的用户名,如果始发主机不支持用户标识的概念,则该字段填“一”。中不能包含空格。是一个数字串,它和、和-起组成全球统一的标识,用来惟一标识会话。分配的方法由生成该标识的工具来决定。但是建议使用网络时间协议(NTP)的时间戳以保证惟一性。是当前会话描述的版本号。如果会话数据做了修改,则这个会话的版本号要增加,具体用法取决于开发工具。建议但不强制要求使用NTP的时间戳。是一个文本串,它给出了网络类型

19、。目前先定义“斟”,它表示互联网。其他值待定。是一个文本串,给出了要遵循的地址类型,这里先定义了两种取值: “IP4”和“i16”。是一个全球惟一的地址,它表示创建会话的主机的地址。对于一个IP4的地址类型,它要么是完全标准的机器域名,要么就是带点的十进制IPv4的地址。对于IP6地址类型,它要么是完全5YD厂r 1 936-2009标准的机器域名,要么就是这台机器的压缩的文本的IPv6地址。对于IP4和IP6,标准的域名应该给出,除非不可用,在这种情况下,全球惟一的地址可能会被替换。总之,“o=”给出了这个版本的会话描述的全球惟一的标识,它的子字段除TPb,组合在一起共同标识了这个会话,而不

20、管该会话是否有过会话数据的修改。出于保密考虑,有时候需要将会话发起者的“username”和P地址虚化。考虑到这个因素,只要这不影响到这些子字段作为标识的惟一性,可以以一定的方式在“O”行中提供和。5223会话名“会话名”行的语法格式如下:s=“s=”字段表示会话名称,是基于文本的。每一个会话描述中必须有一个且只能有一个“s=”字段。“s=”字段不能为空,宜包含ISO 10646字符集(但也需要看“charset”属性)。如果一个会话没有有意义的名称,应当使用这样的表达式:“s=”(通过一个空格来表示会话名称)。5-224会话和媒体信息“会话和媒体信息”行的语法格式如下:i=“i=”字段给出了

21、关于会话的信息。在每一个会话描述中最多包含一个会话级的“i-”字段,在每一个媒体中也最多包含一个“i-”字段。虽然它可能会被省略,但省略可能会造成会话声明信息不全,所以在创建会话的用户界面中应当提供文本输入。如果在SDP中出现了该字段,它必须包含ISO 10646字符集(但还需要看后面的“charset”属性)。单个的“i-”字段也可以用在媒体定义中。在媒体定义中,该字段主要是用来标记媒体流。这样,当一个会话中有多个具有相同媒体类型的不同媒体流时,就可以区分开来。例如,在一个会话中有两种不同的白板,一个用来为播放幻灯片准备,另一个是为反馈和提问准备。5-2-25统一资源标识131:11URI的

22、格式如下:u=URI是www客户端使用的统一资源标识符。URI应当是指向与会议相关的附加信息的指针。该字段是可选的,但如果选用了该字段,则应当在第一个媒体字段前对其进行规定。每一个会话描述中不允许有多于一个的URI字段。5226 电子邮件地址和电话号码e=p=这两个SDP行规定了负责会议的用户的联系信息。该用户与创建会议声明的用户不一定是同一个人。电子邮件字段和电话字段都是可选的。允许有附加的电子邮件和电话字段。如果SDP中出现了这些字段,他们必须在第一个媒体字段之前给出。每个会话描述可以有多个电子邮件或电话字段。电话号码应当遵照国际通用格式,也就是要加上“+”和国家码。在国家码和其他号码之间

23、必须有一个空格或者是连接符(“一”)。空格和连接符可以用来分隔电话号码以增加可读性,例如:6YD广r 1 936-2009p=+441713807777或者p=+1 617 253 6011电子邮件和电话号码都可以带有一个可选的文本串,用来给出被联系人的姓名。文本串用圆括号括起来,例如:e-mjhisiedu(Mark Handley)此外,电子邮件和电话号码也都允许采用RFC 822的名称引用规则。例如:e=Mark Handlcy文本串宜采用ISO 10646字符集和UTF-8编码方式。如果定义了会话级的charset属性则也可以采用ISO88591字符集或其他的编码方式。522_7连接数

24、据c=“c=”字段含有连接数据。一个会话描述必须在每个媒体描述(见下文)中都包含一个“c=”字段,或者必须包含一个会话级的“c=”字段。它也可以包含一个会话级的“c=”字段并在每个媒体描述中包含一个附加的“c=”字段。在这种情况下,对于相关的媒体,应当优先选择媒体描述中的取值而不是会话描述中的取值。第一个子字段是网络类型,它是一个文本串,表示网络的类型。它的值“矾”表示网络类型是互联网。将来也可能会定义其他值。第二个子字段是地址类型,它使SDP可以用在非基于口的会话中。目前,只定义了“IP4”和“IP6”。第三个子字段是连接地址。可选的额外子字段可以加在连接地址之后,这得取决于地址类型的取值。

25、对于为IPv4和IPv6地址,连接地址定义如下:如果会话是组播,则连接地址是坤组播组地址。如果会话不是组播,那么连接地址包含一个数据源或者数据中继点或者数据落地点的单播坤地址,这由附加的属性字段决定。最好不要在与组播声明通信的会话描述中给出单播地址,虽然这样做并未被禁止。使用IPv4组播连接地址的会话除了有组播地址外,还必须有一个生存时间值(TrL)。rIL的取值范围为0255。既然rIL的值必须明确,那么就不要再用它来限定组播业务量了,应用可以通过限定地址范围来代替rIL的这种用法。IPv6组播不使用rIL,所以1-IL的值也不会出现在IPv6组播地址中。最好通过限定的IPv6地址范围来限定

26、会议的范围。nL附在地址的后面,用斜线与地址分隔,如:c=IN4 224211127分级或分层的编码方案都是多个数据流,在这里,从单个媒体源来的编码被分割成多层。接收者只要通过预订这些层中的一个子集就能够选择期望的质量(也就是带宽)。这种分层的编码通常在多个组播组中传输,允许组播的修剪。这项技术可以将非期望的业务量拒绝在只需要特定级别的站点之外。对于需要多个组播组的应用,我们允许连接地址采用下面的形式:【触b,地址数量的缺省值为一。所分配的组播地址以“基本的组播地址”为首的连续地址。例如假设“c=”字段为:7YD厂r 1 936-2009c=q口4 2242111273贝表示使用的地址是224

27、211、224212和224213,tcI是127。这与在一个媒体描述中带有多个c-行在语义上是一样的,即:c=IN,4 224211127c=IN4 224212127c=IN邛14 224213127同样,若Pv6的地址为:c=IN IP6 FFl5:1013,则相当于:c=IN IP6 FFl5:101c=IN IP6 FFl5:102c=IN IP6 FFl5:103注意,m字段不出现在116地址当中。如果在一个分级或分层的编码方案中为不同的层提供组捶地址,可以在每一个媒体描述中给出多个地址或多个“c=”行。但不能给出一个会话级的“c=”行。前面提到的多地址描述中用到的斜线符是不能用在

28、口单播地址中的。5228带宽b=:“带宽”规定了会话或媒体所建议使用的带宽,它是可选的。II勺默认单位是kbits。是带宽修饰语,它可以是字母,也可以是数字,它给出T数值的含义。这里先定义了两种:“CT”和“AS”,其他的值待定。(1)CT(Conference Total)“CT”表示在组播骨干网上或者一个特定的组播管理范围区域内,暗含的与每一个TrL关联的最大带宽。如果会话或媒体的带宽与范围中暗示的带宽不同,则应当提供“b-CT”行,用来给出建议使用的上限带宽。这样做的主要目的是,当有两个或更多的会议时,为这些会议能否同时共存提供一个近似的估计。当在RTP中使用CT修饰语,如果几个RTP会

29、话只是会议的一部分,CT指的就是所有RTP会话总带宽。(2)AS(Application-Specific Maximum)在这种情况下,带宽由应用自定义。也就是说,这个带宽是应用定义的最大带宽。如果可能,这通常与应用的“最大带宽”所设置的保持一致。对于基于RTP的应用,“AS”给出了RTP的会话带宽。注意,CT指的是所有站点的所有媒体的总带宽特性;而AS指的是单个站点的单个媒体的带宽特性,即使同时还有多个站点在发送媒体。扩展机制:开发人员可以定义实验用的带宽修饰语,具体的做法是在他们的修饰语前加上前缀“X-”,例如:b=X-YZ:128SDP的解析器应当忽略带有不认识的修饰语的带宽字段。修饰

30、语可由字母和数字组成,不限制其长度,但建议尽量短。8YD,T 1 936-20095229时间设置t=“t=”字段明确了一个会话的开始时间和结束时间。多个“t-”字段则表示会话在多个不规则的时间段内处于激活状态,每个附加的“t-”字段表示一段会话激活的附加的时间段。如果会话激活状态的时间是有规律的,宜在“t=”字段后附上17=-字段(见下文),在这种情况下,“t-”字段规定的是整个过程的开始时间和结束时问,包括重复的过程。第一个和第二个子字段分别表示会话的开始时间和结束时间。这些值采用的是NTP(见RFC 1305)的十进制表示法,单位是秒。要想将这些值转成UNIX的时间,就必须减去十进制数“

31、2208988800”。如果停止时间设成0,则会话时间是无下限的,但会话在开始时间之前不会被激活。如果开始时间也是为“0”,则会话会被认为是永远的会话。用户界面应当避免让用户创建无下限和永远的会话。因为这两种情况并没有说明会话会在什么时候终止,这会给时间表的安排带来难度。我们可以假定无下限的会话只能在从当前时间或开始时间算起的半个小时内处于激活状态。当关于会话何时结束的新的信息可用时,结束时间应当提供并作适当的修改。这种情况下,可以采用正常的处理方法,而不用理会前面所作的假定。永远的会话对用户来说是永远不会激活的,除非它和明确声明会话何时激活的“#”字段一起使用。一般地,对于任何期望持续时间少

32、于2个月的会话来说,不宜创建永远的会话:对于那些期望持续时间少于6个月的会话来说,应当试图阻止永远的会话。5221 O重复次数r=“r=”字段定义了一个会话的重复次数。例如,如果一个会话在每周周一上午10点和周二上午11点都会被激活1h,并且按照这样的规律持续3个月,那么“t=”字段中的应该是第一周的上午lO点,并且采用NTP的表示法来表示这个时间。“r=”字段中的为一周,为lh,应当为0和25个小时。相关的“t-”字段的停止时间应该是第3个月的最后一个会话的终止时间。所有字段默认的单位都是秒,所以,“r=”和“仁”字段应当如下:t=3034423619 3042462419r=604800

33、3600 0 90000为了使声明显得更加简练,时间单位可以是天、小时或分。它的基本语法就是在数字后面紧跟着一个大小写敏感的字母。不允许使用分数,可采用更小的单位来表示。这里规定的字母有:d天(86400s)h小时(3600s)m分(60s)r秒(可以省略不用)这样,前面的声明可以改为:r=7d lh0 25h在一个“f=”字段中表示按月和按年重复的表示方法在这里并未直接定义,而是采用多个分隔的“t=”字段的方法来显式地列出会话的时间。9YD,T 1 936-200952211时区z=为了安排一个重复的会话,且这个会话跨越了夏令时调整成标准时间的过程,或标准时间调整成夏令时的过程,则需要指明从

34、基准时间开始的时间补偿。这样做是完全有必要的,因为不同的时区在一天当中不同的时间更改时间,不同的国家更改成夏令时或改回标准时间的日期也不一样,而有些国家根本就没有夏令时。这样,为了安排一个会话的时间,必须明确指出这个会话的时区。为了简化接收方的工作,允许发送方给出发生时区校正的NTP时间以及从最初开始量测时间开始算起的时间补偿。Z-字段可以让发送方列出这些校正的时间和时间补偿。例如:z=2882844526*lh 2898848070 0这表示,在时刻为2882844526时,会话的重复次数所用以计算的基准时间要后调一个小时;而在时刻为2898848070时,会话的原来的基准时间将会被恢复。校

35、正的时间往往都是相对于开始时间中所指的时间。校正时间不会累加。如果会话可能持续几年,那么会话声明最好定期修改,而不是在一个声明中增加校正说明。52-212密钥k=k=:如果是通过安全可信的信道传送,SDP协议也可以用来传递密钥。其中一种简单的交换密钥的方式就是通过“k_”行来实现,为了兼容老的版本,本标准支持这种实现方式,但是不建议这种用法。密钥字段允许放在第一个媒体行之前,表示它适用于这个会话中的所有媒体。如果需要也可以为每个媒体行设置一个密钥。本文不讨论密钥的格式和用法,具体内容可参见RFC 2822。指出了获得可用密钥的机制。密钥可通过外部方法或从给出的被编码的密钥中获得。下面定义了一些

36、(1)k=clear:在密钥字段中未作更改地给出了密钥。(2)k=base64:密钥在密钥字段中给出,但经过了“base64”编码,因为它包含了SDP禁止的字符。(3)k=uri:在密钥字段中给出了uRJ。URI指向了包含密钥的数据,且在获得密钥前可能需要鉴权。当发出了带有URI的请求,在响应中应通过MIME content-type指明密钥的编码方式。URI通常是SSLrILS保护的H兀P URI(“https:”)。(4)k=prompt在这种SDP描述中,虽然会话或媒体流已被加密,但该字段并不包含密钥。当用户尝试加入会话时,会被提示有关密钥的信息。用户拿到这个密钥后便可对媒体流进行解密。

37、这种使用方式并不建议采用,因为安全性不高。52213属性10YD厂r 1 936-2009a=a=:属性是扩展SDP的基本方式。属性可以被定义成会话级的,或是媒体级的,或者两者都可。一个媒体描述可以拥有任意数量的属性行(“a=”)。这些属性行是媒体级的,用来提供与媒体有关的信息。属性字段也可以加在第一个媒体字段之前,表示会话级的属性,用来传递适用于整个会议的附加的信息,而不仅仅针对某个媒体。一个很好的例子就是用在会议的基础控制策略上。属性字段可有两种形式:特性属性(property attributes):特性属性非常简单,它的格式为“a=”。这神属性的出现表示这个属性是会话的一个特性,如“a

38、-recvonly”。带值属性(value attributes):它的格式为“a=:”。如某个白板的带值属性为a=odent:landscape。对属性的解释取决于所使用的媒体工具。属性名必须是SO 10646UTF8的USASCO子集。属性值由字节串组成,可以使用除了Ox00(Nul)、0x0A(LF)和0x0D(cR)外的任何字节。默认情况下,属性值用ISO 10646字符集来解析。与其他的文本字段不同,属性值不受“charset”属性的影响。然而,当定义一个属性时,它可以被定义成与字符集无关的。在这种情况下,它的值可以用会话级的“charset”指定的字符集来解析,而不是用ISO 10

39、646来解析。属性需要在IANA注册。未注册的属性应加上前缀“x”以避免和已注册的属性发生冲突。另外,如果收到一个不认识的属性,接收方可以忽略它。5|2,21 4媒体描述m=一个会话描述可能包含多个媒体描述。每个媒体描述以“m-”字段开始,而以下一个“m=”字段或会话描述的结尾结束。一个媒体字段也可以有多个子字段。是媒体类型。目前定义的媒体有:“audio”(音频)、“video”(视频)、“application”(应用)、“text”(文本)和“message”(消息)。这个列表还可能会扩展。是媒体流要发往的传送端口。传送端口取决于“c=”字段中指明的正在使用的网络,以及在第三个子字段中定

40、义的传送协议。其他的媒体应用所使用的端口(如RTCP端口,见RFC3605)可从基准媒体端1:2通过一定的算法导出来或在一个单独的属性中规定(例如在RFC 3605中定义的“a=rtcp:”)。注:基于UDp的传送端口,其值范围应当为102465535。对于RTP协议,它应当使用偶数端口。如果使用非连续的端口,或者说在不愿按照RTP(偶数端口)和RTCP(奇数端口)的奇偶规则来实现时,则必须使用“a-rtcp:”属性。例如,如果应用被请求将媒体发送到一个奇数的所指示的端12,而且给出了“a-rtcp:”属性,这就意味着它必须将RTP发送到所指示的端El,而发送RTCP到“a=rtcp:”所指示

41、的端口。在有些应用中,需要将按层来编码的流发送到一个单播地址,这就需要指出多个传送端口。这里可采用与“c=”字段中表示多个P地址时类似的表示法。如下:m=YD,T 1 936-2009在这里,所使用的端口取决于传送协议。对于RTP,默认使用偶数端口发送数据,而RTCP使用下一个更大的奇数端口。例如:m=video 491702 RTPAVP 3l它定义了两个RTPRTCP对,第一个RTPRTCP对的端口分别是49170和49171,第二对分别是49172和49173。“RTPAVP”表示的是传送协议,“31”表示格式(见下文)。如果在“c=”字段中定义了多个地址,同时在“m-”字段中定义多个端

42、口,则意味着从端口到相应的地址之间一一对应。例如:c=IN4 2242111272re=video 491702 RTPAVP 3 l这表示地址224211对应于端口49170和49171,而地址224212对应于端口49172和49173。目前没有定义多个“m=”行使用一个相同的传送地址的情况。表示传送协议。传送协议的值取决于“c=”字段中的“地址类型”。如果地址类型是“IP4”,则表示传送协议位于IP4之上。对于IP4的情况,一般会期望所有的媒体流量由RTPUDP来携载。下面定义了一些传送协议,但传送协议有可能会扩展,并需要在IANA注册成为新的协议。udp一表示在UDP上运行未规范化的协

43、议。RIP,A、,P一rrF制定的实时传送协议,使用带有最少控制功能的音捌视频模式,承载在UDP之上。RTPAVP应符合RFC 1890的要求。R1wsA、,卜_表示安全的实时传送协议,承载在UDP之上。如果应用使用了单个组合的媒体格式和位于UDP之上的传送协议,则建议“传送协议”的值为“udp”,并使用格式字段,用于区分组合的协议。如果位于UDP之上的传送协议用来承载多个不同的需要会话目录区分的媒体类型,则需要单独指明传送协议和媒体格式。RTP是带有多种能被会话目录识别的净荷格式的传送协议。除了媒体格式之外还要指明传送协议,这主要是因为相同标准的媒体格式可能在不同的传送协议上携载,即使网络协

44、议是一样的。例如vatPCM音频和RTPPCM音频,此外还有TCPRTPPCM音频。此外,传送协议特定但格式任意的中继接续和监视工具也可能出现这种情况。对于工作在RTP音频,视频模式(RTP AudioVideo Profile)下的RTP媒体流,传送协议的值为“RTPAVP”。将来定义的其他RTP模式将采用相同的定义方法。例如,“RTPXYZ”表示工作在名为“XYz”的模式方式下的RTP。是媒体格式描述。该字段和任意一个后续子字段描述了媒体的格式。对媒体格式的解释取决于子字段的值。如果是“RTPAVP”或“RTPSAVP”,N包含净荷类型编号。如果给出了净荷类型编号列表,则表示所有的这些净荷

45、格式都可能在会话中用到,而第一个净荷格式是这个会话的默认格式。对于动态净荷类型的分配,应当使用“a-npmap:”属性来将一个RTP净荷类型编号映射到一个标识净荷格式的媒体编码名称。“a=fmtp:”可用来规定格式参数,见523节。如果是“udp”,则字段由协议指定。当注册新的传送协议时必须定义解释12YD厂r 1 936-2009的规则。523 SDP属性下面列出一些SDP的属性。因为应用编程人员在需要时可能会添加新的属性,所以下面列出来的并不是全部。(1)a=cat:这个属性给出了分级的会话类别,不同等级的类别由点分隔开来。这样可以使接收方通过类别过滤掉不期望的会话。它是一个会话级的属性,

46、它的值的解释并不依赖于“charset”。(2)a=keywds:与“cat”属性类似,这个属性有助于接收方标识期望的会话。接收方通过描述会话用途的关键字来选择感兴趣的会话。它是一个会话级的属性,依赖于“charset”,也就是说它的值用会话描述中规定的字符集(如果存在的话)来解释,如果未给出字符集,则默认采用ISO 10646UTF-8来解释。(3)a=tool:它给出了创建会话描述的工具的名称和版本号。它是一个会话级的属性,它的值的解释并不依赖于“charset”。(4)a=ptime:它给出了在一个分组包内的媒体的时间长度,单位是毫秒。它可能只对音频数据有意义,但也可能用在别的媒体类型中,只要认为这样做有意义。要想对RTP或vat音频解码,并没有必要知道prime,它是专门用于音频的编码和打包的。它是一个媒体级的属性,它的值的解释并不依赖于“charset”。(5)a=maxp

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 标准规范 > 行业标准 > YD通信行业

copyright@ 2008-2019 麦多课文库(www.mydoc123.com)网站版权所有
备案/许可证编号:苏ICP备17064731号-1