CN101674228B - 实现流媒体通信的方法、装置及系统 - Google Patents

Abstract

本发明实施例中公开了分别应用于客户端与服务器端的实现流媒体通信的方法，首先由客户端向服务器端发送携带有流媒体传输协商请求信息的流媒体会话建立请求，并由服务器端根据本端能力和所述协商请求信息确定流媒体传输协商确认信息，并将携带有所述协商确认信息的响应返回给客户端，然后由客户端向服务器端发送播放请求，服务器端通过协商确认的流标识对应的流传输相应的流媒体数据，该流媒体数据携带有流标识，最后由客户端根据流媒体数据中携带的流标识确定该流媒体数据的类型。本发明实施例中还公开了一种客户端、一种服务器和一种实现流媒体通信的系统。应用本发明能够降低应用层的实现复杂度，提高流媒体通信的性能。

Description

实现流媒体通信的方法、装置及系统

技术领域

本发明涉及流媒体通信技术，特别涉及实现流媒体通信的方法、装置及系统。

背景技术

流媒体是指在网络中使用流式传输技术进行传输的连续媒体，如：音频、视频、多媒体文件等。图1示出了目前基于IP实现流媒体通信的协议层次示意图，该协议层次由上至下依次包括：应用层、传输层和网络层。

参见图1，应用层协议有：实时流协议(RTSP)、会话描述协议(SDP)、实时传输协议/实时传输控制协议(RTP/RTCP)。RTSP用于控制流媒体数据的传输；SDP用于描述所传输的流媒体数据，RTP/RTCP用于传输流媒体数据。当然，在实际应用中，用于控制流媒体数据传输的协议不限于RTSP，例如，可以使用会话初始化协议(SIP)或媒体资源控制协议(MRCP)等控制流媒体数据的传输。

传输层协议有：传输控制协议(TCP)和用户数据报协议(UDP)。通常采用TCP传输控制数据(例如：RTSP消息)，采用UDP传输流媒体数据(例如：RTP/RTCP消息)。在特殊应用场景下(例如，流媒体数据需要穿越防火墙)，也可以采用TCP传输流媒体数据。

网络层采用IP协议。

RTSP是一个基于客户端-服务器模型的应用层协议，在流媒体通信中，客户端与服务器之间通过交换RTSP消息来实现资源描述信息的获取、会话的建立、流媒体数据的播放控制等功能。图2示出了现有RTSP会话的建立和拆除过程示意图。参见图2，RTSP Agent A(即RTSP代理A，以下简称 A)是所述会话的客户端，RTSP Agent B(即RTSP代理B，以下简称B)是所述会话的服务器端。图2所示过程包括以下步骤：

步骤201：A与B建立TCP连接。

步骤202：A向B订阅流媒体文件(DESCRIBE)，B向A返回成功响应(200 OK)。

步骤203：A与B建立音频会话(SETUP(audio))。

步骤204：A与B建立视频会话(SETUP(video))。

步骤205：A向B发送播放请求(PLAY)，B向A返回成功响应。

步骤206：B将音频文件和视频文件打包成RTP/RTCP数据包承载于UDP发送给A。

步骤207：A向B发送拆除会话请求(TEARDOWN)，用于拆除A与B之间的音频会话和视频会话，B向A返回成功响应。

步骤208：拆除A与B之间的TCP连接。

流媒体通信中，可能涉及的网络实体有：客户端(Client)、代理(Proxy)和服务器(Server)。在Client与Proxy的会话交互过程中，Proxy充当图2所示服务器端的角色；在Proxy与Server的会话交互过程中，Proxy充当图2所示客户端的角色。

发明人在实现本发明的过程中，发现现有技术中：当流媒体数据需要穿越防火墙(NAT/FW)时，不能采用UDP传输流媒体数据，可以采用TCP传输流媒体数据，称为内嵌二进制(Embedded Binary Data)。此时，控制数据与流媒体数据在同一条TCP连接上传输，应用层收到来自于传输层的数据后，必须先识别该TCP连接上的数据是控制数据还是音频RTP包或是视频RTP包，再进行相应的后续处理，这增加了上层应用的复杂度，也降低了流媒体通信的性能。

发明内容

本发明实施例提供实现流媒体通信的方法、装置及系统，以降低应用层 的实现复杂度，提高流媒体通信的性能。

本发明实施例的技术方案具体是这样实现的：

一种实现流媒体通信的方法，应用于客户端，包括：

发送流媒体会话建立请求，所述请求中携带有流媒体传输协商请求信息；

接收服务器端返回的响应，从所述响应中获得流媒体传输协商确认信息，所述协商确认信息至少包含当前流媒体类型与当前流媒体传输所用的流标识之间的对应关系；

发送播放请求；

接收服务器返回的流媒体数据，所述流媒体数据中携带有用于传输所述流媒体数据所用的流控制传输协议SCTP偶联的流对应的流标识；

根据所述流媒体数据中的流标识和所述流标识与流媒体类型的对应关系，确定所述流媒体数据的类型。

一种实现流媒体通信的方法，应用于服务器端，包括：

接收流媒体会话建立请求，所述请求中携带有流媒体传输协商请求信息；

根据本端能力和所述协商请求信息，确定流媒体传输协商确认信息，所述协商确认信息至少包含当前流媒体类型与当前流媒体传输所用的流标识之间的对应关系，并返回与所述流媒体会话建立请求对应的响应，所述响应中携带有所述协商确认信息；

接收播放请求；

通过所述协商确认的当前流媒体传输所用的流标识对应的流传输相应的流媒体数据，所述流媒体数据中包含用于传输所述流媒体数据所用的流控制传输协议SCTP偶联的流对应的流标识。

一种客户端，包括：

第一会话管理模块，用于构造携带有流媒体传输协商请求信息的流媒体会话建立请求，并从对应于所述流媒体会话建立请求的响应中获得流媒体传输协 商确认信息，所述协商确认信息至少包含当前流媒体类型与当前流媒体传输所用的流标识之间的对应关系；

第一播放处理模块，用于构造播放请求，并根据接收的流媒体数据中携带的用于传输所述流媒体数据所用的流控制传输协议SCTP偶联的流对应的流标识，以及所述流标识与流媒体类型的对应关系，确定所述接收的流媒体数据的类型；

第一通信模块，用于发送所述流媒体会话建立请求和播放请求，并用于接收来自服务器端的对应于所述流媒体会话建立请求的响应和对应于所述播放请求的流媒体数据。

一种服务器，包括：

第二会话管理模块，用于从接收的流媒体会话建立请求中获取流媒体传输协商请求信息，根据本端能力以及所述协商请求信息确定流媒体传输协商确认信息；所述协商确认信息至少包含当前流媒体类型与当前流媒体传输所用的流标识之间的对应关系；

第二播放处理模块，用于在接收到播放请求后，确定待发送的流媒体数据；

第二通信模块，用于接收所述流媒体会话建立请求和播放请求，并用于发送对应于所述流媒体会话建立请求的响应和对应于所述播放请求的流媒体数据，其中所述响应携带有所述协商确认信息，所述流媒体数据携带有用于传输所述流媒体数据所用的流控制传输协议SCTP偶联的流对应的流标识。

一种实现流媒体通信的系统，包括本发明实施例上述客户端和服务器。

由上述技术方案可见，本发明实施例所提供的实现流媒体通信的方法，首先由客户端向服务器端发送携带有流媒体传输协商请求信息的流媒体会话建立请求，并由服务器端根据本端能力和所述协商请求信息确定流媒体传输协商确认信息，所述协商确认信息至少包含当前流媒体类型与当前流媒体传输所用的流标识之间的对应关系，并将携带有所述协商确认信息的响应返回给客户端，然后由客户端向服务器端发送播放请求，服务器端通过协商确 认的流标识对应的流传输相应的流媒体数据，该流媒体数据携带有流标识，最后由客户端根据流媒体数据中携带的流标识确定该流媒体数据的类型，可见，使得客户端的应用程序通过流媒体数据中携带的流标识即可区分所接收的数据是控制数据还是流媒体数据，并确定流媒体数据的类型，从而降低了应用层的实现复杂度，减少了传输时延，提高了流媒体通信的性能。

