对媒体进行协商的方法、系统和发送媒体描述信息的方法

专利名称：对媒体进行协商的方法、系统和发送媒体描述信息的方法
技术领域：
本发明涉及多媒体技术，特别涉及一种对媒体进行协商的方法和系统以 及发送媒体描述信息的方法。
背景技术：
随着网络技术的不断发展和人们生活需求的不断提高，多媒体技术已经 成为通信技术中重要的部分。下面对现有的多媒体技术中涉及到的一些相关 协议和技术做简单的介绍。实时传输协议(RTP)是互联网工程任务组(IETF)制定的多媒体通信 协议之一，在请求注解(RFC) 1889中定义，通常与RTP控制协议(RTCP) 配合使用，为实时的音频、视频等数据提供端到端的传输功能。由多媒体应 用程序生成的音频和视频数据块被封装在RTP信息包中，每个RTP信息包 被封装在用户数据报协议(UDP)消息段中，然后再封装在网际协议(IP) 数据包中。可封装在RTP消息包中的音视频格式在RFC1890、 RFC 3551等 配置文件中声明，而对RTP传输过程的监听和控制由RTCP来完成。实时流协议(RTSP)是一个应用层协议，在RFC2326中定义，用于建 立和控制媒体的传输，它本身不参与媒体的传输，而是用于媒体服务器与用 户端的远程控制。RTSP具有易解析、可重用Web的安全机制、与传输层无 关的特性，通过与诸如RTP、资源预留协议(RSVP)等更低层的协议一起， 提供基于Internet的整套流化服务。会话描述协议(SDP)在RFC2327中定义，其作用是对多媒体会话的 内容进行描述。描述范围包括两部分其一是会话级，对整个多媒体会话进 行说明，如会话发起者信息、媒体连接地址、传输网络类型等；其二是媒体级，对该会话中可能存在的各个媒体进行描述，如媒体格式、传输参数、媒体连接地址等。通过使用RTP/音频视频配置(AVP )中的媒体格式声明RFC 3551以及SDP的提供/应答模型，SDP可在会话建立或/和更新的过程中完 成媒体参数的协商，为之后的媒体做好准备。下面举一个包括会话级和媒体级的描述行的SDP消息，表示如下 v=0o=- 2987933615 2987933615 IN IP6 5555::1:2:3:4 s=-c=IN IP6 5555:1:2:3:4t=907165275 0 〃前五行构成开头，v是版本号0， o是与会者标识，s为会话标题，c为连接属性，t为会话建立时间和时长， 面的0表示会话的结束标识为bye的发起。m=audio 3458 RTP/AVP 0 96 97 98a=rtpmap:0 PCMUa=rtpmap:96 G726-32/8000a=rtpmap:97 AMR-WBa=rtpmap:98tekphone-event 〃第一种流音频，端口 3458， RTP/AVP传输协议，编号0,96,97,98,分别表示PCMU， G,726和AMR语音编 码格式m=video 3400 RTP/AVP 99 101 a=rtpmap:99MPVa=rtpmap:101 H.261 〃第二种流视频，端口 3400， RTP/AVP传输，编号99， 101,分别表示MPEG1/MPEG2 Video和H.261编码格式m=video 3456 RTP/AVP 103 121a=sendonlya=rtpmap:103 H.261a=rtpmap:121 MPV 〃第三种流视频，端口 3456， RTP/AVP传输，编号103, 121,分别表示MPEG1/MPEG2 Video和H.261编码格式。上述消息的前5行是多媒体会话级的描述，包括消息发起者的相关信 息，会话信息，以及会话级的网络状况；后面是对支持的媒体类型的描述， 相关说明如下111=<媒体类型> <端口 > <传输协议> <格式列表>m行为媒体行，其中，媒体类型可以是音频(audio)、视频(video)、 应用程序(application)、数据(data)、控制程序(control)等；端口是多 媒体接收端口，若媒体使用分层编码和传输，则后面需要加上端口的个数； 传输协议可以是RTP/AVP、或者UDP;格式列表是该消息的发送者所能支 持的媒体格式，中间用空格分开。c = <网全各类型> <地址类型> <连接;也址>其中，网络类型，对于网络电视(IPTV)来说一般是因特网(IN); 地址类型可以是互联网协议版本4 (IPv4)或者互联网协议版本6 (IPv6); 连接地址为多媒体接收地址，对组播方式，地址后面应该有生存时间(TTL) 参数。如果组播源使用分层编码，则一个流可能出现多个组播地址，因此 TTL后面还可以有组播地址的个数说明，各项之间用"/，，分隔；单播方式 不允许使用"/"。3=<二进制属性>该二进制属性用于表明该属性是媒体特征之一，如a = recvonly,表明 该媒体只用于接收。3 = <属性类型>:<属性值>其中，属性类型是媒体属性行主要的扩展途径，可以有很多名称，如 定义媒体与属性值对应关系的属性类型(rtpmap)，定义媒体内部格式与属 性值对应关系的属性类型(fmtp)等；属性值是给该媒体属性指配的值，与 属性类型相关。a行统称为属性行，其中a-rtpmap行称为rtpmap属性行； a = fmtp行称为fmtp属性4亍。由上面示例可以看出，示例SDP消息描述了三个媒体，UDP端口 3459 上传输的是一个音频流，可选的方案为ia-律脉冲编码调制(PCMU)、国际电联音频编码标准G系列(G.726)、自适应多速率宽带编码标准(AMR-WB) 或者电话语音信号；端口 3400和3456分别传输一个视频流，其中端口 3456 仅用于视频流的发送，不接收对方发送来的媒体。为适应新的需求，往往需要对SDP协议进行扩展，最通用的扩展方法 为a行扩展，来定义新的媒体属性类型以及相关的属性值。例如a = des: qos和a:curr: qos行用于对会话两端的资源预留进行协商；a=fmtp: value 描述行用于对媒体格式进行更详细的说明，其描述的具体内容可以不被协议 所约束。会话初始化协议(SIP)是用于建立、改变或结束多媒体会话的应用层 协议，与SDP、 RTSP、域名系统(DNS)等协议的配合，共同完成会话建 立及媒体协商； 一旦建立会话，媒体将使用RTP在承栽层中直接传送，在 一次会话中可以灵活的交互多种4某体。由于SIP基于公开的Internet标准， 在语音、数据业务结合和互通方面具有很大优势，能跨越媒体和设备时限呼 叫控制，支持丰富的媒体格式，可动态增/删媒体，容易实现更加丰富的业 务特性，同时，SIP支持智能化业务和终端侧发展从而减轻网络负担，其本 身支持包括动态注册机制、位置管理机制、重定向机制等应用层移动性功能， 便于扩展新业务，而且协议简单，具有公认的扩展潜力，因此获得了包括在 IP多媒体子系统(IMS)及下一代通信网络(NGN)中的越来越多的应用。会话通告协议(SAP)是为了通知一个多播的多媒体会议或其它多播会 话而将相关的会话建立信息发送给所期望的会议参与者。SAP本身不建立会 话，它只是将建立会话所必要的信息，例如，所采取的视频或音频编码方式 通知给其它在一个多播内的参与者，当参与者收到该通知数据包后就可以启 动相应的工具并设置正确的参数向该会议的发起者建立会话了 。传输流(TS)是一种媒体封装格式，为实现多路运动图像专家组压缩 标准版本1 (MPEG-1 ) /运动图像专家组压缩标准版本2 (MPEG-2)的音视 频流在单个传输通道上传输，TS被设计为一种多路复用机制。TS是将多种 媒体成分进行打包封装在TS包中形成的媒体， 一个TS中可能有多种媒体成分，例如，可能包含音频、视频、以及数据。每一种媒体成分中可能有不同的格式，例如 一个TS中包含的视频可能是H.264格式和MPEG-2格式 的。相比单个媒体成分的媒体使用单独的RTP传输参数，在TS机制下，多 种媒体成分只占用一个通道，使用一套传输参数边可以传输，节省了网络中 的端口资源。在多媒体应用中，IETF制定了 一系列RFC规范来对于各种音频/视频编 码格式进行说明。并且，SDP通过与SIP、 SAP等其它协议配合，使用提供 /应答模型可以为这些媒体在网络上实现端到端的RTP传输提供一套交互机制。仍以上述例子进行说明，多媒体会话的一个SDP提供者可能发出一个 SDP提供消息(SDP offer)，包含如下内容 v=0o=- 2987933615 2987933615 IN IP6 5555::1:2:3:4 s=-c=IN IP6 5555:1:2:3:4 〃媒体接收地址t=907165275 0 〃 SDP头部，标识提供者的相关网络和时间信息m=audio 3458 RTP/AVP 0 96 97 98 a=rtpmap:0 PCMU a=rtpmap:96 G726-32/8000 a=rtpmap:97 AMR-WBa=rtpmap:98 telephone-event 〃第一个流用于语音交谈 m=video 3400 RTP/AVP 98 99 a=rtpmap:98 MPVa=rtpmap:99H.261 〃第二个流用于视频m=video 3456 RTP/AVP 98 99 a=sendonly a=rtpmap:98 H.261a=rtpmap:99 MPV 〃第三个流单向发送的视频流SDP应答者对该SDP offer中相关的媒体类型和属性进行分析，同时结合自身支持的媒体格式，返回一个SDP应答消息(SDP answer)来描述自10身对于SDP提供者提供的媒体的支持能力。针对上面的例子，该SDP answer可以是 v=0o=- 12357924 1357924 IN IP6 5555::5:6:7:8 s=-c=INIP6 5555:5:6:7:8t=907165275 0 〃 SDP头部，标识应答者的相关网络和时间信息m=audio 4011 RTP/AVP 96 97 98 a=rtpmap:96 G726-32/8000 a=rtpmap:97 AMR-WBa=rtpmap:98 telephone-event 〃第一个流用于语音交谈，不支持编码PCMU m=video 4012 RTP/AVP 99a=rtpmap:99 H.261 〃第二个流用于视频，不支持编码MPVm=video 0 RTP/AVP 98 〃第三个流UDP端口为0，表示不支持该视频流上面所述的SDP提供/应答模型要求SDP offer和SDP answer中的m行 数必须严格一致，也就是说，SDP应答者必须对SDP提供者提供的SDP offer 中的每个m行进行应答。然后，SDP提供者继续才艮据SDP answer 生成反映 SDP应答者支持的媒体的SDP offer,这种SDP提供/应答机制可以在多次 媒体协商过程中循环执行，直至协商成功或失败。由以上可以看出，现有技术已经给出了一种SDP交互机制，为各种已 经注册了多用途网络邮件扩展(MIME)类型的媒体格式提供了一种协商的 方法，但是对于多种媒体成分混装的媒体的协商并没有给出完整的解决方 案。发明内容有鉴于此，本发明的第一个目的在于，提供一种发送媒体描述信息的方 法，以便于对多种媒体成分混装的媒体描述信息进行发送。本发明的第二个目的在于，提供一种对媒体进行协商的方法，以便于对 多种媒体成分混装的媒体进行协商。本发明实施例的第三个目的在于，提供一种对媒体进行协商的系统，以 便于对多种媒体成分混装的媒体进行协商。本发明实施例的第四个目的在于，提供一种SDP提供者，以便于对多 种媒体成分混装的媒体进行协商。为了实现上述第 一个目的，本发明实施例提供了 一种发送媒体描述信息 的方法，该方法包括在会话描述协议SDP中，对多种媒体成分混装的媒 体表征信息进行描述，以及对多种媒体成分混装的媒体内部媒体成分进行描 述形成描述信息，发送该描述信息。为了实现上述第二个目的，本发明实施例提供了 一种对媒体进行协商的 方法，该方法包括SDP提供者对多种媒体成分混装的媒体进行描述，并将 包含描述信息的SDP提供消息SDP offer发送给SDP应答者；SDP应答者应答消息SDP answer;如果协商成功或失败，结束流程；如果没有协商成功 且没有协商失败，SDP提供者将根据该SDP answer重新生成SDP offer,循 环上述步骤，直至协商成功或失败。为了实现上述第三个目的，本发明实施例提供了 一种对媒体进行协商的系 统，该系统包括SDP提供者和SDP应答者；SDP提供者，对多种媒体成分混装的媒体进行描述，并将包含描述信息的 SDP offer发送给SDP应答者；如果没有协商成功且没有协商失败，SDP提供 者将根据该SDP answer重新生成SDP offer;SDP应答者，根据该SDP offer向SDP提供者返回反映SDP应答者端 设备媒体能力的SDP answer。为了实现上述第四个目的，本发明实施例提供了一种SDP提供者，该SDP 提供者包括描述单元、收发单元、以及判断单元；描述单元，对多种媒体成分混装的媒体进行描述，并将包含描述信息的SDP offer提供给收发单元；根据判断单元提供的SDP answer重新生成SDP offer提 供给收发单元；收发单元，将描述单元提供的SDP offer发送出去；接收SDP answer提供 给判断单元；判断单元，根据收发单元提供的SDP answer判断协商结果，如果没有协商 成功且没有协商失败，将该SDP answer提供给描述单元；由以上技术方案可以看出，本发明通过对多种媒体成分混装的媒体进行 外部的封装和内部媒体成分的描述，并且SDP提供者和SDP接收者使用该 描述方法分别发送SDP offer和SDP answer来对该多种内体成分混装的媒体 进行协商，以此，方便于实现多种媒体成分混装的媒体进行协商。


