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

Abstract

本发明提供了一种对媒体进行协商的方法和系统、发送媒体描述信息的方法以及会话描述协议(SDP)提供者，SDP提供者对多种媒体成分混装的媒体进行描述，并将包含该描述信息的SDP提供消息(SDP offer)发送给SDP应答者，SDP应答者根据该SDP offer向SDP提供者返回反映SDP提供者端设备媒体能力的SDP应答消息(SDP answer)，如果没有协商成功且没有协商失败，SDP提供者将根据该SDP answer重新生成SDP offer，循环上述步骤，直至协商成功或者协商失败。在协商和描述过程中，通过对多种媒体成分混装的表征信息和内部媒体成分的描述，方便于实现对多种媒体成分混装的媒体进行协商。

Description

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

技术领域

本发明涉及多媒体技术，特别涉及一种对媒体进行协商的方法和系统以及发送媒体描述信息的方法。

背景技术

随着网络技术的不断发展和人们生活需求的不断提高，多媒体技术已经成为通信技术中重要的部分。下面对现有的多媒体技术中涉及到的一些相关协议和技术做简单的介绍。

实时传输协议(RTP)是互联网工程任务组(IETF)制定的多媒体通信协议之一，在请求注解(RFC)1889中定义，通常与RTP控制协议(RTCP)配合使用，为实时的音频、视频等数据提供端到端的传输功能。由多媒体应用程序生成的音频和视频数据块被封装在RTP信息包中，每个RTP信息包被封装在用户数据报协议(UDP)消息段中，然后再封装在网际协议(IP)数据包中。可封装在RTP消息包中的音视频格式在RFC 1890、RFC 3551等配置文件中声明，而对RTP传输过程的监听和控制由RTCP来完成。

实时流协议(RTSP)是一个应用层协议，在RFC2326中定义，用于建立和控制媒体的传输，它本身不参与媒体的传输，而是用于媒体服务器与用户端的远程控制。RTSP具有易解析、可重用Web的安全机制、与传输层无关的特性，通过与诸如RTP、资源预留协议(RSVP)等更低层的协议一起，提供基于Internet的整套流化服务。

会话描述协议(SDP)在RFC2327中定义，其作用是对多媒体会话的内容进行描述。描述范围包括两部分：其一是会话级，对整个多媒体会话进行说明，如会话发起者信息、媒体连接地址、传输网络类型等；其二是媒体级，对该会话中可能存在的各个媒体进行描述，如媒体格式、传输参数、媒体连接地址等。通过使用RTP/音频视频配置(AVP)中的媒体格式声明RFC3551以及SDP的提供/应答模型，SDP可在会话建立或/和更新的过程中完成媒体参数的协商，为之后的媒体做好准备。

下面举一个包括会话级和媒体级的描述行的SDP消息，表示如下：

v＝0

o＝-29879336152987933615 IN IP6 5555::1:2:3:4

s＝-

c＝IN IP6 5555:1:2:3:4

t＝9071652750               //前五行构成开头，v是版本号0，o是与会者标识，s

                            为会话标题，c为连接属性，t为会话建立时间和时长，

                            面的0表示会话的结束标识为bye的发起。

m＝audio 3458RTP/AVP 0 96 97 98

a＝rtpmap:0 PCMU

a＝rtpmap:96G726-32/8000

a＝rtpmap:97AMR-WB

a＝rtpmap:98telephone-event  //第一种流：音频，端口3458，RTP/AVP传输协议，编

                             号0，96，97，98，分别表示PCMU，G.726和AMR语音编

                             码格式

m＝video 3400RTP/AVP 99 101

a＝rtpmap:99MPV

a＝rtpmap:101H.261           //第二种流：视频，端口3400，RTP/AVP传输，编号

                             99，101，分别表示MPEG1/MPEG2 Video和H.261编

                             码格式

m＝video 3456 RTP/AVP 103 121

a＝sendonly

a＝rtpmap:103H.261