附图说明

图1示出了目前基于IP实现流媒体通信的协议层次示意图；

图2示出了现有RTSP会话的建立和拆除过程示意图；

图3示出了现有SCTP偶联的结构示意图；

图4为本发明实施例中实现流媒体通信的方法的流程示意图；

图5为本发明实施例一中实现流媒体通信的系统的结构示意图；

图6为本发明实施例一中进行媒体传输协商的过程示意图；

图7示出了本发明实施例一所建立的偶联的结构示意图；

图8为本发明实施例一中实现流媒体通信的消息交互流程示意图；

图9为本发明实施例二中实现流媒体通信的系统的结构示意图；

图10示出了本发明实施例二中所建立的偶联的结构示意图；

图11为本发明实施例二中实现流媒体通信的消息交互流程示意图；

图12为本发明实施例三中实现流媒体通信的系统的结构示意图；

图13为本发明实施例客户端的组成结构示意图；

图14为本发明实施例服务器的组成结构示意图；

图15为本发明实施例实现流媒体通信的系统的组成结构示意图。

具体实施方式

为使本发明的目的、技术方案及优点更加清楚明白，以下参照附图并举实施例，对本发明作进一步详细说明。

为了降低应用层的实现复杂度、提高流媒体通信的性能，本发明实施例 提出一种基于流控制传输协议(SCTP)实现流媒体通信的技术方案。

SCTP是IETF提出的一种传输层协议，它运行于提供不可靠传递的分组网络上，向用户提供用户数据无错误无重复的确认传输。SCTP偶联(association)类似于TCP连接，但含义更广。一条偶联的两个SCTP端点都向对方提供一个SCTP端口号和一个IP地址列表，这样每个偶联都由两个SCTP端口号和两个IP地址列表来识别。

在一条SCTP偶联中可以包含多个流(stream)，各个流之间的数据传输相对独立。图3示出了现有SCTP偶联的结构示意图。参见图3，图中所示stream 0、stream 1......stream n同属于一条偶联，每个流的编号唯一。应用层中的SCTP应用程序在传输数据包时指明所述数据包的SCTP偶联和所属流标识，接收端收到数据包后，就可以根据数据包中的流标识来确定所接收的数据包归属于哪个流，从而保证各个流之间所传输的数据的独立性。

本发明实施例利用SCTP偶联的多流特性提出基于SCTP实现流媒体通信的技术方案。如背景技术所述，流媒体通信中，可能涉及的网络实体有：客户端、代理和服务器。在客户端与代理的会话交互过程中，代理实际上充当服务器端的角色；在代理与服务器的会话交互过程中，代理实际上充当客户端的角色，因此，本发明实施例提供了分别应用于客户端与服务器端的实现流媒体通信的技术方案。

图4为本发明实施例实现流媒体通信的方法的流程示意图。图4所示方法涉及客户端的处理以及服务器端的处理，下面分别进行说明。

参见图4，客户端处理流程包括以下步骤：

步骤401：发送流媒体会话建立请求。

本步骤所述流媒体会话建立请求中携带有流媒体传输协商请求信息。所述协商请求信息中可以包含：客户端推荐的用于传输当前流媒体数据所属SCTP偶联的流标识，该协商请求信息中还可以进一步包含：表示采用已经建立的SCTP偶联进行传输的信息、或表示采用新建的SCTP偶联进行传输的信息。

在发送本步骤所述流媒体会话建立请求之前，可以建立SCTP偶联，并将所有的控制数据在所述SCTP偶联的某一预先设置的流中传输。在具体实现时，有如下两种传输控制数据的方式：

第一种传输控制数据方式：对应于每一个流媒体会话，建立一条SCTP偶联，并预先设置用于传输控制数据的流标识。这种方式下，某一流媒体会话的所有控制数据将在其对应的SCTP偶联的所述预先设置的流标识对应的流上传输，并且，所有的控制数据中进一步携带所述预先设置的流标识。

例如：对应于第一种传输控制数据方式，本步骤所述发送流媒体会话建立请求可以是：在与所述流媒体会话建立请求所属的流媒体会话对应的SCTP偶联中的所述预先设置的流标识对应的流上发送进一步携带有所述预先设置的流标识的流媒体会话建立请求。

第二种传输控制数据方式：建立一条供多个流媒体会话共用的SCTP偶联，并设置各个流媒体会话与所述共用的SCTP偶联的各个流标识之间的对应关系，所述各个流标识对应的流分别用于传输对应的流媒体会话的控制数据。在设置所述对应关系时，可以根据流媒体会话的建立时间先后次序关系，将最先建立的流媒体会话对应到stream0，将第二个建立的流媒体会话对应到stream1，依此类推。这种方式下，某一流媒体会话的所有控制数据将在该共用的SCTP偶联的与之相应的流标识对应的流上传输，并且，所有的控制数据中进一步携带与之对应的流标识。

例如：对应于第二种传输控制数据方式，本步骤所述发送流媒体会话建立请求可以是：根据所述设置的对应关系确定与所述请求所属的流媒体会话对应的流标识，在所述共用的SCTP偶联中所述确定的流标识对应的流上发送进一步携带有所述确定的流标识的流媒体会话建立请求。

步骤402：接收服务器端返回的响应，从所述响应中获得流媒体传输协商确认信息。

本步骤中，所述协商确认信息至少包含当前流媒体类型与当前流媒体传输所用的流标识之间的对应关系。此外，所述协商确认信息中还可以包含：服务器端协商确认的用于传输当前流媒体数据所属SCTP偶联的流标识。所述协商确认信息中还可以进一步包含：表示采用已经建立的SCTP偶联进行传输的信息、或表示采用新建的SCTP偶联进行传输的信息。

对应于步骤401所述第一种传输控制数据的方式，本步骤所述接收服务器端返回的响应可以是：从与所述响应所属的流媒体会话对应的SCTP偶联中的所述预先设置的流标识对应的流上接收进一步携带有所述预先设置的流标识的响应。

对应于步骤401所述第二种传输控制数据的方式，本步骤所述接收服务器端返回的响应可以是：根据所述设置的对应关系确定与所述响应所属的流媒体会话对应的流标识，从所述共用的SCTP偶联中所述确定的流标识对应的流上接收进一步携带有所述确定的流标识的响应。

在接收到携带有流标识的响应后，客户端就可以根据所述响应中携带的流标识和预先设置的用于传输控制数据的流标识的匹配结果，确定所述接收到的响应是否为控制数据。

步骤403：发送播放请求。

对应于步骤401所述第一种传输控制数据的方式，本步骤所述发送播放请求可以是：在与所述请求所属的流媒体会话对应的SCTP偶联中的所述预先设置的流标识对应的流上发送携带有所述预先设置的流标识的播放请求。

对应于步骤401所述第二种传输控制数据的方式，本步骤所述发送播放请求包括：根据所述设置的对应关系确定与所述请求所属的流媒体会话对应的流标识，在所述共用的SCTP偶联中所述确定的流标识对应的流上发送进一步携带有所述流标识的播放请求。

步骤404：接收服务器返回的流媒体数据，所述流媒体数据中携带有用于传输所述流媒体数据所用的SCTP偶联的流对应的流标识。

若步骤402所述协商确认信息中包含表示采用已经建立的SCTP偶联进行传输的信息，则本步骤所述接收服务器返回的流媒体数据可以是：从已经建立的SCTP偶联中协商确认的流标识对应的流上接收服务器端返回的流媒体数据。

若步骤402所述协商确认信息中包含表示采用新建的SCTP偶联进行传输的信息，则在步骤402接收服务器端返回的响应之后，进一步需要对应所述流媒体会话，建立新的SCTP偶联；此时，本步骤所述接收服务器返回的流媒体数据可以是：从所述新的SCTP偶联中协商确认的流标识对应的流上接收服务器端返回的流媒体数据。

步骤405：根据所述流媒体数据中的流标识和所述流标识与流媒体类型的对应关系，确定所述流媒体数据的类型。

至此，结束客户端的处理。