图1为本发明实施例提供的对媒体进行协商的方法流程图； 图2为本发明实施例提供的对媒体进行协商的系统结构图 图3为本发明实施例提供的SDP提供者的结构图。
具体实施方式
为了使本发明实施例的目的，技术方案、以及优点更加的清楚，下面结 合具体实施例对本发明进行详细描述。在一个多媒体会话中，双方需要就是否使用多种媒体成分混装的媒体作 为传输媒体进行协商。本发明实施例中使用SDP描述、以及SDP的提供/ 应答机制进行该协商过程。如图1所示，本发明实施例提供的对媒体进行协商的方法主要包括以下 步骤步骤101: SDP提供者对多种媒体成分混装的媒体进行描述，并生成包含该描述信息的SDP offer;步骤102: SDP提供者将所述SDP offer发送给SDP应答者步骤103: SDP应答者根据该SDP offer向SDP提供者返回反映SDP应答者端设备媒体能力的SDP answer;步骤104:如果协商成功或失败，结束流程；如果没有协商成功且没有 协商失败，SDP提供者根据返回的SDP answer重新生成SDP offer,循环执 行上述步骤102-104,直到协商成功或失败。其中，所述多种媒体成分混装的媒体为该媒体内部具有多种编解码配 置的々某体成分，例如，其内部的々某体成分可以包含；f见频、音频、应用程序、 数据等，视频可以是MPEG-2视频、H.264视频等，音频可以是MPEG-2音 频、AC-3音频等，或者是这些情况的组合。其中，所述SDP提供者可以是该媒体的发送方，可以是媒体的接收方， 也可以是知晓该媒体信息、和/或该媒体发送方或接收方能力的单独装置； SDP应答者可以是该媒体的接收方，可以是媒体的发送方，也可以是知晓该 媒体接收方或发送方能力的单独装置。该协商过程可以是在发送媒体前对所发送的媒体进行的协商，也可以是以SDP提供者描述媒体提供方提供的媒体，SDP应答者描述媒体接收方媒 体能力的协商过程为例。所述多种媒体成分混装的媒体可以是TS。SDP offer是对媒体提供者提供的多种媒体成分混装的媒体或者媒体提 供者的自身能力进行描述，该对多种媒体成分混装的媒体进行的描述主要包 :括两个方面I.对多种媒体成分混装的媒体表征信息进行描述，也就是对多种媒体成 分混装的媒体进行外部的封装，该表征信息是用来表征该媒体是由多种媒体 成分混装的媒体。在SDP offer中对该表征信息的描述可以使用 一个统一的标识符在m行或者rtpmap属性行中进行标识。例如，对于TS可以使用符号TS在a = rtpmap行中进行标识，该符号与其它已注册的MIME类型一样，可以被SDP协议接受。对该TS表征信息的描述语句如下 m=video port RTP/AVP nla=rtpmap:nl TS其中，port为接收该媒体成分的端口； nl是分配给该媒体的动态编码， 该分配在相关规范中已有说明，可以在RFC3551中查询。在m行对TS进行标识的方法可以是在RTP/AVP配置中将某个未被 使用的净荷类型(payload type )静态地指配给TS ，如29 ，则相关的TS表 征信息可描述如下m=video port RTP/AVP 29这种方法不需要使用媒体行后面的rtpmap属性行对29号媒体进行描 述，因为前面的编码nl是动态地指配，可以为任何注册了的MIME类型所 用，而29号已经被固定指配给TS 了 ，在媒体行即可将TS的表征信息描述 清楚。II.对多种媒体成分混装的媒体内部媒体成分进行描述。在SDP中可以 采用对fmtp属性行，即a = fmtp行进行扩展的形式，说明该多媒体内部的 媒体成分。fmtp属性行通常在对该媒体表征信息进行描述的媒体行或者rtpmap属性行后面。以TS流为例，其描述可以为m=video port RTP/AVP nl a-rtpmap:nl TS a=TS-description-1 [a=TS-description-21[a=TS-description-N]其中，方括号表示可选项，TS-description-x标识对TS的第x个fmtp 属性行。这N个fmtp属性行声明了该TS的全部或者部分媒体成分。 其中的fmtp属性行具体可以表述为a = fmtp: <MIME类型> <属性描述类型>=<属性值>[; <属性描述类型 >=<属性值>]其中的属性描述类型一般使用无空格的字符串；属性值可以是没有空格符的字符串或者数值，多个值的列表可以使用逗号隔开；[]表示该属性行可 以包含多个描述字段，之间使用分号和空格符隔开，该部分为可选项。 所述对fmtp属性行的扩展方式可以有以下几种 扩展方式一将该媒体的内部媒体成分进行分类，分别对各类进行描迷。 因为一个由多种媒体成分组成的媒体可能内部的封装有多种组合可能 既有音频、又有视频、还有数据；可能有多个音频、和/或视频；也可能包 含多个使用相同编解码的音频或视频等。所以可以将该媒体内部媒体成分分 类为音频类、视频类、数据类等，然后分别使用一个描述符进行说明。例 如,可以使用 video-description、 audeo-description、 data-description等作为 媒体描述类型；属性值可以使用当前可用的媒体成分的MIME类型。仍以TS为例，该TS内部媒体成分用codec 1、 codec2、 codec3.......codecM进行标识，不同i某体成分可能采用相同的编解码，其中，codec2和codecM为 两种音频格式，其它为视频格式，那么该内部媒体成分可以描述为m=video protl RTP/AVP nl a=rtpmap:nl TSa=fmtp:nl video-description=codecl, codec3，…，codecM; audio-description=codec2, codec4从上述例子中可以看出在使用这种扩展方式时，媒体内部的媒体成分在 a= fmtp行中都有体现，即使内部有些媒体成分采用相同的编解码，也同样 适用，比如，codecl和codec3都可以是MPEG - 2视频，其MIME类型为 MPV。另外，在本例子中没有data类型的数据，所以data-description字段为工。所述video-description、 audeo-description、 data-description等属性描述 类型只是一种符号，还可以使用其它字符串代替。属性值的选择也不仅局限 于RFC3551，新的在IANA注册的媒体格式、数据格式的MIME类型也可 以使用。在采用该扩展方式对该媒体内部媒体成分进行描述时，可以对上述fmtp 属性行的顺序进行限定，从而提高协商效率；也可以不对上述fmtp属性行 的顺序进行限定，这样种情况下的同一个媒体可能有多种描述形式，但其内 部的媒体成分是一样的，应该作为同一种媒体进行协商。这种扩展方式简洁明了 ，不过无法对各媒体成分的具体编解码参数详细 说明。扩展方式二依次对多种媒体成分封装的媒体内部的媒体成分单独进行 描述，而不分类别。仍然采用扩展方式一中的TS为例，该扩展方式的描述可以为m=video portl RTP/AVP nl a=rtpmap:nl TSa=fmtp:nl ts=codecl[，samplerate=90000，bitrate=32000，...];ts=codec2[，codec2的格式描述内 容];...ts=codecM[,codecM的格式描述内容]上述对该媒体各内部媒体成分的描述中至少要包含各媒体成分的 MIME类型，其它与该MIME类型相关的可选参数和/或必选参数以逗号方 式紧随其后。[]中为可选参数， 一般为各媒体成分的具体编解码参数，可以 为采样率(samplerate)或压缩比率(bitrate )等。与扩展方式一相似的，该扩展方式也可以对内部各媒体成分的描述行进 行排序，从而提高协商效率；也可以不进行排序。这种扩展方式更加灵活，可以将各个内部媒体成分描述的更加清楚详 细，但是会对SDP的消息体大小有所增加。扩展方式三仅描述媒体提供者所支持的媒体成分。这种扩展方式与扩展方式一类似，不同的是对于重复的MIME类型只 需描述 一 次。例如，codec 1和codec3是同样的MPEG-2视频，就可以进行 一次描述，例如a = fmtp:nl video-description=codec3，." ， codeM由以上可以看出，该扩展方式相比较扩展方式一更加简洁且实用。因为媒体只是多种媒体成分封装的方式，内部的媒体成分可以是任意多个，对其 一一描述往往不切实际，同时，如果媒体提供方或接收方能够对该媒体中的 一个媒体成分进行解码，当然也能对相同编码的其它媒体成分逐一解码，所 以对使用相同编解码的多个媒体成分只进行一次描述是可行的。以上所述三种扩展方式可以在fmtp属性行，即a-fmtp行内，对整个 媒体的内部媒体成分进行描述，以下几种扩展方式可以采用新增媒体属性符 的方法，所述新增的媒体属性符区别与fmtp:扩展方式四引用多个新的媒体属性符对媒体成分进行归类描述。仍以 上面例子进行说明，引入的新的々某体属性符可以是ts-video、 ts-audio、 ts-data 等，将TS内部的视频格式、音频格式、数据格式等进行分类描述，描述如 下m=video portl RTP/AVP nl a^pmap:nl TS a=ts-video:nl codecl codec3 ... a=ts-audio:nl codec2 ... codecM扩展方式五引用一个新的媒体属性符逐一对内部成分进行描述。上面 的例子可以描述如下m=video portl RTP/AVP nl a=rtpmap:nl TSa=ts:nl codecl [samplerate=90000] [bitrate=32000][...] a=ts:nl codec2 [对codec2的其他描述内容]a=ts:nl codecM [对codecM的其他描述内容]上面描述中[]部分为可选项，是对媒体成分编解码参数的详细描述，可 以是采样率或压缩比率等，其内容和格式可以使用RTP/AVP对编解码的描 述规范。 一个a-ts: nl行只描述一个编解码格式。上面所述的对媒体进行的描述可以用在对媒体进行协商过程中SDP提 供者在SDP offer中采用，也可以在媒体进行协商过程中SDP应答者在SDPanswer中提供，但一般情况下，同 一协商过程中的SDP offer和SDP answer 中采用的描述方式相同。另外，上述对媒体进行的描述也可以在HTTP、 RTSP等其它协议的一 些应用中使用，且并不是以提供/应答的交互机制出现，而是在客户端发起 请求后返回一个SDP消息，该SDP消息采用此描述方法来描述服务器端的 々某体能力。例如超文本链接标记语言(HTTP)的获取(GET)请求，以 及RTSP的描述(DESCRIBE )请求。下面以HTTP的GET请求和RTSP的 DESCRIBE请求为例进行说明当用户通过网络(WEB)界面向服务器请求媒体信息时，可能使用GET 请求。该GET请求中声明了对SDP协议的支持，如下GET /twister.sdp HTTP/1.1 Host: www.example.com Accept: application/sdp服务器对其返回的响应中，可以采用上述方法对用户将要获取媒体的具 体信息进行描述。以网络侧提供的媒体是TS为例，以上述扩展方式二对TS以及其内部的々某体成分进行描述如下HTTP/1.0 200 OK Date: 23 Jan 2006 15:35:06 GMT Content-Type: application/sdp Content-Length: 264 Expires: 23 Jan 1998 15:35:06 GMTv=0o=- 2890844526 2890842807 IN IP4 192.16.24.202 s=RTSP Session e=adm@example. com a=range:npt=0-l :49:34 t=0 0m=video 0 RTP/AVP 99 a=rtpmap:99 TSa=fmtp:99 ts=H264,profile-level-id=42A01E,packetization-mode=2; ts=MPV/90000;ts=AMR-WBa=control:rtsp://video.example.com/twister/video.ts该描述中，说明网络侧提供的媒体是TS封装的，TS内部有三种媒体成 分，分别是H.264视频、MPEG-2视频以及AMR-WB音频。在RTSP中，如终端向服务器请求媒体描述信息，则可以发起如下的 DESCRIBE请求DESCRIBE rtsp:〃video.example.cotn/concert/video.ts RTSP/2.0 CSeq: 1Supported: play.basic， play.scale对上述例子中所述媒体，服务器可以返回如下SDP消息RTSP/2.0 200 OK CSeq: 1Content-Type: application/sdp Content-Length: 182 Server: PhonyServer/1.0 Date: 23 Jan 1997 15:35:06 GMT Supported: play.basicv=0o=- 2890844526 2890842807 IN IP4 192.16.24.202s=RTSP Sessionm=video 3456 RTP/AVP 99c=IN IP4 224.2.0.1/16a=rtpmap:99 TSa=ts:99 H264 profile-level-id=42A01E packetization-mode=2 a=ts:99 MPV/90000 a=ts:99 AMR-WBa=control: rtsp:〃live.example.com/concert/video.ts由以上描述可以看出，上述对媒体进行的描述是针对一种媒体进行的， 也就是在SDP协商过程中的媒体仅有一种MIME类型；在对多种媒体，即 对应不同MIME类型的媒体时，可以直接4吏用通常的rtpmap属性行即可。 例^口 m=video 34568 RTP/AVP 102,104,111 a=rtpmap:102 TS扁H264-AC3 a=rtpmap:104 H264/90000 a=rtpmap:lll TS-H264-MPA该SDP消息描述了两种TS流内部由H.264视频和AC-3音频组成的 TS,对应的MIME类型是TS-H264-AC3;内部由H.264视频和MPEG-2 音频组成的TS，对应的MIME类型是TS-H264-MPA。上述这种对多种媒体进行描述不用对a行进行扩展，但是对每种媒体成 分的编解码组合都必须在相关配置中说明，并且无法对内部的媒体成分进行 更详细的描述。进行了上述对多种媒体成分混装的媒体进行描述的过程后，SDP提供者 将包含该描述信息的SDP offer发送给SDP应答者，SDP应答者根据该SDP offer向SDP提供者返回反映其媒体接收方媒体能力的SDP answer.所述SDP应答者根据该SDP offer向SDP提供者返回反映其媒体接收 方媒体能力的SDP answer为SDP应答者根据该媒体接收方的媒体能力对 SDP offer中的各个媒体行即m行进行确认，然后返回SDP answer。下面将对SDP应答者返回SDP answer的过程进行描述。根据该媒体接 收方的媒体能力该过程可以分为三种情况第一种情况该媒体接收方支持多种媒体成分混装的媒体的封装，同时 也支持该々某体内部所有々某体成分的编解码格式，则在SDP answer中使用相 同的m行和a行部分回应，只需要对UDP端口进行重新指配。在此以一个在SDP offer中描述了 TS类型，内部媒体成分有M个，分 另U是codecl， codec2，…，codecM，其中codec2和codecM为音步贞格式，其 它为视频格式为例，该SDP offer使用扩展a行的方法对该媒体的内部媒体 成分进行描述，如下m=video portl RTP/AVP nl a=rtpmap:nl TSa=TS-description<codexl， codec2，…，codecM>该例子中只使用一个a行对TS的内部媒体成分进行描迷。其描述方式 可以采用上面所述的几种对a行的扩展方式进行描述。在第一种情况下，SDP应答者使用相同的m行和a行对媒体接收者的 媒体能力进行描述，如下m=video port2 RTP/AVP n2 a=rtpmap:n2 TSa=TS-description<codexl, codec2,…，codecM>由上可以看出该SDP answer中的描述信息仅仅接收端口号port2和动态 分配的A VP编号n2与SDP offer中的描述信息不同，在完成此SDP answer 的发送后，此次对多种媒体成分混装的媒体的协商完成，媒体提供方和媒体 接收方可以使用内部codecl, codec2，…，codecM混装的TS流作为i某体传 输格式。上面所述第一种情况为协商成功。第二种情况:该媒体接收方支持多种媒体成分混装的媒体的封装，但是仅支持该媒体内部部分媒体成分的编解码格式，比如在上面所述例子中，媒 体接收方仅支持codec2，…，codecM封装的TS，但是不支持codecl的编 解码格式，则此时SDP应答者对该SDP offer返回如下SDP answer:m=video port2 RTP/AVP n2 a=rtpmap:n2 TSa=TS-description<codec2,…,codecM〉此时，SDP应答者仅在a行返回本端媒体接收方支持的媒体成分。 如杲该TS的提供方不支持对TS的解复用功能，则TS提供方和TS接22收方仍然不能使用该TS进行i某体传输。此时，双方可以对不同于TS的其 他媒体进行SDP协商，其协商方法属于现有技术，在此不做赘述。如果该TS的提供方支持对TS的解复用功能，则SDP提供者可以根据 收到的SDP answer重新生成SDP offer。此时的SDP offer可以仍然以TS流 为传输才各式，其内部々某体成分为codec2，…，codecM，这种方式只使用一 套传输参数即可进行TS的交流，节省了网络端口资源；SDP offer也可以对 m行进行拆分，分别传输不同的内部媒体成分，但这种方式会占用较多网络 端口资源。此时的SDP offer可以为m=audio port22 RTP/AVP n22 a=rtpmap:n22 codec2 m=video port23 RTP/AVP n23 a=rtpmap:n23 codec3m=audio port2M RTP/AVP n2M a=rtpmap:n2M codecM上述第二种情况中，如果SDP应答者端设备支持所述多种媒体成分混 装的媒体，但是不支持该媒体内部任何一种媒体成分时，协商失败。第三种情况该媒体接收方不支持多种媒体成分混装的媒体的封装。此 时，SDP应答者可以按照现有技术中的方法进行通常的SDP应答，将m行 的端口设为0。如果该媒体的接收方虽然不支持多种媒体成分混装的媒体的 封装，但是支持其中的几种媒体成分，那么可以通过SDP answer将该媒体 能力反映出来。仍以上面所述例子进行说明，若媒体接收者不支持TS的封 装，但是支持其中的codec 1视频，则SDP应答者返回的SDP answer可以是m=video port21 RTP/AVP n21 a=rtpmap:n21 codec 1如果媒体接收方同时支持音频codec2,则要看在SDP offer中有没有相应的m行对音频进行描述，如果有，则SDP answer也可以通过相应的m行 将codec2反映出来，具体如下 如杲SDP offer为m=video portl RTP/AVP nl a=rtpmap:nl TSa=TS-description<codecl， codec2，…,codecM〉 m=audio portl 1 RTP/AVP nl 1 a=rtpmap:nll codecX其SDP answer为m=video port21 RTP/AVP n21 a=rtpmap:n21 codec 1 m=audio port22 RTP/AVP n22 n23 a=rtpmap:n22 codecX a=rtpmap:n23 codec2SDP提供者接收到该SDP answer之后，可以根据收到的SDP answer重 新发起SDP offer对SDP应答者端的支持的媒体进行描述，循环执行上述步 骤，直至协商成功或失败。其中，重新发起的SDP offer可以没有对该TS 封装能力的描述，改为TS接收方支持的内部媒体成分的封装格式，或者另 外的单独的媒体的格式。上述第三种情况中，如果SDP应答者端设备不支持所述多种媒体成分 混装的媒体，也不支持该媒体内部任何一种媒体成分时，协商失败。行描述，SDP应答者通过SDP answer对该媒体接收方的媒体能力进行描述 为例进行的说明，该方法并不限于此，也同样适用于SDP提供者通过SDP offer对媒体接收方媒体能力进行描述，SDP应答者通过SDP answer对媒体 发送方媒体能力进行描述等情况。上述协商过程可以用于在SIP环境下对多种媒体成分混装的媒体进行的协商。在SIP会话建立过程中使用SDP提供/应答冲几制针对多种媒体成分 混装的媒体达成一致，如图3所示， 一个典型的SIP信令交互过程可以为以 下步骤步骤301:设备A向设备B发送SIP邀请消息(INVITE ); 步骤302:设备向设备A回应一个会话进行中的消息(183 Session In Progress );步骤303:设备A向设备B发送传输可靠性消息(PRACK ); 其中步骤302和步骤303主要用于对带宽和资源等的协商过程。 步骤304:设备B向设备A发送表征达成一致、会话建立的消息(200 OK);步骤305:设备A向设备B返回会话建立响应(ACK )。 在以上步骤中，对多种媒体成分封装的媒体进行协商时，设备A可以 作为SDP提供者，设备B作为SDP应答者，SDP offer在步骤301中初始的 INVITE中提供，此时SDP answer可以在步骤302中183 Session In Progress 中提供，也可以在步骤304中200 OK中提供；也可以为设备B作为SDP 提供者，设备A作为SDP应答者，此时SDP offer可以在在步骤302中183 Session In Progress中或在步骤304中200 OK中提供，SDP answer可以在在 步骤303中PRACK或在步骤305中ACK中提供。2所示，该系统包括SDP提供者201和SDP应答者202。SDP提供者201,对多种媒体成分混装的媒体进行描述，并将包含该描述信息的SDP offer发送给SDP应答者202;如果没有协商成功且没有协商失败，则根据SDP answer重新生成SDP offer;SDP应答者202，根据该SDP offer向SDP提供者201返回反映SDP应答者端设备媒体能力的SDP answer。其中，所述SDP提供者可以是该媒体的发送方，可以是媒体的接收方，也可以是知晓该媒体信息、和/或该媒体发送方或接收方媒体能力的单独装置。所述SDP应答者可以是该媒体的接收方，可以是媒体的发送方，也可 以是知晓该媒体接收方或发送方媒体能力的单独装置。SDP应答者和SDP提供者可以使用上述实施例提供的方法对多种媒体 成分混装的媒体进行描述或对多种媒体成分混装的媒体进行协商。下面对SDP提供者的结构进行详细的描述，如图3所示，该SDP提供者包 括描述单元301、收发单元302、以及判断单元303;描述单元301,对多种媒体成分混装的媒体进行描述，并将包含描述信息 的SDP offer提供给收发单元302;根据判断单元303提供的SDP answer重新 生成SDP offer提供给收发单元302;收发单元302,将描述单元301提供的SDP offer发送出去；接收SDP answer 提供给判断单元303;判断单元303，根据收发单元302提供的SDP answer判断协商结果， 如果没有协商成功且没有协商失败，将该SDP answer提供给描述单元301。SDP提供者可以为所述媒体的发送方、或所述媒体的接收方、或知晓所 述媒体信息、和/或媒体发送方媒体能力的单独装置。判断模块获取的SDP answer中如果有对所述媒体的表征信息进行的描述又 有对所述4某体的所有内部媒体成分进行的描述，则判断协商成功；所述判断模块获取的SDP answer中如杲没有对所述媒体的内部媒体成 分进行的描述，则判断协商失败。由以上描述可以看出，在本发明实施例所提供的方法和系统中，SDP 提供者对多种媒体成分混装的媒体进行描述，并将包含该描述信息的SDP offer发送给SDP应答者，SDP应答者根据该SDP offer向SDP提供者返回 反映其本端媒体能力的SDP answer;如果没有协商成功且没有协商失败， SDP提供者将4艮据该SDP answer重新生成SDP offer,循环上述步骤，直至 协商成功或失败。由此，通过对多种媒体成分混装的媒体进行外部的封装和 内部媒体成分的描述，方便于实现对多种媒体成分混装的媒体进行协商。以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本 发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在 本发明保护的范围之内。
权利要求
1. 一种发送媒体描述信息的方法，其特征在于，该方法包括在会话描述协议SDP中，对多种媒体成分混装的媒体表征信息进行描述，以及对多种媒体成分混装的媒体内部媒体成分进行描述形成描述信息后，发送该描述信息。
2、 根据权利要求1所述的方法，其特征在于，所述对多种媒体成分混装的 媒体表征信息进行描述为在SDP中使用一个统一的标识符在媒体或rtpmap 属性行进行标识。
3、 根据权利要求1所述的方法，其特征在于，所述多种媒体成分混装的媒 体为多个时，所述对多种媒体成分混装的媒体表征信息进行描述为在SDP中 采用多个rtpmap属性行分别使用不同标识符、或者采用多个m行分别使用不 同标识符进行所述对多种媒体成分混装的媒体表征信息进行描述。
4、 根据权利要求1所述的方法，其特征在于，所述对多种媒体成分混装的 媒体内部媒体成分进行描述为在SDP中采用对fintp属性行进行扩展的形式、 或者采用在属性行新增属性符的形式对所述多种媒体成分混装的媒体内部媒体 成分进行描述。
5、 根据权利要求4所述的方法，其特征在于，所述对fintp属性行进行扩 展为将所述媒体的内部媒体成分进行分类，在fmtp属性行中分别对各类进行 描述，或者在fintp属性行中逐一对所述媒体内部的媒体成分单独进行描述，或者 在fintp属性行中仅描述本端设备支持的所述媒体内部媒体成分。
6、 根据权利要求4所述的方法，其特征在于，所述在属性行新增属性符的 形式为在属性行中引用多个新的属性符对所述^^某体内部^ 某体成分进行归类描 述，或者在属性行中引用 一个新的媒体属性符逐一对所述媒体内部媒体成分编解码 参数进行描述。
7、 根据权利要求1所述的方法，其特征在于，所述多种媒体成分混装的媒
8、 一种对媒体进行协商的方法，其特征在于，该方法包括以下步骤A、 SDP提供者对多种媒体成分混装的媒体进行描述，并生成包含描述信 息的SDP提供消息SDP offer;B、 SDP提供者将所述SDP Offer发送给SDP应答者；C、 SDP应答者根据该SDP offer向SDP提供者返回反映SDP应答者端设 备々某体能力的SDP应答消息SDP answer;D、 如果协商成功或失败，结束流程；如果没有协商成功且没有协商失败， SDP提供者将根据该SDP answer重新生成SDP offer,并循环执行步骤B、 C和 D,直至协商成功或失败。
9、 根据权利要求8所述的方法，其特征在于，步骤A中所述SDP提供者 对多种媒体成分混装的媒体进行描述为SDP提供者对其本端设备所提供或接 收的多种媒体成分混装的媒体进行描述，或者SDP提供者对其本端设备的媒体 能力进行描述。
10、 根据权利要求8所述的方法，其特征在于，步骤C中所述SDP应答 者根据所述SDP offer向SDP提供者返回反映SDP应答者端设备媒体能力的 SDP answer为当SDP应答者端设备支持该SDP offer所描述的多种媒体成分 混装的媒体的封装，同时也支持该媒体内部所有媒体成分的编解码格式时，SDP 应答者在SDP answer中使用与SDP offer对应的媒体行对所述媒体的表征信息 进行描述、在属性行对所述媒体的所有内部媒体成分进行描述，对用户数据报 协议UDP端口进行重新指配；当SDP应答者端设备支持多种媒体成分混装的媒体的封装，并且仅支持该 媒体内部部分々某体成分的编解码格式时，SDP应答者仅在SDP answer中的属性 行对SDP应答者端设备支持的所述部分媒体成分进行描述；当SDP应答者端设备不支持多种媒体成分混装的媒体的封装时，SDP应答 者在SDP answer中的媒体行中不包含所述混装媒体的表征信息，或仅在属性行 对所述媒体的内部媒体成分中SDP应答者端设备支持的媒体成分进行描述；当SDP应答者端设备不支持该多种媒体成分混装的媒体内部媒体成分的任 意一种时，SDP应答者在SDP answer中不对所述媒体内部々某体成分进行描述。
11、 根据权利要求IO所述的方法，其特征在于，所述协商成功为SDP应 答者端设备支持多种媒体成分混装的媒体的封装，同时也支持该媒体内部所有 媒体成分的编解码格式；所述协商失败为SDP应答者端设备不支持所述多种々某体成分混装的^(某体 的所有内部J 某体成分；步骤D中所述SDP提供者将根据该SDP answer重新生成SDP offer为SDP 提供者重新对SDP answer中反映的媒体能力的媒体进行描述生成SDPoffer。
12、 根据权利要求8所述的方法，其特征在于，所述多种媒体成分混装的 媒体是TS。
13、 一种对媒体进行协商的系统，其特征在于，该系统包括SDP提供者 和SDP应答者；SDP提供者，对多种媒体成分混装的媒体进行描述，并将包含描述信息的 SDP offer发送给SDP应答者；如杲没有协商成功且没有协商失败，SDP提供 者将根据该SDP answer重新生成SDP offer;SDP应答者，根据该SDP offer向SDP提供者返回反映SDP应答者端设备 々某体能力的SDP answer。
14、 根据权利要求13所述的系统，其特征在于，所述SDP提供者是所述 媒体的发送方，所述SDP应答者是所述4某体的接收方，所述SDP应答者端设 备为所述媒体的接收方；或者所述SDP提供者是所述媒体的接收方，所述SDP应答者是所述媒体的发送 方，所述SDP应答者端设备为所述媒体的发送方；或者所述SDP提供者是知晓所述媒体信息、和/或媒体发送方媒体能力的单独装 置，所述SDP应答者是知晓所述媒体接收方媒体能力的单独装置，所述SDP 应答者端设备为所述媒体接收方。
15、 根据权利要求13所述的系统，其特征在于，所述SDP提供者接收到的SDP answer 中如果有对所述i某体的表征信息进行的描述又有对所述媒体的 所有内部媒体成分进行的描述，则判断协商成功；所述SDP提供者接收到的SDP answer中如果没有对所述媒体的内部媒体成分进行的描述，则判断协商失败。
16、 一种SDP提供者，其特征在于，该SDP提供者包括描述单元、收发 单元、以及判断单元；描述单元，对多种媒体成分混装的媒体进行描述，并将包含描述信息的SDP offer提供给收发单元；根据判断单元提供的SDP answer重新生成SDP offer提 供给收发单元；收发单元，将描述单元提供的SDP offer发送出去；接收SDP answer提供给判断单元；判断单元，根据收发单元提供的SDP answer判断协商结果，如果没有协商 成功且没有协商失败，将该SDP answer提供给描述单元。
17、 根据权利要求16所述的SDP提供者，其特征在于，所述SDP提供者 为所述媒体的发送方、或所述媒体的接收方、或知晓所述媒体信息、和/或媒体 发送方媒体能力的单独装置。
18、 根据权利要求16所述的SDP提供者，其特征在于，所述判断模块获 取的SDP answer中如果有对所述i某体的表征信息进行的描述又有对所述Jf某体 的所有内部媒体成分进行的描述，则判断协商成功；所述判断模块获取的SDP answer中如果没有对所述媒体的内部媒体成分进 行的描述，则判断协商失败。
全文摘要
本发明提供了一种对媒体进行协商的方法和系统、发送媒体描述信息的方法以及会话描述协议(SDP)提供者，SDP提供者对多种媒体成分混装的媒体进行描述，并将包含该描述信息的SDP提供消息(SDP offer)发送给SDP应答者，SDP应答者根据该SDP offer向SDP提供者返回反映SDP提供者端设备媒体能力的SDP应答消息(SDP answer)，如果没有协商成功且没有协商失败，SDP提供者将根据该SDP answer重新生成SDP offer，循环上述步骤，直至协商成功或者协商失败。在协商和描述过程中，通过对多种媒体成分混装的表征信息和内部媒体成分的描述，方便于实现对多种媒体成分混装的媒体进行协商。
文档编号H04L29/06GK101247388SQ200710080258
公开日2008年8月20日 申请日期2007年2月15日 优先权日2007年2月15日
发明者朱文明, 丰 王 申请人:华为技术有限公司