a＝rtpmap:121MPV             //第三种流：视频，端口3456，RTP/AVP传输，编号

                             103，121，分别表示MPEG1/MPEG2 Video和H.261

                             编码格式。

上述消息的前5行是多媒体会话级的描述，包括消息发起者的相关信息，会话信息，以及会话级的网络状况；后面是对支持的媒体类型的描述，相关说明如下：

m＝<媒体类型><端口><传输协议><格式列表>

m行为媒体行，其中，媒体类型可以是音频(audio)、视频(video)、应用程序(application)、数据(data)、控制程序(control)等；端口是多媒体接收端口，若媒体使用分层编码和传输，则后面需要加上端口的个数；传输协议可以是RTP/AVP、或者UDP；格式列表是该消息的发送者所能支持的媒体格式，中间用空格分开。

c＝<网络类型><地址类型><连接地址>

其中，网络类型，对于网络电视(IPTV)来说一般是因特网(IN)；地址类型可以是互联网协议版本4(IPv4)或者互联网协议版本6(IPv6)；连接地址为多媒体接收地址，对组播方式，地址后面应该有生存时间(TTL)参数。如果组播源使用分层编码，则一个流可能出现多个组播地址，因此TTL后面还可以有组播地址的个数说明，各项之间用“/”分隔；单播方式不允许使用“/”。

a＝<二进制属性>

该二进制属性用于表明该属性是媒体特征之一，如：a＝recvonly，表明该媒体只用于接收。

a＝<属性类型>：<属性值>

其中，属性类型是媒体属性行主要的扩展途径，可以有很多名称，如：定义媒体与属性值对应关系的属性类型(rtpmap)，定义媒体内部格式与属性值对应关系的属性类型(fmtp)等；属性值是给该媒体属性指配的值，与属性类型相关。a行统称为属性行，其中a＝rtpmap行称为rtpmap属性行；a＝fmtp行称为fmtp属性行。