参见图4，服务器端处理流程包括以下步骤：

步骤401：接收流媒体会话建立请求。

本步骤所述流媒体会话建立请求中也携带有流媒体传输协商请求信息。所述协商请求信息中可以包含：客户端推荐的用于传输当前流媒体数据所属SCTP偶联的第三流标识；所述协商请求信息中还可以进一步包含：表示采用已经建立的SCTP偶联进行传输的信息、或表示采用新建的SCTP偶联进行传输的信息。

对应于客户端处理流程中步骤401所述第一种传输控制数据的方式，本步骤所述接收流媒体会话建立请求可以是：从与所述请求所属的流媒体会话对应的SCTP偶联中的流上接收进一步携带有客户端预先设置的第一流标识的流媒体会话建立请求。

对应于客户端处理流程中步骤401所述第二种传输控制数据的方式，本步骤所述接收流媒体会话建立请求可以是：从所述共用的SCTP偶联中的流上接收进一步携带有客户端确定的第二流标识的流媒体会话建立请求。

步骤402：根据本端能力和所述协商请求信息，确定流媒体传输协商确认信息，并返回与所述流媒体会话建立请求对应的响应，所述响应中携带有所述协商确认信息。

本步骤中，可以根据本端能力和协商请求信息中的客户端推荐的用于传 输当前流媒体数据的第三流标识，协商确认用于传输当前流媒体数据所属SCTP偶联的流标识，所述流标识为所述第三流标识或者服务器端重新分配的第四流标识，得到包含当前流媒体类型与当前流媒体传输所用的流标识的对应关系的协商确认信息。

并且，可以根据本端能力和协商请求信息中包含的表示采用已经建立的SCTP偶联进行传输的信息、或表示采用新建的SCTP偶联进行传输的信息，确定采用已经建立的SCTP偶联中所述客户端推荐的第三流标识或者服务器端重新分配的第四流标识用于传输，得到包含当前媒体流类型与当前媒体流传输所用的流标识的对应关系以及表示媒体传输所用的SCTP偶联的信息的协商确认信息，或者，确定采用新建的SCTP偶联中所述客户端推荐的第三流标识或者服务器端重新分配的第四流标识用于传输，得到包含当前媒体流类型与当前媒体流传输所用的流标识的对应关系以及表示媒体传输所用的SCTP偶联的信息的协商确认信息。

对应于客户端处理流程中步骤401所述第一种传输控制数据的方式，本步骤所述返回响应可以是：在与所述响应所属流媒体会话对应的SCTP偶联中所述携带于所述流媒体会话建立请求中的第一流标识对应的流上发送携带有所述第一流标识的响应。

对应于客户端处理流程中步骤401所述第二种传输控制数据的方式，本步骤所述返回响应可以是：在所述共用的SCTP偶联中所述携带的第二流标识对应的流上发送进一步携带有所述第二流标识的响应。

步骤403：接收播放请求，根据所述播放请求确定待发送的流媒体数据。

对应于客户端处理流程中步骤401所述第一种传输控制数据的方式，本步骤所述接收播放请求包括：从与所述请求所属的流媒体会话对应的SCTP偶联中的所述第一流标识对应的流上接收携带有所述第一流标识的播放请求。

对应于客户端处理流程中步骤401所述第二种传输控制数据的方式，本步骤所述接收播放请求包括：从所述共用的SCTP偶联中的流上接收携带有 所述第二流标识的播放请求。

步骤404：通过所述协商确认的当前流媒体传输所用的流标识对应的流传输相应的流媒体数据，所述流媒体数据中包含用于传输所述流媒体数据所用的SCTP偶联的流对应的流标识。

若步骤402所述协商确认信息为采用已经建立的SCTP偶联进行传输，则本步骤所述通过协商确认的流标识对应的流传输相应的流媒体数据可以是：在所述已经建立的SCTP偶联中协商确认的流标识对应的流上传输流媒体数据。

若步骤402所述协商确认信息为采用新建的SCTP偶联进行传输，则在步骤402返回响应之后，进一步需要对应所述流媒体会话，重新建立新的SCTP偶联；此时，本步骤所述通过协商确认的流标识对应的流传输相应的流媒体数据可以是：在所述新的SCTP偶联中协商确认的流标识对应的流上传输流媒体数据。

至此，结束服务器端的处理。

对应于上述方法，本发明实施例还提供了一种客户端和一种服务器端。

图13为本发明实施例客户端的组成结构示意图。参见图13，本发明实施例提供的客户端包括：

第一会话管理模块1301，用于构造携带有流媒体传输协商请求信息的流媒体会话建立请求，并从对应于所述流媒体会话建立请求的响应中获得流媒体传输协商确认信息，所述协商确认信息至少包含当前流媒体类型与当前流媒体传输所用的流标识之间的对应关系；

第一播放处理模块1302，用于构造播放请求，并根据接收的流媒体数据中携带的用于传输所述流媒体数据所用的流控制传输协议SCTP偶联的流对应的流标识，以及所述流标识与流媒体类型的对应关系，确定所述接收的流媒体数据的类型；

第一通信模块1303，用于发送所述流媒体会话建立请求和播放请求，并用于接收来自服务器端的对应于所述流媒体会话建立请求的响应和对应于所述播放请求的流媒体数据。

较佳地，所述客户端中还可以进一步包括：第一确定单元1304，用于根据第一通信模块接收的所述响应中携带的流标识和预先设置的用于传输控制数据的流标识的匹配结果，确定所述接收到的响应是否为控制数据。

图14为本发明实施例服务器的组成结构示意图。参见图14，本发明实施例提供的服务器包括：

第二会话管理模块1401，用于从接收的流媒体会话建立请求中获取流媒体传输协商请求信息，根据本端能力以及所述协商请求信息确定协商确认信息；所述协商确认信息至少包含当前流媒体类型与当前流媒体传输所用的流标识之间的对应关系；

第二播放处理模块1402，用于在接收到播放请求后，确定待发送的流媒体数据；

第二通信模块1403，用于接收所述流媒体会话建立请求和播放请求，并用于发送对应于所述流媒体会话建立请求的响应和对应于所述播放请求的流媒体数据，其中所述响应携带有所述协商确认信息，所述流媒体数据携带有用于传输所述流媒体数据所用的流控制传输协议SCTP偶联的流对应的流标识。

较佳地，所述第二会话管理模块1401，具体可以用于从接收的流媒体会话建立请求中获取流媒体传输协商请求信息，所述流媒体传输协商请求信息包含客户端推荐的用于传输当前流媒体数据所属SCTP偶联的第三流标识；根据本端能力和该流媒体会话建立请求中的客户端推荐的所述第三流标识，协商得到包含当前流媒体类型与当前流媒体传输所用流标识的对应关系的协商确认信息，其中所述流标识为所述第三流标识或者重新分配的第四流标识。

图15为本发明实施例实现流媒体通信的系统的组成结构示意图。参见图15，本发明实施例提供的实现流媒体通信的系统包括图13所示客户端和图14所述服务器，具体地：

客户端1501，用于向服务器1502发送携带有流媒体传输协商请求信息的流媒体会话建立请求，接收服务器1502返回的对应于所述流媒体会话建立的响应，从所述响应中获得流媒体传输协商确认信息，所述协商确认信息至少包含当前流媒体类型与当前流媒体传输所用的流标识之间的对应关系；并用于向服务器1502发送播放请求，接收来自服务器1502流媒体数据，根据接收的流媒体数据中携带的用于传输所述流媒体数据所用的SCTP偶联的流对应的流标识，以及所述流标识与流媒体类型的对应关系，确定所述接收的流媒体数据的类型；

服务器1502，用于接收来自客户端1501的流媒体会话建立请求，从所述流媒体会话建立请求获取流媒体传输协商请求信息，根据本端能力以及所述协商请求信息确定流媒体传输协商确认信息，返回携带有所述协商确认信息的对应于所述流媒体会话建立请求的响应给客户端1501，并用于接收来自客户端1501的播放请求，将相应的流媒体数据发送给客户端1501，所述流媒体数据携带有用于传输所述流媒体数据所用的流控制传输协议SCTP偶联的流对应的流标识。

参见图9、12，应当理解的是：当Client a与Proxy B通信时，这里的Client a的角色是客户端，相应的Proxy B为服务器端；

当Proxy B与Server C通信时，这里的Proxy B的角色就是客户端，相应的Server C为服务器端。

由上述可见，本发明实施例所提供的实现流媒体通信的方法，首先由客户端向服务器端发送携带有流媒体传输协商请求信息的流媒体会话建立请求，并由服务器端根据本端能力和所述协商请求信息确定流媒体传输协商确认信息，所述协商确认信息至少包含当前流媒体类型与当前流媒体传输所用的流标识之间的对应关系，并将携带有所述协商确认信息的响应返回给客户端，然后由客户端向服务器端发送播放请求，服务器端通过协商确认的流标识对应的流传输相应的流媒体数据，该流媒体数据携带有流标识，最后由客户端根据流媒体数据中携带的流标识确定该流媒体数据的类型，可见，使得客户端的应用程序通过流媒体数据中携带的流标识即可区分所接收的数据 是控制数据还是流媒体数据，并确定流媒体数据的类型，从而降低了应用层的实现复杂度，减少了传输时延，提高了流媒体通信的性能。

实际应用中存在各种各样的流媒体通信场景，例如：流媒体通信可能只涉及客户端和服务器，还可能进一步涉及代理；所述客户端和服务器可能位于不同网络，而代理位于网络边缘；流媒体数据可能需要经过代理，也可能不需要经过代理等等。因此，本发明针对实际应用中可能出现的各种流媒体通信应用场景，提出了与之相应的实现流媒体通信的技术方案。下面将根据不同的应用场景描述本发明实施例所提供的实现流媒体通信的技术方案。

实施例一：对于不涉及代理，客户端在内部网络、服务器在外部网络的情况，本发明实施例中提供了如下传输控制数据和媒体数据的技术方案：

在客户端与服务器之间，为每一个流媒体会话建立一条SCTP偶联，每条SCTP偶联中建立多个流，在每条SCTP偶联的预先设置的流标识对应的流中传输控制数据，并通过控制数据进行媒体传输协商；根据所述媒体传输协商的结果，以与该协商结果对应的传输方式在所述每条SCTP偶联的除预先设置的流标识对应的流之外的其他流中传输相应流媒体会话的流媒体数据。

针对这种应用场景实现流媒体通信的系统的结构示意图如图5所示。图5中，Client A表示客户端，Server C表示服务器，Client A与Server C之间的实线箭头表示SCTP偶联，该SCTP偶联中不仅承载有控制数据，还承载有流媒体数据。

较佳地，所述预先设置的流标识可以是流0，当然也可以是流1等。

上述在除预先设置的流标识对应的流之外的其他流中传输相应流媒体会话的流媒体数据可以是：在除所述预先设置的流标识对应的流之外的同一个流中传输同一流媒体会话的不同类型的流媒体数据，也可以是：在除所述预先设置的流标识对应的流之外的不同流中分别传输同一流媒体会话的不同类型的流媒体数据。具体采用哪个流传输哪种流媒体数据，是通过控制数据进行媒体传输协商决定的。

图6为本发明实施例一中进行媒体传输协商的过程示意图。参见图6，媒体传输协商过程中涉及的实体包括媒体接收端和媒体发送端，对应于本实施例，所述媒体接收端为客户端、所述媒体发送端为服务器端，该媒体传输协商过程包括：

步骤601：媒体接收端向媒体发送端指明：采用SCTP进行流媒体数据的传输，以下简称“媒体传输”。

步骤602：媒体接收端向媒体发送端指明：采用新建SCTP偶联或原有已经建立好的SCTP偶联进行媒体传输。

步骤603：媒体接收端向媒体发送端指明：媒体接收端的IP和端口。

步骤604：媒体接收端向媒体发送端指明：媒体所属SCTP偶联的流标识。

步骤605：媒体发送端确认采用SCTP进行媒体传输。

步骤606：媒体发送端确认采用新建SCTP偶联或原有已经建立好的SCTP偶联进行媒体传输。

步骤607：媒体发送端向媒体接收端指明：媒体发送端的IP和端口。

步骤608：媒体发送端确认媒体所属SCTP偶联的流标识。

至此，结束媒体传输协商过程。

假设本实施例中，所述预先设置用于传输控制数据的流标识为0，经上述媒体传输协商之后，决定使用流标识为1的流传输音频数据、使用流标识为2的流传输视频数据，以应用层协议采用RTSP为例，图7示出了本发明实施例一中所建立的偶联的结构示意图。参见图7，客户端与服务器之间的一个流媒体会话创建一条偶联，该偶联创建3个流，其中，stream0用于传输RTSP控制数据，stream1用于传输音频数据(如图所示Audio RTP包)，stream2用于传输视频数据(如图所示Video RTP包)。

图8为本发明实施例一中实现流媒体通信的消息交互流程示意图。图中RTSP Client A为本发明实施例所述客户端，以下简称A；RTSP Server C为本发明实施例所述服务器，以下简称C。图8所示消息交互流程包括以下步 骤：

步骤801：A向C发起SCTP偶联a，同时在当前SCTP偶联中建立多个流。针对本实施例，由于将音频数据和视频数据置于不同流中传输，因此，所建立的流不少于3个。

步骤802：A在偶联a的stream 0上向C发送DESCRIBE请求，订阅流媒体文件；C收到DESCRIBE请求后在偶联a的stream 0上向A返回200 OK响应。

步骤803：完成音频会话建立过程，同时完成媒体传输协商过程，确定音频媒体数据在SCTP的哪个流上传输。步骤803具体包括如下步骤8031和步骤8032。

步骤8031：A在偶联a的stream 0上向C发送音频会话建立请求。

在音频连接建立请求的transport头域中携带如下字段：

a)RTP/AVP/SCTP——指明音频数据基于SCTP传输；

b)connection＝existing——说明音频数据将基于原有已存在的偶联传输，不需要重新创建；

c)dest_addr＝“192.0.2.5:544“——音频数据的接收目的ip地址和端口号，即：Client A的地址和端口号；

d)streamid＝＂1:＂——说明客户端建议音频数据所属SCTP偶联的流标识，1表示RTP所属的流标识，冒号之后的数字表示RTCP所属的流标识，如果冒号之后没有任何标识，则表示无RTCP包。流标识A的建议值，对端在回响应时可以改变。

示例如下：

SETUP rtsp://example.com/twister.3gp/audio RTSP/2.0

CSeq:2

User-Agent:PhonyClient/1.2

Require:play.basic

Transport:RTP/AVP/SCTP；unicast；connection＝existing；

dest_addr＝“192.0.2.5:544“；streamid＝”1:”；

步骤8032：C在偶联a的stream0上向A发送200OK响应。并在该200OK响应的transport头域中携带如下字段：

a)RTP/AVP/SCTP——指明音频媒体数据基于SCTP传输；

b)connection＝existing——说明音频数据将基于原有已存在的偶联传输，不需要重新创建；

c)src_addr＝“192.0.2.5:554″——音频数据的源ip地址和端口号；

d)streamid＝″1:2″——说明服务器传输视频媒体的实际流标识，1表示RTP所属的流标识，3标识RTCP所属的流标识。如果冒号之后没有任何标识，则表示无RTCP包。

示例如下：

RTSP/2.0200 OK

CSeq:2

Server:PhonyServer/1.0

Transport:RTP/AVP/SCTP；unicast；connection＝existing；

src_addr＝″192.0.2.5:554″；

streamid＝“1:2“；ssrc＝93CB001E

Session:12345678

Expires:24 Jan 1997 15:35:12 GMT

Date:23 Jan 1997 15:35:12 GMT

Accept-Ranges:NPT

步骤804：完成视频会话建立过程，同时完成媒体传输协商过程，确定视频媒体数据在SCTP的哪个流上传输。步骤804具体包括如下步骤8041和步骤8042。