由上面示例可以看出，示例SDP消息描述了三个媒体，UDP端口3459上传输的是一个音频流，可选的方案为μ-律脉冲编码调制(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在承载层中直接传送，在一次会话中可以灵活的交互多种媒体。由于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＝0

o＝-29879336152987933615 IN IP6 5555::1:2:3:4

s＝-

c＝IN IP6 5555:1:2:3:4         //媒体接收地址

t＝9071652750                  //SDP头部，标识提供者的相关网络和时间信息

m＝audio 3458RTP/AVP 0 96 97 98

a＝rtpmap:0PCMU

a＝rtpmap:96G726-32/8000

a＝rtpmap:97AMR-WB

a＝rtpmap:98telephone-event    //第一个流：用于语音交谈

m＝video 3400RTP/AVP 98 99

a＝rtpmap:98MPV

a＝rtpmap:99H.261              //第二个流：用于视频

m＝video 3456 RTP/AVP 98 99

a＝sendonly

a＝rtpmap:98H.261

a＝rtpmap:99MPV                //第三个流：单向发送的视频流

SDP应答者对该SDP offer中相关的媒体类型和属性进行分析，同时结合自身支持的媒体格式，返回一个SDP应答消息(SDP answer)来描述自身对于SDP提供者提供的媒体的支持能力。针对上面的例子，该SDP answer可以是：

v＝0

o＝-123579241357924 IN IP6 5555::5:6:7:8

s＝-

c＝IN IP6 5555:5:6:7:8

t＝9071652750                  //SDP头部，标识应答者的相关网络和时间信息

m＝audio 4011RTP/AVP 96 97 98

a＝rtpmap:96G726-32/8000

a＝rtpmap:97AMR-WB

a＝rtpmap:98telephone-event    //第一个流：用于语音交谈，不支持编码PCMU

m＝video 4012RTP/AVP 99

a＝rtpmap:99H.261              //第二个流：用于视频，不支持编码MPV

m＝video 0RTP/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 offer向SDP提供者返回反映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提供者包括：描述单元、收发单元、以及判断单元；

描述单元，对多种媒体成分混装的媒体进行描述，并将包含描述信息的SDPoffer提供给收发单元；根据判断单元提供的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，直到协商成功或失败。

其中，所述多种媒体成分混装的媒体为：该媒体内部具有多种编解码配置的媒体成分，例如，其内部的媒体成分可以包含：视频、音频、应用程序、数据等，视频可以是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 n1

a＝rtpmap:n1 TS

其中，port为接收该媒体成分的端口；n1是分配给该媒体的动态编码，该分配在相关规范中已有说明，可以在RFC3551中查询。

在m行对TS进行标识的方法可以是：在RTP/AVP配置中将某个未被使用的净荷类型(payload type)静态地指配给TS，如29，则相关的TS表征信息可描述如下：

...

m＝video port RTP/AVP 29

...

这种方法不需要使用媒体行后面的rtpmap属性行对29号媒体进行描述，因为前面的编码n1是动态地指配，可以为任何注册了的MIME类型所用，而29号已经被固定指配给TS了，在媒体行即可将TS的表征信息描述清楚。

II.对多种媒体成分混装的媒体内部媒体成分进行描述。在SDP中可以采用对fmtp属性行，即a＝fmtp行进行扩展的形式，说明该多媒体内部的媒体成分。fmtp属性行通常在对该媒体表征信息进行描述的媒体行或者rtpmap属性行后面。以TS流为例，其描述可以为：

m＝video port RTP/AVP n1

a＝rtpmap:n1 TS

a＝TS-description-1

[a＝TS-description-2]

......

[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内部媒体成分用codec1、codec2、codec3、......codecM进行标识，不同媒体成分可能采用相同的编解码，其中，codec2和codecM为两种音频格式，其它为视频格式，那么该内部媒体成分可以描述为：

...

m＝video prot 1RTP/AVP n1

a＝rtpmap:n 1TS

a＝fmtp:n1video-description＝codec1，codec3，...，codecM；audio-description＝codec2，codec4

...

从上述例子中可以看出在使用这种扩展方式时，媒体内部的媒体成分在a＝fmtp行中都有体现，即使内部有些媒体成分采用相同的编解码，也同样适用，比如，codec1和codec3都可以是MPEG-2视频，其MIME类型为MPV。

另外，在本例子中没有data类型的数据，所以data-description字段为空。

所述video-description、audeo-description、data-description等属性描述类型只是一种符号，还可以使用其它字符串代替。属性值的选择也不仅局限于RFC3551，新的在IANA注册的媒体格式、数据格式的MIME类型也可以使用。

在采用该扩展方式对该媒体内部媒体成分进行描述时，可以对上述fmtp属性行的顺序进行限定，从而提高协商效率；也可以不对上述fmtp属性行的顺序进行限定，这样种情况下的同一个媒体可能有多种描述形式，但其内部的媒体成分是一样的，应该作为同一种媒体进行协商。

这种扩展方式简洁明了，不过无法对各媒体成分的具体编解码参数详细说明。

扩展方式二：依次对多种媒体成分封装的媒体内部的媒体成分单独进行描述，而不分类别。

仍然采用扩展方式一中的TS为例，该扩展方式的描述可以为：

m＝video port1 RTP/AVP n1

a＝rtpmap:n1 TS

a＝fmtp:n1 ts＝codec1[，samplerate＝90000，bitrate＝32000，...]；ts＝codec2[，codec2的格式描述内容]；...ts＝codecM[，codecM的格式描述内容]

上述对该媒体各内部媒体成分的描述中至少要包含各媒体成分的MIME类型，其它与该MIME类型相关的可选参数和/或必选参数以逗号方式紧随其后。[]中为可选参数，一般为各媒体成分的具体编解码参数，可以为采样率(samplerate)或压缩比率(bitrate)等。

与扩展方式一相似的，该扩展方式也可以对内部各媒体成分的描述行进行排序，从而提高协商效率；也可以不进行排序。

这种扩展方式更加灵活，可以将各个内部媒体成分描述的更加清楚详细，但是会对SDP的消息体大小有所增加。

扩展方式三：仅描述媒体提供者所支持的媒体成分。

这种扩展方式与扩展方式一类似，不同的是对于重复的MIME类型只需描述一次。例如，codec1和codec3是同样的MPEG-2视频，就可以进行一次描述，例如：

a＝fmtp:n1 video-description＝codec3，...，codeM

由以上可以看出，该扩展方式相比较扩展方式一更加简洁且实用。因为媒体只是多种媒体成分封装的方式，内部的媒体成分可以是任意多个，对其一一描述往往不切实际，同时，如果媒体提供方或接收方能够对该媒体中的一个媒体成分进行解码，当然也能对相同编码的其它媒体成分逐一解码，所以对使用相同编解码的多个媒体成分只进行一次描述是可行的。

以上所述三种扩展方式可以在fmtp属性行，即a＝fmtp行内，对整个媒体的内部媒体成分进行描述，以下几种扩展方式可以采用新增媒体属性符的方法，所述新增的媒体属性符区别与fmtp：

扩展方式四：引用多个新的媒体属性符对媒体成分进行归类描述。仍以上面例子进行说明，引入的新的媒体属性符可以是ts-video、ts-audio、ts-data等，将TS内部的视频格式、音频格式、数据格式等进行分类描述，描述如下：

m＝video port1 RTP/AVP n1

a＝rtpmap:n1 TS

a＝ts-video:n 1codec1 codec3...

a＝ts-audio:n1codec2...codecM

......

扩展方式五：引用一个新的媒体属性符逐一对内部成分进行描述。上面的例子可以描述如下：

m＝video port1 RTP/AVP n1

a＝rtpmap:n1 TS

a＝ts:n1codec1[samplerate＝90000][bitrate＝32000][...]

a＝ts:n1codec2[对codec2的其他描述内容]

......

a＝ts:n1codecM[对codecM的其他描述内容]

上面描述中[]部分为可选项，是对媒体成分编解码参数的详细描述，可以是采样率或压缩比率等，其内容和格式可以使用RTP/AVP对编解码的描述规范。一个a＝ts：n1行只描述一个编解码格式。

上面所述的对媒体进行的描述可以用在对媒体进行协商过程中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.0200 OK

 Date：23Jan 200615:35:06GMT

 Content-Type：application/sdp

 Content-Length：264

 Expires：23Jan 199815:35:06GMT

 v＝0

 o＝-28908445262890842807IN IP4192.16.24.202

 s＝RTSP Session

 e＝adm@example.com

 a＝range:npt＝0-1:49:34

 t＝00

 m＝video 0RTP/AVP 99

a＝rtpmap:99TS

a＝fmtp:99ts＝H264，profile-level-id＝42A01E，packetization-mode＝2；ts＝MPV/90000；

ts＝AMR-WB

a＝control:rtsp://video.example.com/twister/video.ts

该描述中，说明网络侧提供的媒体是TS封装的，TS内部有三种媒体成分，分别是H.264视频、MPEG-2视频以及AMR-WB音频。

在RTSP中，如终端向服务器请求媒体描述信息，则可以发起如下的DESCRIBE请求：

DESCRIBE rtsp://video.example.com/concert/video.ts RTSP/2.0

 CSeq：1

 Supported：play.basic，play.scale

对上述例子中所述媒体，服务器可以返回如下SDP消息：

RTSP/2.0200 OK

 CSeq：1

 Content-Type：application/sdp

 Content-Length：182

 Server：PhonyServer/1.0

 Date：23Jan 199715:35:06GMT

 Supported：play.basic

 v＝0

 o＝-28908445262890842807 IN IP4192.16.24.202

 s＝RTSP Session

 m＝video 3456RTP/AVP 99

 c＝IN IP4224.2.0.1/16

 a＝rtpmap:99TS

 a＝ts:99H264profile-level-id＝42A01E packetization-mode＝2

 a＝ts:99MPV/90000

 a＝ts:99AMR-WB

 a＝control:rtsp://live.example.com/concert/video.ts

由以上描述可以看出，上述对媒体进行的描述是针对一种媒体进行的，也就是在SDP协商过程中的媒体仅有一种MIME类型；在对多种媒体，即对应不同MIME类型的媒体时，可以直接使用通常的rtpmap属性行即可。例如：

...

m＝video 34568RTP/AVP 102，104，111

a＝rtpmap:102TS-H264-AC3

a＝rtpmap:104H264/90000

a＝rtpmap:111TS-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应答者根据该SDPoffer向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个，分别是codec1，codec2，...，codecM，其中codec2和codecM为音频格式，其它为视频格式为例，该SDP offer使用扩展a行的方法对该媒体的内部媒体成分进行描述，如下：

……

m＝video port1 RTP/AVP n1

a＝rtpmap:n1 TS

a＝TS-description<codex1，codec2，...，codecM>

......

该例子中只使用一个a行对TS的内部媒体成分进行描述。其描述方式可以采用上面所述的几种对a行的扩展方式进行描述。

在第一种情况下，SDP应答者使用相同的m行和a行对媒体接收者的媒体能力进行描述，如下：

......

m＝video port2RTP/AVP n2

a＝rtpmap:n2TS

a＝TS-description<codex1，codec2，...，codecM>

......

由上可以看出该SDP answer中的描述信息仅仅接收端口号port2和动态分配的AVP编号n2与SDP offer中的描述信息不同，在完成此SDP answer的发送后，此次对多种媒体成分混装的媒体的协商完成，媒体提供方和媒体接收方可以使用内部codec1，codec2，...，codecM混装的TS流作为媒体传输格式。

上面所述第一种情况为协商成功。

第二种情况：该媒体接收方支持多种媒体成分混装的媒体的封装，但是仅支持该媒体内部部分媒体成分的编解码格式，比如在上面所述例子中，媒体接收方仅支持codec2，...，codecM封装的TS，但是不支持codec1的编解码格式，则此时SDP应答者对该SDP offer返回如下SDP answer：

......

m＝video port2RTP/AVP n2

a＝rtpmap:n2TS

a＝TS-description<codec2，...，codecM>

......

此时，SDP应答者仅在a行返回本端媒体接收方支持的媒体成分。

如果该TS的提供方不支持对TS的解复用功能，则TS提供方和TS接收方仍然不能使用该TS进行媒体传输。此时，双方可以对不同于TS的其他媒体进行SDP协商，其协商方法属于现有技术，在此不做赘述。

如果该TS的提供方支持对TS的解复用功能，则SDP提供者可以根据收到的SDP answer重新生成SDP offer。此时的SDP offer可以仍然以TS流为传输格式，其内部媒体成分为codec2，...，codecM，这种方式只使用一套传输参数即可进行TS的交流，节省了网络端口资源；SDP offer也可以对m行进行拆分，分别传输不同的内部媒体成分，但这种方式会占用较多网络端口资源。此时的SDP offer可以为：

......

m＝audio port22RTP/AVP n22

a＝rtpmap:n22codec2

m＝video port23RTP/AVP n23

a＝rtpmap:n23codec3

......

m＝audio port2M RTP/AVP n2M

a＝rtpmap:n2M codecM

......

上述第二种情况中，如果SDP应答者端设备支持所述多种媒体成分混装的媒体，但是不支持该媒体内部任何一种媒体成分时，协商失败。

第三种情况：该媒体接收方不支持多种媒体成分混装的媒体的封装。此时，SDP应答者可以按照现有技术中的方法进行通常的SDP应答，将m行的端口设为0。如果该媒体的接收方虽然不支持多种媒体成分混装的媒体的封装，但是支持其中的几种媒体成分，那么可以通过SDP answer将该媒体能力反映出来。仍以上面所述例子进行说明，若媒体接收者不支持TS的封装，但是支持其中的codec1视频，则SDP应答者返回的SDP answer可以是：

......

m＝video port21RTP/AVP n21

a＝rtpmap:n21codec 1

......

如果媒体接收方同时支持音频codec2，则要看在SDP offer中有没有相应的m行对音频进行描述，如果有，则SDP answer也可以通过相应的m行将codec2反映出来，具体如下：

如果SDP offer为：

......

m＝video port1RTP/AVP n1

a＝rtpmap:n1 TS

a＝TS-description<codec 1，codec2，...，codecM>

m＝audio port11RTP/AVP n11

a＝rtpmap:n 11codecX

......

其SDP answer为：

......

m＝video port21RTP/AVP n21

a＝rtpmap:n21 codec 1

m＝audio port22RTP/AVP n22n23

a＝rtpmap:n22codecX

a＝rtpmap:n23codec2

SDP提供者接收到该SDP answer之后，可以根据收到的SDP answer重新发起SDP offer对SDP应答者端的支持的媒体进行描述，循环执行上述步骤，直至协商成功或失败。其中，重新发起的SDP offer可以没有对该TS封装能力的描述，改为TS接收方支持的内部媒体成分的封装格式，或者另外的单独的媒体的格式。

上述第三种情况中，如果SDP应答者端设备不支持所述多种媒体成分混装的媒体，也不支持该媒体内部任何一种媒体成分时，协商失败。

以上描述均是以SDP提供者通过SDP offer对媒体发送方发送的媒体进行描述，SDP应答者通过SDP answer对该媒体接收方的媒体能力进行描述为例进行的说明，该方法并不限于此，也同样适用于SDP提供者通过SDPoffer对媒体接收方媒体能力进行描述，SDP应答者通过SDP answer对媒体发送方媒体能力进行描述等情况。

上述协商过程可以用于在SIP环境下对多种媒体成分混装的媒体进行的协商。在SIP会话建立过程中使用SDP提供/应答机制针对多种媒体成分混装的媒体达成一致，如图3所示，一个典型的SIP信令交互过程可以为以下步骤：

步骤301：设备A向设备B发送SIP邀请消息(INVITE)；

步骤302：设备向设备A回应一个会话进行中的消息(183 Session InProgress)；

步骤303：设备A向设备B发送传输可靠性消息(PRACK)；

其中步骤302和步骤303主要用于对带宽和资源等的协商过程。

步骤304：设备B向设备A发送表征达成一致、会话建立的消息(200OK)；

步骤305：设备A向设备B返回会话建立响应(ACK)。

在以上步骤中，对多种媒体成分封装的媒体进行协商时，设备A可以作为SDP提供者，设备B作为SDP应答者，SDP offer在步骤301中初始的INVITE中提供，此时SDP answer可以在步骤302中183 Session In Progress中提供，也可以在步骤304中200OK中提供；也可以为设备B作为SDP提供者，设备A作为SDP应答者，此时SDP offer可以在在步骤302中183Session In Progress中或在步骤304中200OK中提供，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中如果有对所述媒体的表征信息进行的描述又有对所述媒体的所有内部媒体成分进行的描述，则判断协商成功；

所述判断模块获取的SDP answer中如果没有对所述媒体的内部媒体成分进行的描述，则判断协商失败。

由以上描述可以看出，在本发明实施例所提供的方法和系统中，SDP提供者对多种媒体成分混装的媒体进行描述，并将包含该描述信息的SDPoffer发送给SDP应答者，SDP应答者根据该SDP offer向SDP提供者返回反映其本端媒体能力的SDP answer；如果没有协商成功且没有协商失败，SDP提供者将根据该SDP answer重新生成SDP offer，循环上述步骤，直至协商成功或失败。由此，通过对多种媒体成分混装的媒体进行外部的封装和内部媒体成分的描述，方便于实现对多种媒体成分混装的媒体进行协商。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。

Claims (18)

1. 一种发送媒体描述信息的方法，其特征在于，该方法包括：在会话描述协议SDP中，对多种媒体成分混装的媒体表征信息进行描述，以及对多种媒体成分混装的媒体内部媒体成分进行描述形成描述信息后，发送该描述信息。

2. 根据权利要求1所述的方法，其特征在于，所述对多种媒体成分混装的媒体表征信息进行描述为：在SDP中使用一个统一的标识符在媒体或rtpmap属性行进行标识。

3. 根据权利要求1所述的方法，其特征在于，所述多种媒体成分混装的媒体为多个时，所述对多种媒体成分混装的媒体表征信息进行描述为：在SDP中采用多个rtpmap属性行分别使用不同标识符、或者采用多个m行分别使用不同标识符进行所述对多种媒体成分混装的媒体表征信息进行描述。

4. 根据权利要求1所述的方法，其特征在于，所述对多种媒体成分混装的媒体内部媒体成分进行描述为：在SDP中采用对fmtp属性行进行扩展的形式、或者采用在属性行新增属性符的形式对所述多种媒体成分混装的媒体内部媒体成分进行描述。

5. 根据权利要求4所述的方法，其特征在于，所述对fmtp属性行进行扩展为：将所述媒体的内部媒体成分进行分类，在fmtp属性行中分别对各类进行描述，或者

在fmtp属性行中逐一对所述媒体内部的媒体成分单独进行描述，或者

在fmtp属性行中仅描述本端设备支持的所述媒体内部媒体成分。

6. 根据权利要求4所述的方法，其特征在于，所述在属性行新增属性符的形式为：在属性行中引用多个新的属性符对所述媒体内部媒体成分进行归类描述，或者

在属性行中引用一个新的媒体属性符逐一对所述媒体内部媒体成分编解码参数进行描述。

7. 根据权利要求1所述的方法，其特征在于，所述多种媒体成分混装的媒体为传输流TS。

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. 根据权利要求10所述的方法，其特征在于，所述协商成功为：SDP应答者端设备支持多种媒体成分混装的媒体的封装，同时也支持该媒体内部所有媒体成分的编解码格式；

所述协商失败为：SDP应答者端设备不支持所述多种媒体成分混装的媒体的所有内部媒体成分；

步骤D中所述SDP提供者将根据该SDP answer重新生成SDP offer为：SDP提供者重新对SDP answer中反映的媒体能力的媒体进行描述生成SDP offer。

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应答者是所述媒体的接收方，所述SDP应答者端设备为所述媒体的接收方；或者

所述SDP提供者是所述媒体的接收方，所述SDP应答者是所述媒体的发送方，所述SDP应答者端设备为所述媒体的发送方；或者

所述SDP提供者是知晓所述媒体信息、和/或媒体发送方媒体能力的单独装置，所述SDP应答者是知晓所述媒体接收方媒体能力的单独装置，所述SDP应答者端设备为所述媒体接收方。

15. 根据权利要求13所述的系统，其特征在于，所述SDP提供者接收到的SDP answer中如果有对所述媒体的表征信息进行的描述又有对所述媒体的所有内部媒体成分进行的描述，则判断协商成功；

所述SDP提供者接收到的SDP answer中如果没有对所述媒体的内部媒体成分进行的描述，则判断协商失败。

16. 一种SDP提供者，其特征在于，该SDP提供者包括：描述单元、收发单元、以及判断单元；

描述单元，对多种媒体成分混装的媒体进行描述，并将包含描述信息的SDPoffer提供给收发单元；根据判断单元提供的SDP answer重新生成SDP offer提供给收发单元；

收发单元，将描述单元提供的SDP offer发送出去；接收SDP answer提供给判断单元；

判断单元，根据收发单元提供的SDP answer判断协商结果，如果没有协商成功且没有协商失败，将该SDP answer提供给描述单元。

17. 根据权利要求16所述的SDP提供者，其特征在于，所述SDP提供者为所述媒体的发送方、或所述媒体的接收方、或知晓所述媒体信息、和/或媒体发送方媒体能力的单独装置。

18. 根据权利要求16所述的SDP提供者，其特征在于，所述判断模块获取的SDP answer中如果有对所述媒体的表征信息进行的描述又有对所述媒体的所有内部媒体成分进行的描述，则判断协商成功；

所述判断模块获取的SDP answer中如果没有对所述媒体的内部媒体成分进行的描述，则判断协商失败。

Images