步骤8041：A在偶联a的stream0上向B发送视频连接建立请求(SETUP(video))。本步骤中，可以在视频连接建立请求的transport头域中携带以下字段：

a)RTP/AVP/SCTP——指明视频媒体数据基于SCTP传输；

b)connection＝existing——说明视频媒体数据基于原有已存在的偶联传输，不需要重新创建；

c)dest_addr＝″192.0.2.5:9000″——视频媒体数据的接收目的ip地址和端口号；

d)src_addr＝“192.0.2.5:554＂——视频媒体数据的源ip地址和端口号；

e)streamid＝″3:4″——说明客户端建议视频媒体数据所属SCTP偶联的流标识，3表示RTP所属的流标识，4表示RTCP所属的流标识。如果冒号之后没有任何标识，则表示无RTCP包。流标识是A的建议值，对端在返回响应时可以改变。

示例如下：

SETUP rtsp://example.com/twister.3gp/video RTSP/2.0

CSeq:3

User-Agent:PhonyClient/1.2

Require:play.basic

Session:12345678

Transport:RTP/AVP/SCTP；unicast；connection＝existing；

dest_addr＝″192.0.2.5:9000″；

src_addr＝″192.0.2.5:554″；streamid＝“2:“；

步骤8042：C在偶联a的stream 0上向B发送200 OK响应，并在transport头域中携带如下字段：

a)RTP/AVP/SCTP——指明视频媒体数据基于SCTP传输；

b)connection＝existing——说明视频媒体数据基于原有已存在的偶联传输，不需要重新创建；

c)src_addr＝“192.0.2.5:554″“——视频媒体数据的源ip地址和端口号；

d)streamid＝″2:″——说明服务器传输视频媒体数据的实际流标识，2表示RTP所属的流标识，冒号之后的数字表示RTCP所属的流标识，如果冒号之 后没有任何标识，则表示无RTCP包。

示例如下：

RTSP/2.0 200 OK

CSeq:3

Server:PhonyServer/1.0

Transport:RTP/AVP/SCTP；unicast；connection＝existing；

src_addr＝″192.0.2.5:554″；

streamid＝“2:“；ssrc＝93CB001E

Session:12345678

Expires:24 Jan 1997 15:35:12 GMT

Date:23 Jan 1997 15:35:12 GMT

Accept-Ranges:NPT

步骤805：A在偶联a的stream 0上向C发送播放(PLAY)请求消息，请求播放流媒体；C收到播放请求消息后，在偶联a的stream 0上向A返回200响应。

步骤806：C在协商好的流上传输音频和视频数据。在偶联a的stream 1上传送音频RTP包，在偶联a的stream 2上传送音频RTCP包；在偶联a的stream 3上传送视频RTP包，在偶联a的stream 4上传送视频RTCP包。

至此，结束本发明实施例一中实现流媒体通信的消息交互流程。

实施例二：对于涉及代理，客户端在内部网络、代理位于网络边缘、服务器在外部网络、流媒体数据不经过代理的情况，本发明实施例中提供了如下传输控制数据和媒体数据的技术方案：

由于流媒体数据不需要经过代理，可以为每一个流媒体会话建立至少三条SCTP偶联，具体地：

在客户端与代理之间，为每一个流媒体会话建立一条SCTP偶联，在所述SCTP偶联的预先设置的流标识对应的流中传输相应流媒体会话的控制数据，并通过所述控制数据进行媒体传输协商；

在代理和服务器之间，建立一条供多个流媒体会话共用的SCTP偶联，并在所述SCTP偶联中建立与所述多个流媒体会话一一对应的多个流，在所述多个流中传输相应流媒体会话的控制数据，并通过所述控制数据进行相应流媒体会话的媒体传输协商；

根据所述媒体传输协商的结果，在客户端与服务器之间，为每一个流媒体会话建立至少一条SCTP偶联，在所述至少一条偶联的除预先设置的流标识对应的流之外的其他流中传输相应流媒体会话的流媒体数据。

针对这种应用场景实现流媒体通信的系统的结构示意图如图9所示。图9中，Client a、Client b和Client c表示客户端，ProxyB表示代理，Server C表示服务器，Client A与ProxyB之间的实线箭头，以及ProxyB与Server C之间的实线箭头表示承载有控制数据的SCTP偶联，Client A与Server C之间的虚线箭头表示承载有流媒体数据的SCTP偶联。

与实施例一类似，较佳地，所述预先设置的流标识可以是流0，当然也可以是流1等。

上述在除预先设置的流标识对应的流之外的其他流中传输相应流媒体会话的流媒体数据可以是：在除所述预先设置的流标识对应的流之外的同一个流中传输同一流媒体会话的不同类型的流媒体数据，也可以是：在除所述预先设置的流标识对应的流之外的不同流中分别传输同一流媒体会话的不同类型的流媒体数据。具体采用哪个流传输哪种流媒体数据，是通过控制数据进行媒体传输协商决定的。本实施例也可以根据图6所示流程进行媒体协商。

仍然以应用层协议采用RTSP为例，图10示出了本发明实施例二中所建立的偶联的结构示意图。参见图10，为描述简便，图中省略了处于客户端与服务器之间的代理。客户端与服务器之间的一个流媒体会话创建两条偶联——a和b，其中，偶联a用于传输控制数据(如图所示RTSP消息)，偶联b中的stream 1用于传输音频数据(如图所示Audio RTP包)，偶联b中的stream 2用于传输视频数据(如图所示Video RTP包)。值得说明的是： RTCP主要完成媒体数据的流量控制和拥塞控制，而由于SCTP已经提供了类似功能，因此，在基于SCTP实现流媒体通信时，可以不产生RTCP包，所以，图10中并未示出RTCP包。

图11为本发明实施例二中实现流媒体通信的消息交互流程示意图。参见图11，图中RTSP Client A为本发明实施例所述客户端，以下简称A；RTSPProxy B为本发明实施例所述代理，以下简称B；RTSP Server C为本发明实施例所述服务器，以下简称C。图11所示消息交互流程包括以下步骤：

步骤1101～步骤1102：与图8所示步骤801～802相同，在此不再赘述。

步骤1103：完成音频会话建立过程，同时需要完成媒体传输协商过程，确定音频媒体数据在新建SCTP偶联的哪个流上传输。

A在偶联a的stream 0上向B发送音频会话建立请求(SETUP(audio))，B收到所述音频会话建立请求后，也在偶联c的stream 0上向C发送音频会话建立请求。

音频会话建立请求的transport头域中需要携带该音频会话的相关信息，例如：基于哪种协议传输流媒体数据等。本步骤中，可以在音频会话建立请求的transport头域中携带如下字段：

a)RTP/AVP/SCTP——指明流媒体数据基于SCTP传输；

b)connection＝new——说明需要创建一条新的偶联；

c)setup＝active——说明SCTP偶联是由A主动创建的；

d)dest_addr＝″:9″——流媒体数据的目的ip地址和端口号，即：Client A的地址和端口号，因为是A主动创建，所以端口号设置为9(废弃端口)；

e)streamid＝″1:″——说明流媒体所属SCTP偶联的流标识，1表示RTP所属的流标识，冒号之后的数字表示RTCP所属的流标识，如果冒号之后没有任何标识，则表示无RTCP包。流标识为A的建议值，对端在返回响应时可以改变。

示例如下：

SETUP rtsp://example.com/twister.3gp/trackID＝1 RTSP/2.0

CSeq:2

User-Agent:PhonyClient/1.2

Require:play.basic

Transport:RTP/AVP/SCTP；unicast；connection＝new；

setup＝active；dest_addr＝“:9“；

streamid＝“1:“；

C在偶联c的stream 1上向B发送200 OK响应，B收到该200 OK响应后，在偶联a的stream 1上向A发送200 OK响应，并在该200 OK响应的transport头域中携带如下字段：

a)RTP/AVP/SCTP——指明流媒体基于SCTP传输；

b)connection＝new——说明需要创建一条新的偶联；

c)setup＝passive——说明SCTP偶联是B被动创建；

d)src_addr＝“192.0.2.5:554″——流媒体数据的源ip地址和端口号，这里是Server C的地址和端口号；

e)streamid＝″1:″——说明B传输流媒体的实际流标识，1表示RTP所属的流标识，冒号之后的数字表示RTCP所属的流标识，如果冒号之后没有任何标识，则表示无RTCP包。

示例如下：

RTSP/2.0 200 OK

CSeq:2

Server:PhonyServer/1.0

Transport:RTP/AVP/SCTP；unicast；connection＝new；

setup＝passive；src_addr＝″192.0.2.5:554″；

streamid＝“1:“；ssrc＝93CB001E

Session:12345678

Expires:24 Jan 1997 15:35:12 GMT

Date:23 Jan 1997 15:35:12 GMT

Accept-Ranges:NPT

步骤1104：A向C发起SCTP偶联b。

通过上述步骤1103，A与C之间已经协商好：由A主动创建一条与C之间的偶联，用于传输A与C之间的流媒体数据，并且，已协商好各自用于该偶联的ip地址和端口号，以及该偶联中用于传输流媒体数据的流的流标识。因此，本步骤中，A将向C发起SCTP偶联b，建立上述已经协商好的偶联。

步骤1105：完成视频会话建立过程，同时需要完成媒体传输协商过程，确定视频媒体数据在SCTP的哪个流上传输。

A在偶联a的stream 0上向B发送视频连接建立请求(SETUP(video))，B收到所述视频连接建立请求后，也在偶联c的stream 0上向C发送视频连接建立请求。

本步骤中，可以在视频连接建立请求的transport头域中携带以下字段：

a)RTP/AVP/SCTP——指明流媒体基于SCTP传输；

b)connection＝existing——说明使用已经存在的偶联，不需要重新创建；因为通过上述步骤1106，A与C之间已经建立起用于传输流媒体数据的偶联b，所以不需要重新创建了；

c)dest_addr＝″192.0.2.5:9000″——流媒体数据的目的ip地址和端口号；

d)src_addr＝“192.0.2.5:554″——流媒体数据的源ip地址和端口号；

e)streamid＝″2:″——说明流媒体所属SCTP偶联的流标识，2表示RTP所属的流标识，冒号之后的数字表示RTCP所属的流标识，如果冒号之后没有任何标识，则表示无RTCP包。流标识是A的建议值，对端在返回响应时可以改变。

示例如下：

SETUP rtsp://example.com/twister.3gp/trackID＝2RTSP/2.0

CSeq:3

User-Agent:PhonyClient/1.2

Require:play.basic

Session:12345678

Transport:RTP/AVP/SCTP；unicast；connection＝existing；

dest_addr＝″192.0.2.5:9000″；

src_addr＝″192.0.2.5:554″；streamid＝“2:“；

C在偶联c的stream 0上向B发送200 OK响应，B收到该200 OK响应后，在偶联a的stream 0上向A发送200 OK响应，并在transport头域中携带如下字段：

a)RTP/AVP/SCTP——指明流媒体基于SCTP传输；

b)connection＝existing——说明使用已经存在的偶联，不需要重新创建；

c)src_addr＝“192.0.2.5:554″“——流媒体数据的源ip地址和端口号；

d)streamid＝″2:″——说明B传输流媒体的实际流标识，2表示RTP所属的流标识，冒号之后的数字表示RTCP所属的流标识，如果冒号之后没有任何标识，则表示无RTCP包。

示例如下：

RTSP/2.0200OK

CSeq:3

Server:PhonyServer/1.0

Transport:RTP/AVP/SCTP；unicast；connection＝existing；

src_addr＝″192.0.2.5:554″；

streamid＝“2:“；ssrc＝93CB001E

Session:12345678

Expires:24Jan199715:35:12GMT

Date:23 Jan 1997 15:35:12 GMT

Accept-Ranges:NPT

步骤1106：A在偶联a的stream 0上向B发送播放(PLAY)请求消息， 请求播放流媒体；B收到播放请求消息后，也在偶联c的stream 0上向C发送播放请求消息。C在偶联c的stream 0上向B返回200 OK响应，B收到200 OK响应后，在偶联a的stream 0上向A返回200响应。

步骤1107：根据上述步骤1103和1104协商的结果，C将在偶联b的stream 1上传送音频RTP包，在偶联b的stream 2上传送视频RTP包；相应地，A将在偶联b的stream 1上接收音频RTP包，在偶联b的stream 2上接收视频RTP包。

至此，结束本发明实施例二中实现流媒体通信的消息交互流程。

实施例三：对于涉及代理，客户端在内部网络、代理位于网络边缘、服务器在外部网络、流媒体数据需要经过代理的情况，本发明实施例中提供了如下传输控制数据和媒体数据的技术方案：

在客户端与代理之间，为每一个流媒体会话建立一条SCTP偶联，每条SCTP偶联中建立多个流，在每条SCTP偶联的预先设置的流标识对应的流中传输控制数据，并通过控制数据完成媒体传输协商，根据所述媒体传输协商的结果，以与该协商结果对应的传输方式在所述每条SCTP偶联的除预先设置的流标识对应的流之外的其他流中传输相应流媒体会话的流媒体数据；

在代理和服务器之间，建立一条供多个流媒体会话共用的SCTP偶联，并在所述SCTP偶联中建立与所述多个流媒体会话一一对应的多个流，在所述多个流中传输相应流媒体会话的控制数据，并通过控制数据完成媒体传输协商，根据所述媒体传输协商的结果在所述SCTP偶联的除用于传输控制数据的流之外的其他流中传输流媒体数据。

针对这种应用场景实现流媒体通信的系统的结构示意图如图12所示。图12中，各Client与Proxy B之间的实线箭头以及Proxy B与Server C之间的实线箭头表示SCTP偶联，各SCTP偶联中不仅承载有控制数据，还承载有流媒体数据。

以上对本发明实施例提供的实现流媒体通信的方法进行了详细说明，下面结合附图，对本发明实施例提供的实现流媒体通信的系统进行说明。

参见图5所示本发明实施例一中实现流媒体通信的系统结构示意图，该系统包括客户端A和服务器C，其中：

所述客户端A，用于与服务器C建立SCTP偶联，在所述SCTP偶联的预先设置的流标识对应的流中传输流媒体会话的控制数据(应当理解的是：控制数据就是客户端A和服务器C之间交互的信令消息)，进行媒体传输协商，并用于根据所述媒体传输协商的结果，以与该协商结果对应的传输方式接收相应流媒体会话的流媒体数据；需要说明的是：前述提及的“进行媒体传输协商，并用于根据所述媒体传输协商的结果，以与该协商结果对应的传输方式接收相应流媒体会话的流媒体数据”的描述请参考前述图15所示的本发明实施例的实现流媒体通信的系统的描述。

所述服务器C，用于与客户端A建立SCTP偶联，并用于在所述SCTP偶联的预先设置的流标识对应的流中传输流媒体会话的控制数据，进行媒体传输协商，并用于根据所述媒体传输协商的结果，以与该协商结果对应的传输方式发送相应流媒体会话的流媒体数据。需要说明的是：前述提及的“进行媒体传输协商，并用于根据所述媒体传输协商的结果，以与该协商结果对应的传输方式发送相应流媒体会话的流媒体数据”的描述请参考前述图15所示的本发明实施例的实现流媒体通信的系统的描述。

图5所述系统中，所述服务器C，还可以用于根据所述媒体传输协商的结果在所述SCTP偶联中建立多个流，并用于在除所述预先设置的流标识对应的流之外的其他流中发送相应流媒体会话的流媒体数据；

所述客户端A，还可以用于在除所述预先设置的流标识对应的流之外的其他流中接收相应流媒体会话的流媒体数据。

参见图9、图12所示本发明实施例二中实现流媒体通信的系统结构示意图，图9和图12所示系统结构示意图适用于系统包括客户端a、b、c、代理B和服务器C的情况，其中：

所述客户端a、b、c，用于与代理B建立SCTP偶联，并用于在所述SCTP偶联的预先设置的流标识对应的流中传输流媒体会话的控制数据，进行媒体 传输协商，并用于根据所述媒体传输协商的结果，接收相应流媒体会话的流媒体数据；需要说明的是：前述提及的“进行媒体传输协商，并用于根据所述媒体传输协商的结果，接收相应流媒体会话的流媒体数据”的描述请参考前述图15所示的本发明实施例的实现流媒体通信的系统的描述。

所述代理B，用于与客户端a、b、c分别建立SCTP偶联，在所述SCTP偶联的预先设置的流标识对应的流中传输流媒体会话的控制数据，进行媒体传输协商；并用于与服务器建立供多个流媒体会话共用的SCTP偶联，在所述共用的SCTP偶联中建立与所述多个流媒体会话一一对应的多个流，在所述多个流中传输相应流媒体会话的控制数据，通过所述控制数据进行相应流媒体会话的媒体传输协商；需要说明的是：前述提及的“进行媒体传输协商”和“在所述多个流中传输相应流媒体会话的控制数据，通过所述控制数据进行相应流媒体会话的媒体传输协商”的描述请参考前述图15所示的本发明实施例的实现流媒体通信的系统的描述。

所述服务器C，用于与代理B建立供多个流媒体会话共用的SCTP偶联，在所述共用的SCTP偶联中建立与所述多个流媒体会话一一对应的多个流，在所述多个流中传输相应流媒体会话的控制数据，通过所述控制数据进行相应流媒体会话的媒体传输协商，并用于根据所述媒体传输协商的结果，发送相应流媒体会话的流媒体数据。需要说明的是：前述提及的“在所述多个流中传输相应流媒体会话的控制数据，通过所述控制数据进行相应流媒体会话的媒体传输协商，并用于根据所述媒体传输协商的结果，发送相应流媒体会话的流媒体数据”的描述请参考前述图15所示的本发明实施例的实现流媒体通信的系统的描述。

图9所示系统中，所述服务器C，还用于根据所述媒体传输协商的结果与客户端a、b、c建立至少一条SCTP偶联，在所述至少一条SCTP偶联的除预先设置的流标识对应的流之外的其他流中发送相应流媒体会话的流媒体数据；

所述客户端a、b、c，还用于在所述至少一条SCTP偶联的除预先设置 的流标识对应的流之外的其他流中接收相应流媒体会话的流媒体数据。

较佳地，图9所示系统中，所述服务器C为第一服务器，可以用于根据所述媒体传输协商的结果与客户端建立一条包含多个流的SCTP偶联，并用于在所述包含多个流的SCTP偶联的除预先设置的流标识对应的流之外的多个流中分别发送不同类型的流媒体数据；

所述客户端a、b、c为第一客户端，可以用于在所述包含多个流的SCTP偶联的除预先设置的流标识对应的流之外的多个流中分别接收不同类型的流媒体数据。

较佳地，图9所示系统中，所述服务器C为第二服务器，可以用于根据所述媒体传输协商的结果与客户端建立多条SCTP偶联，并用于在所述多条SCTP偶联的除预先设置的流标识对应的流之外的流中分别发送不同类型的流媒体数据；

所述客户端a、b、c为第二客户端，可以用于在所述多条SCTP偶联的除预先设置的流标识对应的流之外的流中分别接收不同类型的流媒体数据。

图12所示系统中，所述服务器C，还用于根据所述媒体传输协商的结果在所述共用的SCTP偶联中为所述多个流媒体会话的每一个流媒体会话建立至少一个流，在所述至少一个流中发送相应流媒体会话的流媒体数据；

所述代理B，还用于在所述共用的SCTP偶联的多个流中接收相应流媒体会话的流媒体数据；并用于根据所述媒体传输协商的结果在所述与客户端a、b、c之间的SCTP偶联中建立多个流，在所述建立的多个流的除所述预先设置的流标识对应的流之外的其他流中发送接收自服务器的相应流媒体会话的流媒体数据；

所述客户端a、b、c，还用于并在所述与代理之间建立的多个流的除所述预先设置的流标识对应的流之外的其他流中接收相应流媒体会话的流媒体数据。

由上述实施例可见，本发明实施例所提供的实现流媒体通信的方法，通过在代理与服务器之间建立供多个流媒体会话共用的SCTP偶联，并在所述 共用的SCTP偶联的不同流上传输所述多个流媒体会话的控制数据，这样，可以通过所述控制数据进行媒体传输协商，从而确定如何进行流媒体数据的传输。一方面能够充分利用SCTP偶联的多流特性，使应用程序通过流标识即可区分所接收的数据属于哪一个流，从而降低了应用层的实现复杂度、减少了传输时延、提高了流媒体通信的性能，并增强了多路会话的并发性；另一方面，由于代理与服务器之间的多个流媒体会话共用一条SCTP偶联，减少了创建SCTP偶联所带来的开销以及资源消耗。

此外，由于SCTP协议本身所具备的一些优秀特性，使得本发明实施例所提供的实现流媒体通信的技术方案还能取得如下有益效果：

1)通过SCTP建立“四次握手”中的cookie机制，有效避免服务器遭受拒绝服务(DOS)攻击，增强了流媒体通信的安全性，使得提供实时流媒体数据的服务器变得更加可靠。

2)SCTP具有无序可靠传输的功能，可以使达到接收端的数据包不用等待前面的数据包就可以直接提交到应用层，提高了数据的传输效率。

3)利用SCTP支持多流传输的功能，使音频数据和视频数据分开传输，减少了声音和视频同时丢包失真的概率。

本领域普通技术人员可以理解实现上述实施例中实现流媒体通信的过程可以通过程序指令相关的硬件来完成，所述的程序可以存储于客户端、代理或服务器的可读取存储介质中，该程序在执行时执行上述方法中的对应步骤。所述的存储介质可以如：ROM/RAM、磁碟、光盘等。

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

Claims (14)

1.一种实现流媒体通信的方法，其特征在于，应用于客户端，包括：

发送流媒体会话建立请求，所述请求中携带有流媒体传输协商请求信息；

接收服务器端返回的响应，从所述响应中获得流媒体传输协商确认信息，所述协商确认信息至少包含当前流媒体类型与当前流媒体传输所用的流标识之间的对应关系；

发送播放请求；

接收服务器返回的流媒体数据，所述流媒体数据中携带有用于传输所述流媒体数据所用的流控制传输协议SCTP偶联的流对应的流标识；

根据所述流媒体数据中的流标识和所述流标识与流媒体类型的对应关系，确定所述流媒体数据的类型；

在所述发送流媒体会话建立请求之前，进一步包括：对应于每一个流媒体会话，建立一条SCTP偶联，并预先设置用于传输控制数据的所述SCTP偶联中流对应的流标识；此时，

所述发送流媒体会话建立请求包括：在与所述请求所属的流媒体会话对应的SCTP偶联中的所述预先设置的流标识对应的流上发送进一步携带有所述预先设置的流标识的流媒体会话建立请求；

所述接收服务器端返回的响应包括：从与所述响应所属的流媒体会话对应的SCTP偶联中的所述预先设置的流标识对应的流上接收进一步携带有所述预先设置的流标识的响应；

所述发送播放请求包括：在与所述请求所属的流媒体会话对应的SCTP偶联中的所述预先设置的流标识对应的流上发送携带有所述预先设置的流标识的播放请求；

或者，在所述发送流媒体会话建立请求之前，进一步包括：建立一条供多个流媒体会话共用的SCTP偶联，并设置各个流媒体会话与所述共用的SCTP偶联的各个流标识之间的对应关系，所述各个流标识对应的流分别用于传输对应的流媒体会话的控制数据；此时，

所述发送流媒体会话建立请求包括：根据所述设置的对应关系确定与所述请求所属的流媒体会话对应的流标识，在所述共用的SCTP偶联中所述确定的流标识对应的流上发送进一步携带有所述确定的流标识的流媒体会话建立请求；

所述接收服务器端返回的响应包括：根据所述设置的对应关系确定与所述响应所属的流媒体会话对应的流标识，从所述共用的SCTP偶联中所述确定的流标识对应的流上接收进一步携带有所述确定的流标识的响应；

所述发送播放请求包括：根据所述设置的对应关系确定与所述请求所属的流媒体会话对应的流标识，在所述共用的SCTP偶联中所述确定的流标识对应的流上发送进一步携带有所述流标识的播放请求。

2.根据权利要求1所述的方法，其特征在于，所述接收进一步携带有所述流标识的响应的步骤后，进一步包括：

根据所述响应中携带的流标识和预先设置的用于传输控制数据的流标识的匹配结果，确定所述接收到的响应是否为控制数据。

3.根据权利要求1所述的方法，其特征在于，所述协商请求信息中包含：客户端推荐的用于传输当前流媒体数据所属SCTP偶联的流标识；

所述协商确认信息中包含：服务器端协商确认的用于传输当前流媒体数据所属SCTP偶联的流标识。

4.根据权利要求3所述的方法，其特征在于，所述协商请求信息中进一步包含：表示采用已经建立的SCTP偶联进行传输的信息、或表示采用新建的SCTP偶联进行传输的信息；

所述协商确认信息中进一步包含：表示采用已经建立的SCTP偶联进行传输的信息、或表示采用新建的SCTP偶联进行传输的信息。

5.根据权利要求4所述的方法，其特征在于，若所述协商确认信息中包含表示采用已经建立的SCTP偶联进行传输的信息，则所述接收服务器返回的流媒体数据包括：从已经建立的SCTP偶联中协商确认的流标识对应的流上接收服务器端返回的流媒体数据。

6.根据权利要求4所述的方法，其特征在于，若所述协商确认信息中包含表示采用新建的SCTP偶联进行传输的信息，则在接收服务器端返回的响应之后，进一步包括：对应所述流媒体会话，建立新的SCTP偶联；

所述接收服务器返回的流媒体数据包括：从所述新的SCTP偶联中协商确认的流标识对应的流上接收服务器端返回的流媒体数据。

7.一种实现流媒体通信的方法，其特征在于，应用于服务器端，包括：

接收流媒体会话建立请求，所述请求中携带有流媒体传输协商请求信息；

根据本端能力和所述协商请求信息，确定流媒体传输协商确认信息，所述协商确认信息至少包含当前流媒体类型与当前流媒体传输所用的流标识之间的对应关系，并返回与所述流媒体会话建立请求对应的响应，所述响应中携带有所述协商确认信息；

接收播放请求；

通过所述协商确认的当前流媒体传输所用的流标识对应的流传输相应的流媒体数据，所述流媒体数据中包含用于传输所述流媒体数据所用的流控制传输协议SCTP偶联的流对应的流标识；

在所述接收流媒体会话建立请求之前，进一步包括：对应于每一个流媒体会话，建立一条SCTP偶联；此时，

所述接收流媒体会话建立请求包括：从与所述请求所属的流媒体会话对应的SCTP偶联中的流上接收进一步携带有客户端预先设置的第一流标识的流媒体会话建立请求；

所述返回响应包括：在与所述响应所属流媒体会话对应的SCTP偶联中所述携带于所述流媒体会话建立请求中的第一流标识对应的流上发送携带有所述第一流标识的响应；

所述接收播放请求包括：从与所述请求所属的流媒体会话对应的SCTP偶联中的所述第一流标识对应的流上接收携带有所述第一流标识的播放请求；

或者，在所述接收流媒体会话建立请求之前，进一步包括：建立一条供多个流媒体会话共用的SCTP偶联；此时，

所述接收流媒体会话建立请求包括：从所述共用的SCTP偶联中的流上接收进一步携带有客户端确定的第二流标识的流媒体会话建立请求；

所述返回响应包括：在所述共用的SCTP偶联中所述携带的第二流标识对应的流上发送进一步携带有所述第二流标识的响应；

所述接收播放请求包括：从所述共用的SCTP偶联中的流上接收携带有所述第二流标识的播放请求。

8.根据权利要求7所述的方法，其特征在于，所述协商请求信息中包含：客户端推荐的用于传输当前流媒体数据所属SCTP偶联的第三流标识；

所述根据本端能力和所述协商请求信息，确定流媒体传输协商确认信息的步骤包括：

根据本端能力和该流媒体会话建立请求中的客户端推荐的用于传输当前流媒体数据的第三流标识，协商确认用于传输当前流媒体数据所属SCTP偶联的流标识，所述流标识为所述第三流标识或者服务器端重新分配的第四流标识，得到包含当前流媒体类型与当前流媒体传输所用的流标识的对应关系的协商确认信息。

9.根据权利要求8所述的方法，其特征在于，所述协商请求信息中包含：表示采用已经建立的SCTP偶联进行传输的信息、或表示采用新建的SCTP偶联进行传输的信息；

所述根据本端能力和所述协商请求信息，确定协商确认信息包括：根据本端能力和所述协商请求信息，确定采用已经建立的SCTP偶联中所述客户端推荐的第三流标识或者服务器端重新分配的第四流标识用于传输，得到包含当前媒体流类型与当前媒体流传输所用的流标识的对应关系以及表示媒体传输所用的SCTP偶联的信息的协商确认信息；

或者，根据本端能力和所述协商请求信息，确定采用新建的SCTP偶联中所述客户端推荐的第三流标识或者服务器端重新分配的第四流标识用于传输，得到包含当前媒体流类型与当前媒体流传输所用的流标识的对应关系以及表示媒体传输所用的SCTP偶联的信息的协商确认信息。

10.根据权利要求9所述的方法，其特征在于，若所述协商确认信息为采用已经建立的SCTP偶联进行传输，则所述通过协商确认的流标识对应的流传输相应的流媒体数据包括：在所述已经建立的SCTP偶联中协商确认的流标识对应的流上传输流媒体数据。

11.根据权利要求9所述的方法，其特征在于，若所述协商确认信息为采用新建的SCTP偶联进行传输，则在所述返回响应之后，进一步包括：对应所述流媒体会话，重新建立新的SCTP偶联；

所述通过协商确认的流标识对应的流传输相应的流媒体数据包括：在所述新的SCTP偶联中协商确认的流标识对应的流上传输流媒体数据。

12.一种客户端，其特征在于，包括：

第一会话管理模块，用于构造携带有流媒体传输协商请求信息的流媒体会话建立请求，并从对应于所述流媒体会话建立请求的响应中获得流媒体传输协商确认信息，所述协商确认信息至少包含当前流媒体类型与当前流媒体传输所用的流标识之间的对应关系；

第一播放处理模块，用于构造播放请求，并根据接收的流媒体数据中携带的用于传输所述流媒体数据所用的流控制传输协议SCTP偶联的流对应的流标识，以及所述流标识与流媒体类型的对应关系，确定所述接收的流媒体数据的类型；

第一通信模块，用于发送所述流媒体会话建立请求和播放请求，并用于接收来自服务器端的对应于所述流媒体会话建立请求的响应和对应于所述播放请求的流媒体数据；

第一确定单元，用于根据所述第一通信模块接收的所述响应中携带的流标识和预先设置的用于传输控制数据的流标识的匹配结果，确定所述接收到的响应是否为控制数据。

13.一种服务器，其特征在于，包括：

第二会话管理模块，用于从接收的流媒体会话建立请求中获取流媒体传输协商请求信息，所述流媒体传输协商请求信息包含客户端推荐的用于传输当前流媒体数据所属SCTP偶联的第三流标识；根据本端能力和该流媒体会话建立请求中的客户端推荐的所述第三流标识，协商得到包含当前流媒体类型与当前流媒体传输所用流标识的对应关系的协商确认信息，其中所述流标识为所述第三流标识或者重新分配的第四流标识；

第二播放处理模块，用于在接收到播放请求后，确定待发送的流媒体数据；

第二通信模块，用于接收所述流媒体会话建立请求和播放请求，并用于发送对应于所述流媒体会话建立请求的响应和对应于所述播放请求的流媒体数据，其中所述响应携带有所述协商确认信息，所述流媒体数据携带有用于传输所述流媒体数据所用的流控制传输协议SCTP偶联的流对应的流标识。

14.一种实现流媒体通信的系统，其特征在于，包括如权利要求12所述客户端和如权利要求13所述服务器。

Images