WO2015180570A1 - 数据通道建立方法和通信设备 - Google Patents

数据通道建立方法和通信设备 Download PDF

Info

Publication number
WO2015180570A1
WO2015180570A1 PCT/CN2015/078972 CN2015078972W WO2015180570A1 WO 2015180570 A1 WO2015180570 A1 WO 2015180570A1 CN 2015078972 W CN2015078972 W CN 2015078972W WO 2015180570 A1 WO2015180570 A1 WO 2015180570A1
Authority
WO
WIPO (PCT)
Prior art keywords
data channel
mode
attribute line
response
receiving end
Prior art date
Application number
PCT/CN2015/078972
Other languages
English (en)
French (fr)
Inventor
刘艳
杨玮玮
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2015180570A1 publication Critical patent/WO2015180570A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication

Abstract

本发明公开了一种数据通道建立方法和通信设备，属于网络通信领域。所述方法包括：发送端向接收端发送携带有第一提议属性行和第二提议属性行的提议消息；接收应答消息，应答消息是接收端根据第一提议属性行、第二提议属性行和接收端支持的数据通道协商方式确定的；根据应答消息与接收端建立数据通道。本发明解决了当通信两端中的至少一端同时支持两种或者两种以上的数据通道协商方式时，通信两端就无法协商建立数据通道的问题。当两端中至少一端支持两种或两种以上数据通道协商方式时，通过两端对数据通道协商方式的协商，并在此基础上建立数据通道，使得两端能够简单、高效地建立数据通道，实现了不同终端、不同网络之间的互连互通。

Description

数据通道建立方法和通信设备
本申请要求了2014年5月29日提交的、申请号为201410232844.9、发明名称为“数据通道建立方法和通信设备”的中国申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本发明涉及网络通信领域，特别涉及一种数据通道建立方法和通信设备。
背景技术
SCTP(Stream Control Transmission Protocol，流控制传输协议)是IETF(Internet Engineering Task Force，互联网工程任务组)定义的一种可靠的传输层协议，它在两个SCTP端点之间提供稳定、有序的数据传输服务。SCTP端点是SCTP分组中逻辑的接收方或发送方，两个SCTP端点之间存在一个SCTP偶联。一个SCTP偶联下可以有多个SCTP流，且每个SCTP流都有唯一的流标识。其中，SCTP流是从两个SCTP端点之间建立的一个单向逻辑通道，而数据通道则是包含一对出入流的双向逻辑通道，且该对出入流拥有相同的流标识。
数据通道提供一种传输通道，允许两个SCTP端点在数据通道之上采用数据协议进行数据传输。在协商数据通道的过程中，两个SCTP端点需要经过至少一次的协商以建立SCTP偶联，确定数据通道所关联的流标识、数据通道所对应的标签以及在数据通道上采用的数据协议等内容，并在此基础上建立数据通道。IETF定义了两种数据通道协商方式。其中，一种是基于带内的采用DCEP(Data Channel Establishment Protocol，数据通道建立协议)方式，另一种是基于带外的采用SDP(Session Description Protocol，会话描述协议)方式。
DCEP方式主要用于在两个基于浏览器的终端之间协商建立数据通道。基于浏览器的终端是指采用WebRTC(Web Real-Time Communication，网页实时通信)技术实现实时通信的终端，该实时通信可以包括语音通话、视频通话、文档共享、消息收发等实时的信息交互。
SDP方式主要用于在传统终端与媒体网关之间、或者传统终端与传统终端之间协商建立数据通道。传统终端与基于浏览器的终端相对应，是指并不采用WebRTC技术实现通信的终端。
在实现本发明的过程中，发明人发现上述技术至少存在以下问题：在上述技术中，只能够实现当通信两端均只采用一种数据通道协商方式且该数据通道协商方式为相同的方式时，通信两端采用该数据通道协商方式协商建立数据通道。然而，从未来发展的角度，为了实现基于浏览器的终端与传统终端之间、或者基于浏览器的终端与媒体网关之间协商建立数据通道，通信两端中的至少一端需要同时支持两种或者两种以上的数据通道协商方式。但是，上述技术并未给出相关的解决方案，也即当通信两端中的至少一端同时支持两种或者两种以上的数据通道协商方式时，通信两端就无法协商建立数据通道。
发明内容
为了解决背景技术中存在的当通信两端中的至少一端同时支持两种或者两种以上的数据通道协商方式时，通信两端就无法协商建立数据通道的问题，本发明实施例提供了一种数据通道建立方法和通信设备。所述技术方案如下：
第一方面，提供了一种数据通道建立方法，所述方法包括：
发送端向接收端发送携带有第一提议属性行和第二提议属性行的提议消息；其中，所述第一提议属性行包括所述发送端支持的数据通道协商方式的信息，所述第二提议属性行包括本次请求的数据通道协商方式的信息，所述本次请求的数据通道协商方式为所述发送端支持的数据通道协商方式中的一种；
发送端接收所述接收端发送的应答消息，所述应答消息是所述接收端根据所述第一提议属性行、所述第二提议属性行以及所述接收端支持的数据通道协商方式确定的；
发送端根据所述应答消息与所述接收端之间建立数据通道；
其中，所述发送端和所述接收端中的至少一端支持两种或者两种以上数据通道协商方式。
在第一方面的第一种可能的实施方式中，所述发送端和所述接收端中的一端支持的数据通道协商方式包括数据通道建立协议DCEP方式和会话描述协议SDP方式，且另一端支持的数据通道协商方式包括所述DCEP方式和所述SDP方式中的至少一种。
结合第一方面或者第一方面的第一种可能的实施方式，在第一方面的第二种可能的实施方式中，所述提议消息还包括第三提议属性行，所述第三提议属 性行包括所述发送端在所述数据通道上支持的数据协议的信息，以便所述接收端根据所述第三提议属性行和所述接收端在所述数据通道上支持的数据协议确定出两端在所述数据通道上均支持的数据协议。
结合第一方面的第一种可能的实施方式或者第一方面的第二种可能的实施方式，在第一方面的第三种可能的实施方式中，所述发送端根据所述应答消息与所述接收端之间建立数据通道，包括：
当所述应答消息中携带有对应于所述第二提议属性行的第二应答属性行时，通过所述SDP方式与所述接收端之间建立所述数据通道；
其中，所述第二应答属性行是所述接收端确定同意采用的数据通道协商方式为所述SDP方式时生成的。
结合第一方面的第一种可能的实施方式或者第一方面的第二种可能的实施方式，在第一方面的第四种可能的实施方式中，所述发送端根据所述应答消息与所述接收端之间建立数据通道，包括：
当所述应答消息中未携带有对应于所述第二提议属性行的第二应答属性行时，根据所述应答消息中携带的对应于所述第一提议属性行的第一应答属性行检测两端是否均支持所述DCEP方式；
若检测出两端均支持所述DCEP方式，则通过所述DCEP方式与所述接收端之间建立所述数据通道。
结合第一方面的第二种可能的实施方式，在第一方面的第五种可能的实施方式中，所述发送端接收所述接收端发送的应答消息之后，还包括：
发送端读取所述应答消息中携带的对应于所述第三提议属性行的第三应答属性行，所述第三应答属性行是所述接收端根据所述第三提议属性行和所述接收端在所述数据通道上支持的数据协议确定出两端在所述数据通道上均支持的数据协议后生成的；
发送端根据所述第三应答属性行确定在所述数据通道上传输的数据协议。
第二方面，提供了一种数据通道建立方法，所述方法包括：
接收端接收发送端发送的携带有第一提议属性行和第二提议属性行的提议消息；其中，所述第一提议属性行包括所述发送端支持的数据通道协商方式的信息，所述第二提议属性行包括本次请求的数据通道协商方式的信息，所述本次请求的数据通道协商方式为所述发送端支持的数据通道协商方式中的一种；
接收端根据所述第一提议属性行、所述第二提议属性行以及接收端支持的数据通道协商方式确定应答消息；
接收端向所述发送端发送所述应答消息，以便所述发送端根据所述应答消息与所述接收端之间建立数据通道；
其中，所述接收端和所述发送端中的至少一端支持两种或者两种以上数据通道协商方式。
第三方面，提供了一种通信设备，所述通信设备包括：
发送模块，用于向接收端发送携带有第一提议属性行和第二提议属性行的提议消息；其中，所述第一提议属性行包括所述发送端支持的数据通道协商方式的信息，所述第二提议属性行包括本次请求的数据通道协商方式的信息，所述本次请求的数据通道协商方式为所述发送端支持的数据通道协商方式中的一种；
应答接收模块，用于接收所述接收端发送的应答消息，所述应答消息是所述接收端根据所述第一提议属性行、所述第二提议属性行以及所述接收端支持的数据通道协商方式确定的；
通道建立模块，用于根据所述应答消息与所述接收端之间建立数据通道；
其中，所述发送端和所述接收端中的至少一端支持两种或者两种以上数据通道协商方式。
第四方面，提供了一种通信设备，所述通信设备包括：
接收模块，用于接收发送端发送的携带有第一提议属性行和第二提议属性行的提议消息；其中，所述第一提议属性行包括所述发送端支持的数据通道协商方式的信息，所述第二提议属性行包括本次请求的数据通道协商方式的信息，所述本次请求的数据通道协商方式为所述发送端支持的数据通道协商方式中的一种；
应答确定模块，用于根据所述第一提议属性行、所述第二提议属性行以及接收端支持的数据通道协商方式确定应答消息；
应答发送模块，用于向所述发送端发送所述应答消息，以便所述发送端根据所述应答消息与所述接收端之间建立数据通道；
其中，所述接收端和所述发送端中的至少一端支持两种或者两种以上数据通道协商方式。
本发明实施例提供的技术方案带来的有益效果是：
通过发送端向接收端发送携带有第一提议属性行和第二提议属性行的提议消息，接收接收端发送的应答消息，该应答消息是接收端根据第一提议属性行、第二提议属性行以及接收端支持的数据通道协商方式确定的，并根据应答消息与接收端之间建立数据通道；解决了当通信两端中的至少一端同时支持两种或者两种以上的数据通道协商方式时，通信两端就无法协商建立数据通道的问题；当两端中的至少一端支持两种或两种以上数据通道协商方式时，通过两端对数据通道协商方式的协商确定，进而在此基础上完成数据通道的建立，使得两端能够简单、高效地建立数据通道，实现了不同终端、不同网络之间的互连互通。
附图说明
为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是本发明各个实施例所涉及的一种实施环境的结构示意图；
图2是本发明一个实施例提供的数据通道建立方法的方法流程图；
图3是本发明另一实施例提供的数据通道建立方法的方法流程图；
图4是本发明再一实施例提供的数据通道建立方法的方法流程图；
图5是本发明还一实施例提供的数据通道建立方法的方法流程图；
图6是本发明一个实施例提供的通信设备的结构方框图；
图7是本发明另一实施例提供的通信设备的结构方框图；
图8是本发明再一实施例提供的通信设备的结构方框图；
图9是本发明还一实施例提供的通信设备的结构方框图；
图10是本发明一个实施例所提供的发送端的结构示意图；
图11是本发明一个实施例所提供的接收端的结构示意图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。
发明人发现：当两端中至少一端同时支持两种或者两种以上的数据通道协商方式时，两端之间需要通过协商确定最终采用的数据通道协商方式，并在此基础上采用协商确定的数据通道协商方式完成数据通道的建立。下面，将通过具体的实施例对本发明提供的技术方案进行详细介绍和说明。
请参考图1，其示出了本发明各个实施例所涉及的一种实施环境的结构示意图。该实施环境包括：发送端120和接收端140。
发送端120和接收端140可以同为基于浏览器的终端，也可以同为传统终端，还可以一端为基于浏览器的终端且另一端为传统终端。在上述情况下，发送端120和接收端140之间可以通过有线网络或者无线网络相连。
或者，当发送端120或者接收端140中的一端为媒体网关时，另一端可以是基于浏览器的终端或者传统终端。
其中，基于浏览器的终端是指采用WebRTC技术实现实时通信的终端，该实时通信可以包括语音通话、视频通话、文档共享、消息收发等实时的信息交互；而传统终端与基于浏览器的终端相对应，是指并不采用WebRTC技术实现通信的终端。上述终端设备可以是手机、平板电脑、电子书阅读器、MP3(Moving Picture Experts Group Audio Layer III，动态影像专家压缩标准音频层面3)播放器、MP4(Moving Picture Experts Group Audio Layer IV，动态影像专家压缩标准音频层面4)播放器、膝上型便携计算机、台式计算机和会议终端等等。
需要说明的一点是：在图1所示的实施环境中，发送端120和接收端140的类型、数量以及连接关系仅是示例性的。在实际应用中，发送端120和接收端140即为协商建立数据通道以进行数据传输的通信两端，且两者的位置、功能可以互换。
另外，在本发明各个实施例中，所涉及的通信设备可以是上文介绍的终端设备，也可以是媒体网关，或者其它用于协商建立数据通道以进行数据传输的设备。
请参考图2，其示出了本发明一个实施例提供的数据通道建立方法的方法流程图，本实施例以该数据通道建立方法应用于图1所示实施环境中的发送端侧来举例说明。该数据通道建立方法可以包括如下几个步骤：
步骤202，发送端向接收端发送携带有第一提议属性行和第二提议属性行的提议消息。
其中，第一提议属性行包括发送端支持的数据通道协商方式的信息，第二提议属性行包括本次请求的数据通道协商方式的信息，且本次请求的数据通道协商方式为发送端支持的数据通道协商方式中的一种。
其中，数据通道协商方式的信息，可以是明确的数据通道协商方式，也可以是能表明数据通道协商方式的信息，这里不限定具体形式。
步骤204，发送端接收接收端发送的应答消息，该应答消息是接收端根据第一提议属性行、第二提议属性行以及接收端支持的数据通道协商方式确定的。
步骤206，发送端根据应答消息与接收端之间建立数据通道。
其中，发送端和接收端中的至少一端支持两种或者两种以上数据通道协商方式。
可选的，发送端和接收端中的一端支持的数据通道协商方式包括DCEP方式和SDP方式，且另一端支持的数据通道协商方式包括DCEP方式和SDP方式中的至少一种。
可选的，若本次请求的数据通道协商方式为DCEP方式，则第二提议属性行还包括任意流标识符。该任意流标识符用于表示数据通道关联的流标识为任意的，以便接收端在确定出两端均支持的数据通道协商方式包括DCEP方式时，根据任意流标识符确定同意采用的数据通道协商方式为DCEP方式。或者，
若本次请求的数据通道协商方式为DCEP方式，则第二提议属性行还包括任意流标识符。该任意流标识符用于表示数据通道关联的流标识为任意的，以便接收端在确定出两端均支持的数据通道协商方式有且只有SDP方式时，生成包括数据通道关联的流标识为指定流标识符的第二应答属性行，该指定流标识符是接收端确定的。或者，
若本次请求的数据通道协商方式为SDP方式，则第二提议属性行还包括指定流标识符。该指定流标识符用于表示数据通道关联的流标识为指定的，以便接收端在确定出两端均支持的数据通道协商方式包括SDP方式时，根据指定流标识符确定同意采用的数据通道协商方式为SDP方式。或者，
若本次请求的数据通道协商方式为SDP方式，则第二提议属性行还包括指定流标识符。该指定流标识符用于表示数据通道关联的流标识为指定的，以便 接收端在确定出两端均支持的数据通道协商方式有且只有DCEP方式时，确定同意采用的数据通道协商方式为DCEP方式。
可选的，提议消息还包括第三提议属性行，该第三提议属性行包括发送端在数据通道上支持的数据协议的信息，以便接收端根据第三提议属性行和接收端在数据通道上支持的数据协议确定出两端在数据通道上均支持的数据协议。
可选的，该数据通道建立方法还可以包括：
第一，发送端根据发送端在数据通道上支持的数据协议对应的应用的数量a确定本次请求建立的数据通道的数量a，a≥1。其中，每种数据协议对应于至少一种应用。
本步骤可以包括如下两种可能的实现方式：
1、若本次请求的数据通道协商方式为DCEP方式，则生成a个第二提议属性行。其中，每个第二提议属性行包括一个流标识和一个标签，且不同的第二提议属性行中包括的流标识均为任意流标识符，不同的第二提议属性行中包括的标签为互不相同的标签，每个标签对应于一条数据通道。
2、若本次请求的数据通道协商方式为SDP方式，则生成a个第二提议属性行。其中，每个第二提议属性行包括一个流标识和一个标签，且不同的第二提议属性行中包括的流标识为互不相同的指定流标识符，不同的第二提议属性行中包括的标签为互不相同的标签，每个标签对应于一条数据通道。
第二，发送端根据本次请求的数据通道协商方式生成a个第二提议属性行。
可选的，第三提议属性行的确定过程可以包括如下几个步骤：
第一，对于发送端在数据通道上支持的每一个数据协议，发送端获取数据协议对应的应用的数量。
第二，发送端根据数据协议对应的应用的数量为数据协议分配相同数量的标签，每个标签为a个第二提议属性行中包括的a个互不相同的标签中的一个。
第三，发送端将数据协议对应的协议标识与数据协议所分配的标签进行关联。
第四，发送端生成包括各个数据协议对应的协议标识以及每个协议标识关联的标签的第三提议属性行。
可选的，上述步骤206可以包括如下两种可能的实现方式：
1、当应答消息中携带有对应于第二提议属性行的第二应答属性行时，通过 SDP方式与接收端之间建立数据通道。其中，第二应答属性行是接收端确定同意采用的数据通道协商方式为SDP方式时生成的。
2、当应答消息中未携带有对应于第二提议属性行的第二应答属性行时，根据应答消息中携带的对应于第一提议属性行的第一应答属性行检测两端是否均支持DCEP方式；若检测出两端均支持DCEP方式，则通过DCEP方式与接收端之间建立数据通道。
可选的，上述步骤204之后，还可以包括如下几个步骤：
第一，发送端读取应答消息中携带的对应于第三提议属性行的第三应答属性行。该第三应答属性行是接收端根据第三提议属性行和接收端在数据通道上支持的数据协议确定出两端在数据通道上均支持的数据协议后生成的。
第二，发送端根据第三应答属性行确定在数据通道上传输的数据协议。
综上所述，本实施例提供的数据通道建立方法，解决了当通信两端中的至少一端同时支持两种或者两种以上的数据通道协商方式时，通信两端就无法协商建立数据通道的问题；当两端中的至少一端支持两种或两种以上数据通道协商方式时，通过两端对数据通道协商方式的协商确定，进而在此基础上完成数据通道的建立，使得两端能够简单、高效地建立数据通道，实现了不同终端、不同网络之间的互连互通。
另外，通过在第二提议属性行中携带任意流标识符或者指定流标识符，可以使得接收端在确定采用SDP方式建立数据通道时，在应答消息中直接反馈数据通道关联的流标识，避免两端在后续过程中对流标识的进一步协商；或者，使得接收端在确定采用DCEP方式建立数据通道时，可以生成未携带有第二应答属性行的应答消息，之后发送端根据该应答消息通过DCEP方式与接收端之间建立数据通道。
另外，当提议消息中还包括第三提议属性行时，发送端和接收端在对数据通道协商方式进行协商的同时，还可对数据通道上传输的数据协议进行协商，发送端和接收端之间通过一次SDP会话即可完成数据通道协商方式的协商以及数据通道上传输的数据协议的协商，充分提高了数据通道建立的效率。
请参考图3，其示出了本发明另一实施例提供的数据通道建立方法的方法流程图，本实施例以该数据通道建立方法应用于图1所示实施环境中的接收端侧 来举例说明。该数据通道建立方法可以包括如下几个步骤：
步骤302，接收端接收发送端发送的携带有第一提议属性行和第二提议属性行的提议消息。
其中，第一提议属性行包括发送端支持的数据通道协商方式的信息，第二提议属性行包括本次请求的数据通道协商方式的信息，且本次请求的数据通道协商方式为发送端支持的数据通道协商方式中的一种。
步骤304，接收端根据第一提议属性行、第二提议属性行以及接收端支持的数据通道协商方式确定应答消息。
步骤306，接收端向发送端发送应答消息，以便发送端根据应答消息与接收端之间建立数据通道。
其中，接收端和发送端中的至少一端支持两种或者两种以上数据通道协商方式。
可选的，该数据通道建立方法还可以包括如下步骤：
1、当提议消息中还包括第三提议属性行时，接收端根据第三提议属性行和接收端在数据通道上支持的数据协议检测是否存在两端在数据通道上均支持的数据协议；其中，第三提议属性行是发送端根据发送端在数据通道上支持的数据协议生成的。
2、若检测出存在两端在数据通道上均支持的数据协议，则接收端根据两端在数据通道上均支持的数据协议生成对应于第三提议属性行的第三应答属性行，以便发送端根据第三应答属性行确定在数据通道上传输的数据协议。
综上所述，本实施例提供的数据通道建立方法，解决了当通信两端中的至少一端同时支持两种或者两种以上的数据通道协商方式时，通信两端就无法协商建立数据通道的问题；当两端中的至少一端支持两种或两种以上数据通道协商方式时，通过两端对数据通道协商方式的协商确定，进而在此基础上完成数据通道的建立，使得两端能够简单、高效地建立数据通道，实现了不同终端、不同网络之间的互连互通。
另外，当提议消息中还包括第三提议属性行时，发送端和接收端在对数据通道协商方式进行协商的同时，还可对数据通道上传输的数据协议进行协商，发送端和接收端之间通过一次SDP会话即可完成数据通道协商方式的协商以及数据通道上传输的数据协议的协商，充分提高了数据通道建立的效率。
请参考图4，其示出了本发明再一实施例提供的数据通道建立方法的方法流程图，本实施例以该数据通道建立方法应用于图1所示实施环境中来举例说明。该数据通道建立方法可以包括如下几个步骤：
步骤401，发送端向接收端发送携带有第一提议属性行和第二提议属性行的提议消息。
发送端与接收端之间可以采用SDP会话进行数据通道的协商，该SDP会话通常表现为SDP Offer/SDP Answer(SDP提议/SDP应答)的形式。提议消息(也即SDP Offer)可以包括如下3个提议属性行：
m＝application 54111DTLS/SCTP 5000
c＝IN IP479.97.215.79
a＝sctpmap:5000datachannel max-message-size＝100000streams＝16
其中，“m＝”行用于表示媒体类型和媒体流的发送端口；“c＝”行用于表示连接信息；“a＝”行为会话属性行，一个SDP Offer可以包括0个或者多个会话属性行。
另外，在本实施例提供的数据通道建立方法中，为了实现两端对采用何种数据通道协商方式的协商，提议消息中还包括第一提议属性行和第二提议属性行。
第一提议属性行包括发送端支持的数据通道协商方式的信息。在本发明各个实施例中，发送端和接收端中的至少一端支持两种或者两种以上数据通道协商方式。第一提议属性行中包括的信息可以是明确的携带有发送端支持的数据通道协商方式对应的标识的信息，也可以是能够表明发送端支持的数据通道协商方式的其它任何形式的信息，对此本实施例不作具体限定。
另外，在本实施例中，以发送端支持的数据通道协商方式为DCEP方式以及SDP方式中的任意一种或者全部两种来举例说明，在其它可能的实施例中，发送端还可能支持其它数据通道协商方式，对此本实施例不作具体限定。
第二提议属性行包括本次请求的数据通道协商方式的信息，本次请求的数据通道协商方式为发送端支持的数据通道协商方式中的一种。第二提议属性行中包括的信息通常包括相关用于建立数据通道的参数，比如SCTP端口号、数据通道关联的流标识、数据通道对应的标签以及最大重传次数等等。
具体地，以第一提议属性行中包括的信息为携带有DCEP方式和/或SDP方式对应的标识的信息为例，提议消息的确定过程可以包括如下几个步骤：
第一，根据发送端支持的数据通道协商方式确定本次请求的数据通道协商方式。
本次请求的数据通道协商方式为发送端支持的数据通道协商方式中的一种。当发送端支持的数据通道协商方式为DCEP方式时，本次请求的数据通道协商方式即为DCEP方式；当发送端支持的数据通道协商方式为SDP方式时，本次请求的数据通道协商方式即为SDP方式；当发送端支持的数据通道协商方式为DCEP方式以及SDP方式时，发送端可任意选取一种数据通道协商方式作为本次请求的数据通道协商方式。
第二，根据发送端支持的数据通道协商方式确定第一提议属性行。
1、若发送端支持的数据通道协商方式为DCEP方式和SDP方式，则第一提议属性行包括第一标识和第二标识。
其中，第一标识与DCEP方式相对应，第二标识与SDP方式相对应。
在本实施例中，假设以“dynamic”表示第一标识，“static”表示第二标识，则当发送端同时支持两种数据通道协商方式时，第一提议属性行可以为：
a＝assignstreamid:static；dynamic
2、若发送端支持的数据通道协商方式为DCEP方式，则第一提议属性行包括第一标识。
比如，第一提议属性行可以为：a＝assignstreamid:dynamic
3、若发送端支持的数据通道协商方式为SDP方式，则第一提议属性行包括第二标识。
比如，第一提议属性行可以为：a＝assignstreamid:static
第三，根据本次请求的数据通道协商方式确定第二提议属性行。
1、若本次请求的数据通道协商方式为DCEP方式，则第二提议属性行包括任意流标识符。
其中，任意流标识符用于表示本次请求建立的数据通道关联的流标识为任意的，其可由接收端在后续应答过程中选定一个未被使用的流标识作为数据通道关联的流标识，也可在后续过程中以DCEP Open消息的形式进一步协商确定数据通道关联的流标识。
在本实施例中，假设以“*”表示任意流标识符。发送端生成的第二提议属性行除了包括数据通道关联的流标识之外，通常还包括SCTP端口号、数据通道对应的标签以及最大重传次数等参数。因此，第二提议属性行可以为：
a＝dcmap:5000stream＝*；label＝"channel 2"；max_retr＝3
其中，“5000”表示SCTP端口号；“stream＝*”表示数据通道关联的流标识为任意流标识符；“label＝"channel 2"”表示数据通道对应的标签为channel 2；“max_retr＝3”表示最大重传次数为3。
若第二提议属性行包括任意流标识符，可以使得接收端在后续过程中确定采用SDP方式建立数据通道时，在应答消息中直接反馈数据通道关联的流标识，避免两端在后续过程中对流标识的进一步协商。
2、若本次请求的数据通道协商方式为SDP方式，则第二提议属性行包括指定流标识符。
其中，指定流标识符用于表示数据通道关联的流标识为指定的。当发送端请求SDP方式协商建立数据通道时，发送端为请求建立的数据通道选定一个未被使用的流标识。指定流标识符可以是1、2、3、……、n中的任意整数，n≥1。
在本实施例中，假设指定流标识符为“2”，则第二提议属性行可以为：
a＝dcmap:5000stream＝2；label＝"channel 2"；max_retr＝3
上述第二和第三两个步骤可以同时进行，也可以先后进行，本实施例不作具体限定。
第四，生成携带有第一提议属性行和第二提议属性行的提议消息。
发送端在确定第一提议属性行和第二提议属性行之后，生成携带有第一提议属性行和第二提议属性行的提议消息。
比如，发送端生成的提议消息可以包括：
m＝application 54111DTLS/SCTP 5000
c＝IN IP479.97.215.79
a＝sctpmap:5000datachannel max-message-size＝100000streams＝16
a＝assignstreamid:static；dynamic
a＝dcmap:5000stream＝*；label＝"channel 2"；max_retr＝3
之后，发送端向接收端发送携带有第一提议属性行和第二提议属性行的提议消息。
对应地，接收端接收发送端发送的携带有第一提议属性行和第二提议属性行的提议消息。
步骤402，接收端根据第一提议属性行、第二提议属性行以及接收端支持的数据通道协商方式确定应答消息。
其中，接收端和发送端中的至少一端支持两种或者两种以上数据通道协商方式。在本实施例中，以接收端支持的数据通道协商方式为DCEP方式以及SDP方式中的任意一种或者全部两种来举例说明，在其它可能的实施例中，发送端还可能支持其它数据通道协商方式，对此本实施例不作具体限定。
应答消息(也即SDP Answer)与提议消息(也即SDP Offer)相对应，应答消息是接收端根据发送端发送的提议消息做出的应答。在SDP会话机制中规定，应答消息中携带的“a＝”行数量不得超过提议消息中携带的“a＝”行数量。
具体地，本步骤可以包括如下几个子步骤：
第一，根据第一提议属性行和接收端支持的数据通道协商方式确定两端均支持的数据通道协商方式。
第一提议属性行包括发送端支持的数据通道协商方式的信息。以第一提议属性行中包括的信息为携带有DCEP方式和/或SDP方式对应的标识的信息为例，接收端读取第一提议属性行中的信息，若第一提议属性行包括第一标识，则说明发送端支持的数据通道协商方式为DCEP方式；若第一提议属性行包括第二标识，则说明发送端支持的数据通道协商方式为SDP方式；若第一提议属性行包括第一标识和第二标识，则说明发送端支持的数据通道协商方式为DCEP方式和SDP方式。之后，接收端根据发送端支持的数据通道协商方式和接收端支持的数据通道协商方式确定出两端均支持的数据通道协商方式。
第二，若两端均支持的数据通道协商方式有且只有DCEP方式，则确定同意采用的数据通道协商方式为DCEP方式，并生成携带有第一应答属性行的应答消息。
当两端均支持的数据通道协商方式有且只有DCEP方式时，接收端同意采用DCEP方式与发送端之间建立数据通道。在这种情况下，接收端生成携带有第一应答属性行的应答消息，以便发送端在后续过程中根据第一应答属性行检测出两端均支持DCEP方式后，通过DCEP方式与接收端之间建立数据通道。
第一应答属性行与第一提议属性行对应，第一应答属性行包括接收端支持 的数据通道协商方式的信息。该信息可以是明确的携带有DCEP方式和/或SDP方式对应的标识的信息，也可以是能够表明接收端支持的数据通道协商方式的其它任何形式的信息，对此本实施例不作具体限定。
以第一应答属性行中包括的信息为携带有DCEP方式和/或SDP方式对应的标识的信息为例，第一应答属性行的确定过程可以如下：
1、若接收端支持的数据通道协商方式为DCEP方式和SDP方式，则第一应答属性行包括第一标识和第二标识。
其中，第一标识与DCEP方式相对应，第二标识与SDP方式相对应。
仍然以“dynamic”表示第一标识，“static”表示第二标识。当接收端同时支持两种数据通道协商方式时，第一应答属性行可以为：
a＝assignstreamid:static；dynamic
2、若接收端支持的数据通道协商方式为DCEP方式，则第一应答属性行包括第一标识。
比如，第一应答属性行可以为：a＝assignstreamid:dynamic
3、若接收端支持的数据通道协商方式为SDP方式，则第一应答属性行包括第二标识。
比如，第一应答属性行可以为：a＝assignstreamid:static
因此，当确定同意采用的数据通道协商方式为DCEP方式时，应答消息可以包括：
c＝IN IP479.97.215.79
a＝sctpmap:5000datachannel max-message-size＝100000streams＝16
a＝assignstreamid:dynamic
其中，第一应答属性行“a＝assignstreamid:dynamic”表示接收端支持的数据通道协商方式为DCEP方式。
第三，若两端均支持的数据通道协商方式有且只有SDP方式，则确定同意采用的数据通道协商方式为SDP方式，并生成携带有第一应答属性行和第二应答属性行的应答消息。
其中，第一应答属性行与第一提议属性行对应，第一应答属性行包括接收端支持的数据通道协商方式的信息。第二应答属性行与第二提议属性行对应，第二应答属性行包括接收端同意采用的数据通道协商方式的信息，该信息通常 包括相关用于建立数据通道的参数，比如SCTP端口号、数据通道关联的流标识、数据通道对应的标签以及最大重传次数等等。接收端生成携带有第一应答属性行和第二应答属性行的应答消息，以便发送端在后续过程中读取第二应答属性行后，通过SDP方式与接收端之间建立数据通道。
第二应答属性行还包括指定流标识符。当第二提议属性行中的流标识为任意流标识符时，第二应答属性行中的指定流标识符是接收端确定的；当第二提议属性行中的流标识为指定流标识符时，第二应答属性行中的指定流标识符即为第二提议属性行中的指定流标识符。
比如，当第二提议属性行为：a＝dcmap:5000stream＝*；label＝"channel 2"；max_retr＝3时，对应的第二应答属性行可以为：a＝dcmap:5000stream＝2；label＝"channel 2"；max_retr＝3。
之后，接收端生成携带有第一应答属性行和第二应答属性行的应答消息。该应答消息可以包括：
c＝IN IP479.97.215.79
a＝sctpmap:5000datachannel max-message-size＝100000streams＝16
a＝assignstreamid:static
a＝dcmap:5000stream＝2；label＝"channel 2"；max_retr＝3
接收端通过在应答消息中直接反馈数据通道关联的流标识，可以避免两端在后续过程中对流标识的进一步协商，使得发送端接收到应答消息之后，可以直接根据应答消息中携带的第二应答属性行与接收端之间通过SDP方式建立数据通道，减少两端信息交互的次数，提高数据通道建立的效率；同时，还可避免因信息交互过程中可能存在的信息丢失、或者收发延时等问题导致的协商失败，充分提高数据通道建立的成功率。
另外，当第二提议属性行包括指定流标识符时，第二应答属性行中包括的指定流标识符与第二提议属性行中的指定流标识符相同。
比如，当第二提议属性行为：a＝dcmap:5000stream＝2；label＝"channel 2"；max_retr＝3时，对应的第二应答属性行即为：a＝dcmap:5000stream＝2；label＝"channel 2"；max_retr＝3。
第四，若两端均支持的数据通道协商方式为DCEP方式和SDP方式，则判断第二提议属性行中包括的数据通道关联的流标识为任意流标识符还是指定流 标识符；若为任意流标识符，则确定同意采用的数据通道协商方式为DCEP方式，并生成携带有第一应答属性行的应答消息；若为指定流标识符，则确定同意采用的数据通道协商方式为SDP方式，并生成携带有第一应答属性行和第二应答属性行的应答消息。
其中，第二提议属性行中的任意流标识符表示发送端本次请求的数据通道协商方式为DCEP方式，第二提议属性行中的指定流标识符表示发送端本次请求的数据通道协商方式为SDP方式。当两端均支持的数据通道协商方式为DCEP方式和SDP方式时，接收端根据发送端请求的数据通道协商方式确定最终采用的数据通道协商方式。
步骤403，接收端向发送端发送应答消息。
对应地，发送端接收接收端发送的应答消息。
步骤404，发送端根据应答消息与接收端之间建立数据通道。
具体地，本步骤可以包括如下两种可能的实现方式：
在第一种可能的实现方式中，当应答消息中携带有对应于第二提议属性行的第二应答属性行时，通过SDP方式与接收端之间建立数据通道。
其中，第二应答属性行是接收端确定同意采用的数据通道协商方式为SDP方式时生成的。发送端可根据第二应答属性行中包括的数据通道关联的流标识、数据通道对应的标签等参数直接与接收端之间建立数据通道。
进一步地，可在该数据通道之上传输诸如MSRP(Message Session Relay Protocol，消息会话中继协议)或者CLUE(Controlling Multiple Streams for Telepresence，用于智真的多流控制协议)之类的数据协议，实现语音通话、视频通话、文档共享、消息收发、视频会议等实时的信息交互。
在第二种可能的实现方式中，当应答消息中未携带有对应于第二提议属性行的第二应答属性行时，根据应答消息中携带的对应于第一提议属性行的第一应答属性行检测两端是否均支持DCEP方式；若检测出两端均支持DCEP方式，则通过DCEP方式与接收端之间建立数据通道。
当发送端检测出两端均支持DCEP方式时，发送端向接收端发送数据通道打开请求，该数据通道打开请求可以以DCEP Open消息的形式发送给接收端。
数据通道打开请求中携带有发送端为数据通道指定的流标识。另外，数据通道打开请求中还可携带有PPID(Payload Protocol Identifier，净荷协议标识)、 用于请求打开数据通道的参数以及在数据通道上传输的数据协议等内容。
比如，该数据通道打开请求可以为：
Figure PCTCN2015078972-appb-000001
其中，“Stream ID＝2”表示发送端为数据通道指定的流标识为2，“PPID＝50”用于表示DCEP协议，“MessageType＝DATA_CHANNEL_OPEN”用于表示请求打开数据通道的参数，“Protocol＝MSRP”用于表示数据通道上传输的数据协议为MSRP。
对应地，接收端根据数据通道打开请求与发送端之间建立数据通道，并向发送端反馈数据通道打开响应。
比如，该数据通道打开响应可以为：
Figure PCTCN2015078972-appb-000002
其中，“MessageType＝DATA_CHANNEL_ACK”用于表示响应打开数据通道的参数。
另外，发送端与接收端之间首先建立SCTP偶联，然后在此基础上建立数据通道，该数据通道包括SCTP偶联下的一对出入流，且该对出入流具有相同的流标识。
综上所述，本实施例提供的数据通道建立方法，解决了当通信两端中的至少一端同时支持两种或者两种以上的数据通道协商方式时，通信两端就无法协商建立数据通道的问题；当两端中的至少一端支持两种或两种以上数据通道协商方式时，通过两端对数据通道协商方式的协商确定，进而在此基础上完成数 据通道的建立，使得两端能够简单、高效地建立数据通道，实现了不同终端、不同网络之间的互连互通。
另外，本实施例提供的数据通道建立方法，在对数据通道协商方式进行协商的同时，接收端在确定同意采用SDP方式建立数据通道时，通过在应答消息中直接反馈数据通道关联的流标识，可以避免两端在后续过程中对流标识的进一步协商，使得发送端接收到应答消息之后，可以直接根据应答消息与接收端之间建立数据通道，减少两端信息交互的次数，提高数据通道建立的效率；同时，还可避免因信息交互过程中可能存在的信息丢失、或者收发延时等问题导致的协商失败，充分提高数据通道建立的成功率。
需要说明的一点是，当基于浏览器的终端或者传统终端与IMS(IP Multimedia Subsystem，IP多媒体子系统)连接时，接收端通常为分离架构下的IMS-ALG(IMS Application Level Gateway，IMS应用层网关)和IMS-AGW(IMS Access Media Gateway，IMS接入媒体网关)。由于发送端与IMS-ALG之间进行SDP会话，而数据通道需要建立在发送端与IMS-AGW之间，这就需要在IMS-ALG与IMS-AGW之间建立一种协商机制，使得IMS-ALG获知IMS-AGW支持的数据通道协商方式。
具体地，当接收端包括分离架构下的应用层网关和接入媒体网关时，通过应用层网关和接入媒体网关之间交互确定接入媒体网关支持的数据通道协商方式；通过应用层网关根据第一提议属性行、第二提议属性行以及接入媒体网关支持的数据通道协商方式确定应答消息。
在一个实施例中，应用层网关可以向接入媒体网关发送询问请求以询问接入媒体网关支持的数据通道协商方式。比如，该询问请求为：
Query_datachannel_message{method for established datachannel:static；dynamic}
其中，仍然以第一标识“dynamic”表示DCEP方式，第二标识“static”表示SDP方式。
对应地，接入媒体网关根据自身支持的数据通道协商方式向应用层网关发送对应于询问请求的询问响应：
Resp_datachannel_message{method for established datachannel:static；dynamic}
其中，若询问响应包括第一标识“dynamic”，则说明接入媒体网关支持DCEP方式；若询问响应包括第二标识“static”，则说明接入媒体网关支持SDP方式；若询问响应包括第一标识“dynamic”和第二标识“static”，则说明接入媒体网关支持DCEP方式和SDP方式。
之后，应用层网关根据第一提议属性行、第二提议属性行和接入媒体网关支持的数据通道协商方式确定应答消息。具体确定应答消息的过程在上述图4所示实施例中的步骤402已经详细介绍，不再赘述。
在图4所示实施例中，具体介绍了发送端与接收端之间对数据通道协商方式的协商，并在此基础上建立数据通道。在对数据通道协商方式进行协商的同时，发送端和接收端之间还可对数据通道上传输的数据协议进行协商。下面，将通过图5所示实施例介绍在一次SDP会话中完成数据通道协商方式的协商以及数据通道上传输的数据协议的协商。
请参考图5，其示出了本发明还一实施例提供的数据通道建立方法的方法流程图，本实施例以该数据通道建立方法应用于图1所示实施环境中来举例说明。该数据通道建立方法可以包括如下几个步骤：
步骤501，发送端向接收端发送提议消息。
与图4所示实施例相同的是，为了实现两端对采用何种数据通道协商方式的协商，提议消息中携带有第一提议属性行和第二提议属性行。
与图4所示实施例不同的是，在本实施例中，为了实现两端在对数据通道协商方式进行协商的同时，对数据通道上传输的数据协议也进行协商，提议消息中还包括第三提议属性行。
第三提议属性行包括发送端在数据通道上支持的数据协议的信息。在通常情况下，基于SCTP偶联的数据通道上可以传输MSRP协议的数据和CLUE协议的数据。其中，MSRP协议主要用于聊天应用和文件传输应用，CLUE协议主要用于会议应用。因此，发送端在数据通道上支持的数据协议可以是MSRP协议和CLUE协议中的任意一种或者全部两种。第三提议属性行中包括的信息可以是明确的携带有MSRP协议和/或CLUE协议对应的协议标识的信息，也可以是能够表明发送端在数据通道上支持的数据协议的其它任何形式的信息，对此本实施例不作具体限定。
具体地，提议消息的确定过程可以包括如下几个步骤：
第一，根据发送端支持的数据通道协商方式确定本次请求的数据通道协商方式。
第二，根据发送端支持的数据通道协商方式确定第一提议属性行。
第一提议属性行的确定过程在图4所示实施例中已经详细介绍和说明，具体参见图4所示实施例，本实施例中不再赘述。
第三，根据发送端在数据通道上支持的数据协议确定第三提议属性行。
第三提议属性行中可以包括发送端在数据通道上支持的数据协议对应的协议标识。比如，当发送端在数据通道上支持的数据协议为MSRP协议和CLUE协议时，第三提议属性行可以为：a＝subprotocol:MSRP/CLUE；再比如，当发送端在数据通道上支持的数据协议为MSRP协议时，第三提议属性行可以为：a＝subprotocol:MSRP。
第四，根据发送端在数据通道上支持的数据协议对应的应用的数量a确定本次请求建立的数据通道的数量a，a≥1。
其中，每种数据协议对应于至少一种应用。比如，当发送端在数据通道上支持的数据协议为MSRP协议和CLUE协议时，假设发送端请求通过MSRP协议实现聊天应用和文件传输应用，通过CLUE协议实现会议应用，则发送端需要请求建立3条数据通道，每条数据通道用于传输一种应用的数据。
第五，根据本次请求的数据通道协商方式生成a个第二提议属性行。
第二提议属性行的数量与本次请求建立的数据通道的数量相同。当本次请求建立的数据通道的数量为3时，发送端需要生成3个第二提议属性行。具体地：
若本次请求的数据通道协商方式为DCEP方式，则生成a个第二提议属性行；其中，每个第二提议属性行包括一个流标识和一个标签，且不同的第二提议属性行中包括的流标识均为任意流标识符，不同的第二提议属性行中包括的标签为互不相同的标签，每个标签对应于一条数据通道。
任意流标识符用于表示本次请求建立的数据通道关联的流标识为任意的，其可由接收端在后续应答过程中选定一个未被使用的流标识作为数据通道关联的流标识，也可在后续过程中以DCEP Open消息的形式进一步协商确定数据通道关联的流标识。
在本实施例中，假设以“*”表示任意流标识符。发送端生成的第二提议属性行除了包括流标识和标签之外，通常还包括SCTP端口号、数据通道对应的标签以及最大重传次数等参数。因此，当本次请求的数据通道协商方式为DCEP方式时，上述3条数据通道所对应的3个第二提议属性行可以为：
a＝dcmap:5000stream＝*；label 1＝"channel for file transfer"；max_retr＝3
a＝dcmap:5000stream＝*；label 2＝"channel for chat"；max_retr＝3
a＝dcmap:5000stream＝*；label 3＝"channel for conference"；max_retr＝3
若第二提议属性行包括任意流标识符，可以使得接收端在后续过程中确定采用SDP方式建立数据通道时，在应答消息中直接反馈数据通道关联的流标识，避免两端在后续过程中对流标识的进一步协商。
若本次请求的数据通道协商方式为SDP方式，则生成a个第二提议属性行；其中，每个第二提议属性行包括一个流标识和一个标签，且不同的第二提议属性行中包括的流标识为互不相同的指定流标识符，不同的第二提议属性行中包括的标签为互不相同的标签，每个标签对应于一条数据通道。
指定流标识符用于表示数据通道关联的流标识为指定的。当发送端请求SDP方式协商建立数据通道时，发送端为请求建立的数据通道选定一个未被使用的流标识。指定流标识符可以是1、2、3、……、n中的任意整数，n≥1。
比如，当本次请求的数据通道协商方式为SDP方式时，上述3条数据通道所对应的3个第二提议属性行可以为：
a＝dcmap:5000stream＝1；label 1＝"channel for file transfer"；max_retr＝3
a＝dcmap:5000stream＝2；label 2＝"channel for chat"；max_retr＝3
a＝dcmap:5000stream＝3；label 3＝"channel for conference"；max_retr＝3
另外，第三提议属性行还可以包括每个协议标识关联的标签，以便接收端在后续过程中对第二提议属性行做出有针对性的应答。对于发送端在数据通道上支持的每一个数据协议，发送端获取该数据协议对应的应用的数量。比如，当发送端在数据通道上支持的数据协议为MSRP协议和CLUE协议时，假设MSRP协议对应的应用的数量为2(即聊天应用和文件传输应用)，CLUE协议对应的应用的数量为1(即会议应用)。之后，发送端根据数据协议对应的应用的数量为数据协议分配相同数量的标签，每个标签为a个第二提议属性行中包括的a个互不相同的标签中的一个。比如，发送端根据MSRP协议对应的应用 的数量为MSRP协议分配2个标签，分别为label 1和label 2；根据CLUE协议对应的应用的数量为CLUE协议分配1个标签，为label 3。之后，发送端将数据协议对应的协议标识与数据协议所分配得的标签进行关联。比如，该关联结果可以表示为MSRP(label 1；label 2)以及CLUE(label 3)。之后，发送端生成包括各个数据协议对应的协议标识以及每个协议标识关联的标签的第三提议属性行。比如，第三提议属性行可以为：a＝subprotocol:MSRP(label 1；label 2)/CLUE(label 3)。
第六，发送端生成携带有第一提议属性行、a个第二提议属性行和第三提议属性行的提议消息。
比如，发送端生成的提议消息可以包括：
m＝application 54111DTLS/SCTP 5000
c＝IN IP479.97.215.79
a＝sctpmap:5000datachannel max-message-size＝100000streams＝16
a＝assignstreamid:static；dynamic
a＝subprotocol:MSRP(label 1；label 2)/CLUE(label 3)
a＝dcmap:5000stream＝*；label 1＝"channel for file transfer"；max_retr＝3
a＝dcmap:5000stream＝*；label 2＝"channel for chat"；max_retr＝3
a＝dcmap:5000stream＝*；label 3＝"channel for conference"；max_retr＝3
之后，发送端向接收端发送提议消息。
对应地，接收端接收发送端发送的提议消息。
步骤502，接收端确定应答消息。
具体地，本步骤可以包括如下几个子步骤：
第一，当提议消息中还包括第三提议属性行时，接收端根据第三提议属性行和接收端在数据通道上支持的数据协议检测是否存在两端在数据通道上均支持的数据协议。
第三提议属性行包括发送端在数据通道上支持的数据协议的信息。接收端根据发送端在数据通道上支持的数据协议和接收端在数据通道上支持的数据协议检测是否存在两端在数据通道上均支持的数据协议。
比如，当第三提议属性行为“a＝subprotocol:MSRP/CLUE”，且接收端在数据通道上支持的数据协议为MSRP协议时，说明存在两端在数据通道上均支持的 数据协议，即MSRP协议。
再比如，当第三提议属性行为“a＝subprotocol:CLUE”，且接收端在数据通道上支持的数据协议为MSRP协议和CLUE协议时，说明存在两端在数据通道上均支持的数据协议，即CLUE协议。
第二，若检测出存在两端在数据通道上均支持的数据协议，则接收端根据两端在数据通道上均支持的数据协议生成对应于第三提议属性行的第三应答属性行。
与图4所示实施例不同的是，在本实施例中，应答消息中还可以携带有对应于第三提议属性行的第三应答属性行。第三应答属性行包括两端在数据通道上均支持的数据协议的信息。
第三应答属性行可以包括两端在数据通道上均支持的数据协议所对应的协议标识。比如，当两端在数据通道上均支持的数据协议为MSRP协议和CLUE协议时，第三应答属性行可以为：a＝subprotocol:MSRP/CLUE；再比如，当两端在数据通道上均支持的数据协议为MSRP协议时，第三应答属性行可以为：a＝subprotocol:MSRP。
另外，若检测出不存在两端在数据通道上均支持的数据协议，则不生成对应于第三提议属性行的第三应答属性行。相应地，在后续生成应答消息的过程中，应答消息中也不携带对应于第三提议属性行的第三应答属性行。
在本实施例中，当存在两端在数据通道上均支持的数据协议时，应答消息中携带有对应于第一提议属性行的第一应答属性行，以及对应于第三提议属性行的第三应答属性行。另外，根据最终确定采用的数据通道协商方式不同，应答消息中可以携带有对应于第二提议属性行的第二应答属性行，也可以不携带对应于第二提议属性行的第二应答属性行。具体地：
第三，根据第一提议属性行和接收端支持的数据通道协商方式确定两端均支持的数据通道协商方式。
第四，若两端均支持的数据通道协商方式有且只有DCEP方式，则确定同意采用的数据通道协商方式为DCEP方式，并生成携带有第一应答属性行和第三应答属性行的应答消息。
当确定同意采用的数据通道协商方式为DCEP方式时，应答消息可以包括：
c＝IN IP479.97.215.79
a＝sctpmap:5000datachannel max-message-size＝100000streams＝16
a＝assignstreamid:dynamic
a＝subprotocol:MSRP
其中，第一应答属性行“a＝assignstreamid:dynamic”表示接收端支持的数据通道协商方式为DCEP方式；第三应答属性行“a＝subprotocol:MSRP”表示两端在数据通道上均支持的数据协议为MSRP协议。
第四，若两端均支持的数据通道协商方式有且只有SDP方式，则确定同意采用的数据通道协商方式为SDP方式，并生成携带有第一应答属性行、第二应答属性行和第三应答属性行的应答消息。
其中，第二应答属性行与第二提议属性行对应，第二应答属性行包括接收端同意采用的数据通道协商方式的信息，该信息通常包括相关用于建立数据通道的参数，比如SCTP端口号、数据通道关联的流标识、数据通道对应的标签以及最大重传次数等等。接收端生成携带有第一应答属性行、第二应答属性行和第三应答属性行的应答消息，以便发送端在后续过程中读取第二应答属性行后，通过SDP方式与接收端之间建立数据通道，并根据第三应答属性行确定在数据通道上传输的数据协议。
在本实施例中，接收端确定第二应答属性行的过程如下：
1、根据第三提议属性行以及两端在数据通道上均支持的数据协议确定所需应答的第二提议属性行。
其中，所需应答的第二提议属性行中的属性值包括的标签与两端在数据通道上均支持的数据协议对应的协议标识在第三提议属性行中关联的标签相同。
比如，当第三提议属性行为a＝subprotocol:MSRP(label 1；label 2)/CLUE(label3)，且两端在数据通道上均支持的数据协议为MSRP协议时，所需应答的第二提议属性行即为：
a＝dcmap:5000stream＝*；label 1＝"channel for file transfer"；max_retr＝3
a＝dcmap:5000stream＝*；label 2＝"channel for chat"；max_retr＝3
再比如，当第三提议属性行为a＝subprotocol:MSRP(label 1；label 2)/CLUE(label 3)，且两端在数据通道上均支持的数据协议为CLUE协议时，所需应答的第二提议属性行即为：
a＝dcmap:5000stream＝*；label 3＝"channel for conference"；max_retr＝3
2、生成对应于所需应答的第二提议属性行的第二应答属性行。
第二应答属性行包括指定流标识符。当第二提议属性行中的流标识为任意流标识符时，第二应答属性行中的指定流标识符是接收端确定的；当第二提议属性行中的流标识为指定流标识符时，第二应答属性行中的指定流标识符与第二提议属性行中的指定流标识符相同。第二应答属性行还包括标签，第二应答属性行中的标签与其对应的第二提议属性行中的标签相同。
比如，当所需应答的第二提议属性行即为：
a＝dcmap:5000stream＝*；label 1＝"channel for file transfer"；max_retr＝3
a＝dcmap:5000stream＝*；label 2＝"channel for chat"；max_retr＝3时，第二应答属性行可以为：
a＝dcmap:5000stream＝1；label 1＝"channel for file transfer"；max_retr＝3
a＝dcmap:5000stream＝2；label 2＝"channel for chat"；max_retr＝3
再比如，当所需应答的第二提议属性行即为：
a＝dcmap:5000stream＝3；label 3＝"channel for conference"；max_retr＝3时，第二应答属性行可以为：
a＝dcmap:5000stream＝3；label 3＝"channel for conference"；max_retr＝3
之后，接收端生成携带有第一应答属性行、第二应答属性行和第三应答属性行的应答消息。比如，应答消息可以包括：
c＝IN IP479.97.215.79
a＝sctpmap:5000datachannel max-message-size＝100000streams＝16
a＝assignstreamid:static
a＝subprotocol:MSRP(label 1；label 2)
a＝dcmap:5000stream＝1；label 1＝"channel for file transfer"；max_retr＝3
a＝dcmap:5000stream＝2；label 2＝"channel for chat"；max_retr＝3
接收端通过在应答消息中直接反馈数据通道关联的流标识，可以避免两端在后续过程中对流标识的进一步协商，使得发送端接收到应答消息之后，可以直接根据应答消息中携带的第二应答属性行与接收端之间通过SDP方式建立数据通道，减少两端信息交互的次数，提高数据通道建立的效率；同时，还可避免因信息交互过程中可能存在的信息丢失、或者收发延时等问题导致的协商失败，充分提高数据通道建立的成功率。
第五，若两端均支持的数据通道协商方式为DCEP方式和SDP方式，则判断第二提议属性行中包括的数据通道关联的流标识为任意流标识符还是指定流标识符；若为任意流标识符，则确定同意采用的数据通道协商方式为DCEP方式，并生成携带有第一应答属性行和第三应答属性行的应答消息；若为指定流标识符，则确定同意采用的数据通道协商方式为SDP方式，并生成携带有第一应答属性行、第二应答属性行和第三应答属性行的应答消息。
其中，第二提议属性行中的任意流标识符表示发送端本次请求的数据通道协商方式为DCEP方式，第二提议属性行中的指定流标识符表示发送端本次请求的数据通道协商方式为SDP方式。当两端均支持的数据通道协商方式为DCEP方式和SDP方式时，接收端根据发送端请求的数据通道协商方式确定最终采用的数据通道协商方式。
步骤503，接收端向发送端发送应答消息。
对应地，发送端接收接收端发送的应答消息。
步骤504，发送端根据应答消息与接收端之间建立数据通道。
上述步骤503至步骤504与图4所示实施例中的步骤403至步骤404相同或者类似，对此不再赘述。
另外，在上述步骤503之后，本实施例还包括如下步骤505和步骤506：
步骤505，发送端读取应答消息中携带的对应于第三提议属性行的第三应答属性行。
步骤506，发送端根据第三应答属性行确定在数据通道上传输的数据协议。
第三应答属性行包括两端在数据通道上均支持的数据协议的信息，该两端在数据通道上均支持的数据协议即为两端在数据通道上传输的数据协议。
综上所述，本实施例提供的数据通道建立方法，解决了当通信两端中的至少一端同时支持两种或者两种以上的数据通道协商方式时，通信两端就无法协商建立数据通道的问题；当两端中的至少一端支持两种或两种以上数据通道协商方式时，通过两端对数据通道协商方式的协商确定，进而在此基础上完成数据通道的建立，使得两端能够简单、高效地建立数据通道，实现了不同终端、不同网络之间的互连互通。
另外，本实施例提供的数据通道建立方法，在对数据通道协商方式进行协商的同时，发送端和接收端之间还可对数据通道上传输的数据协议进行协商， 发送端和接收端之间通过一次SDP会话即可完成数据通道协商方式的协商以及数据通道上传输的数据协议的协商，充分提高了数据通道建立的效率。
需要说明的一点是，上述图5所示实施例仅以发送端和接收端之间通过一次SDP会话完成数据通道协商方式的协商以及数据通道上传输的数据协议的协商进行举例说明，在其它可能的实施例中，上述两种协商过程可分为两次SDP会话进行，也即发送端和接收端直接可单独通过一次SDP会话以完成数据通道上传输的数据协议的协商，对此本发明实施例不作具体限定。
下述为本发明装置实施例，可以用于执行本发明方法实施例。对于本发明装置实施例中未披露的细节，请参照本发明方法实施例。
请参考图6，其示出了本发明一个实施例提供的通信设备的结构方框图，本实施例以该通信设备为图1所示实施环境中的发送端来举例说明。该发送端可以是基于浏览器的终端、传统终端或者媒体网关。该通信设备可以包括：发送模块610、应答接收模块620和通道建立模块630。
发送模块610，用于向接收端发送携带有第一提议属性行和第二提议属性行的提议消息；其中，所述第一提议属性行包括所述发送端支持的数据通道协商方式的信息，所述第二提议属性行包括本次请求的数据通道协商方式的信息，所述本次请求的数据通道协商方式为所述发送端支持的数据通道协商方式中的一种。
应答接收模块620，用于接收所述接收端发送的应答消息，所述应答消息是所述接收端根据所述第一提议属性行、所述第二提议属性行以及所述接收端支持的数据通道协商方式确定的。
通道建立模块630，用于根据所述应答消息与所述接收端之间建立数据通道。
其中，所述发送端和所述接收端中的至少一端支持两种或者两种以上数据通道协商方式。
综上所述，本实施例提供的通信设备，解决了当通信两端中的至少一端同时支持两种或者两种以上的数据通道协商方式时，通信两端就无法协商建立数据通道的问题；当两端中的至少一端支持两种或两种以上数据通道协商方式时，通过两端对数据通道协商方式的协商确定，进而在此基础上完成数据通道的建 立，使得两端能够简单、高效地建立数据通道，实现了不同终端、不同网络之间的互连互通。
请参考图7，其示出了本发明另一实施例提供的通信设备的结构方框图，本实施例以该通信设备为图1所示实施环境中的发送端来举例说明。该发送端可以是基于浏览器的终端、传统终端或者媒体网关。该通信设备可以包括：发送模块610、应答接收模块620和通道建立模块630。
发送模块610，用于向接收端发送携带有第一提议属性行和第二提议属性行的提议消息；其中，所述第一提议属性行包括所述发送端支持的数据通道协商方式的信息，所述第二提议属性行包括本次请求的数据通道协商方式的信息，所述本次请求的数据通道协商方式为所述发送端支持的数据通道协商方式中的一种。
其中，所述发送端和所述接收端中的至少一端支持两种或者两种以上数据通道协商方式。
可选的，所述发送端和所述接收端中的一端支持的数据通道协商方式包括数据通道建立协议DCEP方式和会话描述协议SDP方式，且另一端支持的数据通道协商方式包括所述DCEP方式和所述SDP方式中的至少一种。
另外，第二提议属性行中包括的信息在上述图4和图5所示的方法实施例中已经详细介绍，具体参见上述图4和图5所示的方法实施例，本实施例中不再赘述。
可选的，所述提议消息还包括第三提议属性行，所述第三提议属性行包括所述发送端在所述数据通道上支持的数据协议的信息，以便所述接收端根据所述第三提议属性行和所述接收端在所述数据通道上支持的数据协议确定出两端在所述数据通道上均支持的数据协议。
可选的，所述通信设备还包括：数量确定模块601和生成模块602。
数量确定模块601，用于根据所述发送端在所述数据通道上支持的数据协议对应的应用的数量a确定本次请求建立的所述数据通道的数量a，a≥1；其中，每种数据协议对应于至少一种应用。
生成模块602，用于根据所述本次请求的数据通道协商方式生成a个所述第二提议属性行。
可选的，所述生成模块602，包括：第一生成单元；或者，第二生成单元。
所述第一生成单元，用于若所述本次请求的数据通道协商方式为DCEP方式，则生成a个所述第二提议属性行；其中，每个第二提议属性行包括一个流标识和一个标签，且不同的第二提议属性行中包括的流标识均为任意流标识符，不同的第二提议属性行中包括的标签为互不相同的标签，每个标签对应于一条数据通道。
所述第二生成单元，用于若所述本次请求的数据通道协商方式为SDP方式，则生成a个所述第二提议属性行；其中，每个第二提议属性行包括一个流标识和一个标签，且不同的第二提议属性行中包括的流标识为互不相同的指定流标识符，不同的第二提议属性行中包括的标签为互不相同的标签，每个标签对应于一条数据通道。
可选的，所述通信设备还包括：数量获取模块603、标签分配模块604、标签关联模块605和属性行生成模块606。
数量获取模块603，用于对于所述发送端在所述数据通道上支持的每一个数据协议，获取所述数据协议对应的应用的数量。
标签分配模块604，用于根据所述数据协议对应的应用的数量为所述数据协议分配相同数量的标签，每个标签为a个所述第二提议属性行中包括的a个互不相同的标签中的一个。
标签关联模块605，用于将所述数据协议对应的协议标识与所述数据协议所分配得的标签进行关联。
属性行生成模块606，用于生成包括各个所述数据协议对应的协议标识以及每个协议标识关联的标签的第三提议属性行。
应答接收模块620，用于接收所述接收端发送的应答消息，所述应答消息是所述接收端根据所述第一提议属性行、所述第二提议属性行以及所述接收端支持的数据通道协商方式确定的。
通道建立模块630，用于根据所述应答消息与所述接收端之间建立数据通道。
可选的，所述通道建立模块630，包括：第一建立单元。
所述第一建立单元，用于当所述应答消息中携带有对应于所述第二提议属性行的第二应答属性行时，通过所述SDP方式与所述接收端之间建立所述数据 通道；
其中，所述第二应答属性行是所述接收端确定同意采用的数据通道协商方式为所述SDP方式时生成的。
可选的，所述通道建立模块630，包括：方式检测单元和第二建立单元。
所述方式检测单元，用于当所述应答消息中未携带有对应于所述第二提议属性行的第二应答属性行时，根据所述应答消息中携带的对应于所述第一提议属性行的第一应答属性行检测两端是否均支持所述DCEP方式。
所述第二建立单元，用于若检测出两端均支持所述DCEP方式，则通过所述DCEP方式与所述接收端之间建立所述数据通道。
可选的，所述通信设备还包括：应答读取模块621和协议确定模块622。
应答读取模块621，用于读取所述应答消息中携带的对应于所述第三提议属性行的第三应答属性行，所述第三应答属性行是所述接收端根据所述第三提议属性行和所述接收端在所述数据通道上支持的数据协议确定出两端在所述数据通道上均支持的数据协议后生成的。
协议确定模块622，用于根据所述第三应答属性行确定在所述数据通道上传输的数据协议。
综上所述，本实施例提供的通信设备，解决了当通信两端中的至少一端同时支持两种或者两种以上的数据通道协商方式时，通信两端就无法协商建立数据通道的问题；当两端中的至少一端支持两种或两种以上数据通道协商方式时，通过两端对数据通道协商方式的协商确定，进而在此基础上完成数据通道的建立，使得两端能够简单、高效地建立数据通道，实现了不同终端、不同网络之间的互连互通。
另外，当提议消息中还包括第三提议属性行时，发送端和接收端在对数据通道协商方式进行协商的同时，还可对数据通道上传输的数据协议进行协商，发送端和接收端之间通过一次SDP会话即可完成数据通道协商方式的协商以及数据通道上传输的数据协议的协商，充分提高了数据通道建立的效率。
请参考图8，其示出了本发明再一实施例提供的通信设备的结构方框图，本实施例以该通信设备为图1所示实施环境中的接收端来举例说明。该接收端可以是基于浏览器的终端、传统终端或者媒体网关。该通信设备可以包括：接收 模块710、应答确定模块720和应答发送模块730。
接收模块710，用于接收发送端发送的携带有第一提议属性行和第二提议属性行的提议消息；其中，所述第一提议属性行包括所述发送端支持的数据通道协商方式的信息，所述第二提议属性行包括本次请求的数据通道协商方式的信息，所述本次请求的数据通道协商方式为所述发送端支持的数据通道协商方式中的一种。
应答确定模块720，用于根据所述第一提议属性行、所述第二提议属性行以及接收端支持的数据通道协商方式确定应答消息。
应答发送模块730，用于向所述发送端发送所述应答消息，以便所述发送端根据所述应答消息与所述接收端之间建立数据通道。
其中，所述接收端和所述发送端中的至少一端支持两种或者两种以上数据通道协商方式。
综上所述，本实施例提供的通信设备，解决了当通信两端中的至少一端同时支持两种或者两种以上的数据通道协商方式时，通信两端就无法协商建立数据通道的问题；当两端中的至少一端支持两种或两种以上数据通道协商方式时，通过两端对数据通道协商方式的协商确定，进而在此基础上完成数据通道的建立，使得两端能够简单、高效地建立数据通道，实现了不同终端、不同网络之间的互连互通。
请参考图9，其示出了本发明再一实施例提供的通信设备的结构方框图，本实施例以该通信设备为图1所示实施环境中的接收端来举例说明。该接收端可以是基于浏览器的终端、传统终端或者媒体网关。该通信设备可以包括：接收模块710、应答确定模块720和应答发送模块730。
接收模块710，用于接收发送端发送的携带有第一提议属性行和第二提议属性行的提议消息；其中，所述第一提议属性行包括所述发送端支持的数据通道协商方式的信息，所述第二提议属性行包括本次请求的数据通道协商方式的信息，所述本次请求的数据通道协商方式为所述发送端支持的数据通道协商方式中的一种。
其中，所述接收端和所述发送端中的至少一端支持两种或者两种以上数据通道协商方式。
可选的，所述接收端和所述发送端中的一端支持的数据通道协商方式包括数据通道建立协议DCEP方式和会话描述协议SDP方式，且另一端支持的数据通道协商方式包括所述DCEP方式和所述SDP方式中的至少一种。
应答确定模块720，用于根据所述第一提议属性行、所述第二提议属性行以及接收端支持的数据通道协商方式确定应答消息。
可选的，所述应答确定模块720，包括：方式确定单元，和下面至少一个单元：第一应答单元，第二应答单元，和第三应答单元。
所述方式确定单元，用于根据所述第一提议属性行和所述接收端支持的数据通道协商方式确定两端均支持的数据通道协商方式。
所述第一应答单元，用于若所述两端均支持的数据通道协商方式有且只有DCEP方式，则确定同意采用的数据通道协商方式为所述DCEP方式，并生成携带有所述第一应答属性行的应答消息，以便所述发送端根据所述第一应答属性行检测出两端均支持所述DCEP方式后，通过所述DCEP方式与所述接收端之间建立所述数据通道。
所述第二应答单元，用于若所述两端均支持的数据通道协商方式有且只有SDP方式，则确定同意采用的数据通道协商方式为所述SDP方式，并生成携带有所述第一应答属性行和第二应答属性行的应答消息，以便所述发送端读取所述第二应答属性行后，通过所述SDP方式与所述接收端之间建立所述数据通道。
所述第三应答单元，用于若所述两端均支持的数据通道协商方式为DCEP方式和SDP方式，则判断所述第二提议属性行中包括的所述数据通道关联的流标识为任意流标识符还是指定流标识符；其中，所述任意流标识符表示所述本次请求的数据通道协商方式为所述DCEP方式，所述指定流标识符表示所述本次请求的数据通道协商方式为所述SDP方式；若为所述任意流标识符，则确定同意采用的数据通道协商方式为所述DCEP方式，并生成携带有所述第一应答属性行的应答消息，以便所述发送端根据所述第一应答属性行检测出两端均支持所述DCEP方式后，通过所述DCEP方式与所述接收端之间建立所述数据通道；若为所述指定流标识符，则确定同意采用的数据通道协商方式为所述SDP方式，并生成携带有所述第一应答属性行和第二应答属性行的应答消息，以便所述发送端读取所述第二应答属性行后，通过所述SDP方式与所述接收端之间建立所述数据通道。
可选的，所述第二应答属性行还包括指定流标识符；其中，当所述第二提议属性行中的流标识为所述任意流标识符时，所述第二应答属性行中的所述指定流标识符是所述接收端确定的；当所述第二提议属性行中的流标识为所述指定流标识符时，所述第二应答属性行中的所述指定流标识符与所述第二提议属性行中的所述指定流标识符相同。
可选的，所述通信设备还包括：协议检测模块711和协议应答模块712。
协议检测模块711，用于当所述提议消息中还包括第三提议属性行时，根据所述第三提议属性行和所述接收端在所述数据通道上支持的数据协议检测是否存在两端在所述数据通道上均支持的数据协议；其中，所述第三提议属性行是所述发送端根据所述发送端在所述数据通道上支持的数据协议生成的。
协议应答模块712，用于若检测出存在两端在所述数据通道上均支持的数据协议，则根据两端在所述数据通道上均支持的数据协议生成对应于所述第三提议属性行的第三应答属性行，以便所述发送端根据所述第三应答属性行确定在所述数据通道上传输的数据协议。
可选的，所述通信设备还包括：确定模块713和应答模块714。
确定模块713，用于根据所述第三提议属性行以及两端在所述数据通道上均支持的数据协议确定所需应答的第二提议属性行；其中，所述所需应答的第二提议属性行中的属性值包括的标签与两端在所述数据通道上均支持的数据协议对应的协议标识在所述第三提议属性行中关联的标签相同。
应答模块714，用于生成对应于所述所需应答的第二提议属性行的第二应答属性行，所述第二应答属性行还包括标签，所述第二应答属性行中的标签与其对应的第二提议属性行中的标签相同。
应答发送模块730，用于向所述发送端发送所述应答消息，以便所述发送端根据所述应答消息与所述接收端之间建立数据通道。
综上所述，本实施例提供的通信设备，解决了当通信两端中的至少一端同时支持两种或者两种以上的数据通道协商方式时，通信两端就无法协商建立数据通道的问题；当两端中的至少一端支持两种或两种以上数据通道协商方式时，通过两端对数据通道协商方式的协商确定，进而在此基础上完成数据通道的建立，使得两端能够简单、高效地建立数据通道，实现了不同终端、不同网络之间的互连互通。
另外，当提议消息中还包括第三提议属性行时，发送端和接收端在对数据通道协商方式进行协商的同时，还可对数据通道上传输的数据协议进行协商，发送端和接收端之间通过一次SDP会话即可完成数据通道协商方式的协商以及数据通道上传输的数据协议的协商，充分提高了数据通道建立的效率。
本发明实施例还提供了一种数据通道建立系统，该数据通道建立系统可以包括发送端和接收端。其中，发送端可以是上述图6或者图7所示的通信设备；接收端可以是上述图8或者图9所示的通信设备。
需要说明的是，上述实施例提供的通信设备在协商建立数据通道时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的通信设备与数据通道建立方法的方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。
请参考图10，其示出了本发明一个实施例所提供的发送端的结构示意图，该发送端可以是基于浏览器的终端、传统终端或者媒体网关。该发送端包括：处理器1020、与所述处理器1020电性相连的存储器1040、接收机1060和发送机1080。存储器1040中存储有一个或者一个以上的程序，处理器1020可以根据存储器1040中存储的一个或者一个以上的程序实现相应的操作。具体的：
所述处理器1020，用于控制所述发送机1080向接收端发送携带有第一提议属性行和第二提议属性行的提议消息；其中，所述第一提议属性行包括所述发送端支持的数据通道协商方式的信息，所述第二提议属性行包括本次请求的数据通道协商方式的信息，所述本次请求的数据通道协商方式为所述发送端支持的数据通道协商方式中的一种。
所述处理器1020，还用于控制所述接收机1060接收所述接收端发送的应答消息，所述应答消息是所述接收端根据所述第一提议属性行、所述第二提议属性行以及所述接收端支持的数据通道协商方式确定的。
所述处理器1020，还用于根据所述应答消息与所述接收端之间建立数据通 道。
其中，所述发送端和所述接收端中的至少一端支持两种或者两种以上数据通道协商方式。
综上所述，本实施例提供的发送端，解决了当通信两端中的至少一端同时支持两种或者两种以上的数据通道协商方式时，通信两端就无法协商建立数据通道的问题；当两端中的至少一端支持两种或两种以上数据通道协商方式时，通过两端对数据通道协商方式的协商确定，进而在此基础上完成数据通道的建立，使得两端能够简单、高效地建立数据通道，实现了不同终端、不同网络之间的互连互通。
在图10所示实施例的第一种可能的实施方式中，所述发送端和所述接收端中的一端支持的数据通道协商方式包括数据通道建立协议DCEP方式和会话描述协议SDP方式，且另一端支持的数据通道协商方式包括所述DCEP方式和所述SDP方式中的至少一种。
在图10所示实施例的第二种可能的实施方式中，
若所述本次请求的数据通道协商方式为DCEP方式，则所述第二提议属性行还包括任意流标识符，所述任意流标识符用于表示所述数据通道关联的流标识为任意的，以便所述接收端在确定出两端均支持的数据通道协商方式包括DCEP方式时，根据所述任意流标识符确定同意采用的数据通道协商方式为所述DCEP方式；
或者，
若所述本次请求的数据通道协商方式为DCEP方式，则所述第二提议属性行还包括任意流标识符，所述任意流标识符用于表示所述数据通道关联的流标识为任意的，以便所述接收端在确定出两端均支持的数据通道协商方式有且只有SDP方式时，生成包括所述数据通道关联的流标识为指定流标识符的第二应答属性行，所述指定流标识符是所述接收端确定的；
或者，
若所述本次请求的数据通道协商方式为SDP方式，则所述第二提议属性行还包括指定流标识符，所述指定流标识符用于表示所述数据通道关联的流标识为指定的，以便所述接收端在确定出两端均支持的数据通道协商方式包括SDP方式时，根据所述指定流标识符确定同意采用的数据通道协商方式为所述SDP 方式；
或者，
若所述本次请求的数据通道协商方式为SDP方式，则所述第二提议属性行还包括指定流标识符，所述指定流标识符用于表示所述数据通道关联的流标识为指定的，以便所述接收端在确定出两端均支持的数据通道协商方式有且只有DCEP方式时，确定同意采用的数据通道协商方式为所述DCEP方式。
在图10所示实施例的第三种可能的实施方式中，所述提议消息还包括第三提议属性行，所述第三提议属性行包括所述发送端在所述数据通道上支持的数据协议的信息，以便所述接收端根据所述第三提议属性行和所述接收端在所述数据通道上支持的数据协议确定出两端在所述数据通道上均支持的数据协议。
在图10所示实施例的第四种可能的实施方式中，
所述处理器1020，还用于根据所述发送端在所述数据通道上支持的数据协议对应的应用的数量a确定本次请求建立的所述数据通道的数量a，a≥1；其中，每种数据协议对应于至少一种应用；
所述处理器1020，还用于根据所述本次请求的数据通道协商方式生成a个所述第二提议属性行。
在图10所示实施例的第五种可能的实施方式中，
所述处理器1020，还用于若所述本次请求的数据通道协商方式为DCEP方式，则生成a个所述第二提议属性行；其中，每个第二提议属性行包括一个流标识和一个标签，且不同的第二提议属性行中包括的流标识均为任意流标识符，不同的第二提议属性行中包括的标签为互不相同的标签，每个标签对应于一条数据通道；
所述处理器1020，还用于若所述本次请求的数据通道协商方式为SDP方式，则生成a个所述第二提议属性行；其中，每个第二提议属性行包括一个流标识和一个标签，且不同的第二提议属性行中包括的流标识为互不相同的指定流标识符，不同的第二提议属性行中包括的标签为互不相同的标签，每个标签对应于一条数据通道。
在图10所示实施例的第六种可能的实施方式中，
所述处理器1020，还用于对于所述发送端在所述数据通道上支持的每一个数据协议，获取所述数据协议对应的应用的数量；
所述处理器1020，还用于根据所述数据协议对应的应用的数量为所述数据协议分配相同数量的标签，每个标签为a个所述第二提议属性行中包括的a个互不相同的标签中的一个；
所述处理器1020，还用于将所述数据协议对应的协议标识与所述数据协议所分配得的标签进行关联；
所述处理器1020，还用于生成包括各个所述数据协议对应的协议标识以及每个协议标识关联的标签的第三提议属性行。
在图10所示实施例的第七种可能的实施方式中，
所述处理器1020，还用于当所述应答消息中携带有对应于所述第二提议属性行的第二应答属性行时，通过所述SDP方式与所述接收端之间建立所述数据通道；
其中，所述第二应答属性行是所述接收端确定同意采用的数据通道协商方式为所述SDP方式时生成的。
在图10所示实施例的第八种可能的实施方式中，
所述处理器1020，还用于当所述应答消息中未携带有对应于所述第二提议属性行的第二应答属性行时，根据所述应答消息中携带的对应于所述第一提议属性行的第一应答属性行检测两端是否均支持所述DCEP方式；
所述处理器1020，还用于若检测出两端均支持所述DCEP方式，则通过所述DCEP方式与所述接收端之间建立所述数据通道。
在图10所示实施例的第九种可能的实施方式中，
所述处理器1020，还用于读取所述应答消息中携带的对应于所述第三提议属性行的第三应答属性行，所述第三应答属性行是所述接收端根据所述第三提议属性行和所述接收端在所述数据通道上支持的数据协议确定出两端在所述数据通道上均支持的数据协议后生成的；
所述处理器1020，还用于根据所述第三应答属性行确定在所述数据通道上传输的数据协议。
请参考图11，其示出了本发明一个实施例所提供的接收端的结构示意图，该接收端可以是基于浏览器的终端、传统终端或者媒体网关。该接收端包括：处理器1120、与所述处理器1120电性相连的存储器1140、接收机1160和发送 机1180。存储器1140中存储有一个或者一个以上的程序，处理器1120可以根据存储器1140中存储的一个或者一个以上的程序实现相应的操作。具体的：
所述处理器1120，用于控制所述接收机1160接收发送端发送的携带有第一提议属性行和第二提议属性行的提议消息；其中，所述第一提议属性行包括所述发送端支持的数据通道协商方式的信息，所述第二提议属性行包括本次请求的数据通道协商方式的信息，所述本次请求的数据通道协商方式为所述发送端支持的数据通道协商方式中的一种。
所述处理器1120，还用于根据所述第一提议属性行、所述第二提议属性行以及接收端支持的数据通道协商方式确定应答消息。
所述处理器1120，还用于控制所述发送机1180向所述发送端发送所述应答消息，以便所述发送端根据所述应答消息与所述接收端之间建立数据通道。
其中，所述接收端和所述发送端中的至少一端支持两种或者两种以上数据通道协商方式。
综上所述，本实施例提供的接收端，解决了当通信两端中的至少一端同时支持两种或者两种以上的数据通道协商方式时，通信两端就无法协商建立数据通道的问题；当两端中的至少一端支持两种或两种以上数据通道协商方式时，通过两端对数据通道协商方式的协商确定，进而在此基础上完成数据通道的建立，使得两端能够简单、高效地建立数据通道，实现了不同终端、不同网络之间的互连互通。
在图11所示实施例的第一种可能的实施方式中，所述接收端和所述发送端中的一端支持的数据通道协商方式包括数据通道建立协议DCEP方式和会话描述协议SDP方式，且另一端支持的数据通道协商方式包括所述DCEP方式和所述SDP方式中的至少一种。
在图11所示实施例的第二种可能的实施方式中，
所述处理器1120，还用于根据所述第一提议属性行和所述接收端支持的数据通道协商方式确定两端均支持的数据通道协商方式；
所述处理器1120，还用于若所述两端均支持的数据通道协商方式有且只有DCEP方式，则确定同意采用的数据通道协商方式为所述DCEP方式，并生成携带有所述第一应答属性行的应答消息，以便所述发送端根据所述第一应答属性行检测出两端均支持所述DCEP方式后，通过所述DCEP方式与所述接收端之 间建立所述数据通道；
所述处理器1120，还用于若所述两端均支持的数据通道协商方式有且只有SDP方式，则确定同意采用的数据通道协商方式为所述SDP方式，并生成携带有所述第一应答属性行和第二应答属性行的应答消息，以便所述发送端读取所述第二应答属性行后，通过所述SDP方式与所述接收端之间建立所述数据通道；
所述处理器1120，还用于若所述两端均支持的数据通道协商方式为DCEP方式和SDP方式，则判断所述第二提议属性行中包括的所述数据通道关联的流标识为任意流标识符还是指定流标识符；其中，所述任意流标识符表示所述本次请求的数据通道协商方式为所述DCEP方式，所述指定流标识符表示所述本次请求的数据通道协商方式为所述SDP方式；若为所述任意流标识符，则确定同意采用的数据通道协商方式为所述DCEP方式，并生成携带有所述第一应答属性行的应答消息，以便所述发送端根据所述第一应答属性行检测出两端均支持所述DCEP方式后，通过所述DCEP方式与所述接收端之间建立所述数据通道；若为所述指定流标识符，则确定同意采用的数据通道协商方式为所述SDP方式，并生成携带有所述第一应答属性行和第二应答属性行的应答消息，以便所述发送端读取所述第二应答属性行后，通过所述SDP方式与所述接收端之间建立所述数据通道。
在图11所示实施例的第三种可能的实施方式中，所述第二应答属性行还包括指定流标识符；其中，当所述第二提议属性行中的流标识为所述任意流标识符时，所述第二应答属性行中的所述指定流标识符是所述接收端确定的；当所述第二提议属性行中的流标识为所述指定流标识符时，所述第二应答属性行中的所述指定流标识符与所述第二提议属性行中的所述指定流标识符相同。
在图11所示实施例的第四种可能的实施方式中，
所述处理器1120，还用于当所述提议消息中还包括第三提议属性行时，根据所述第三提议属性行和所述接收端在所述数据通道上支持的数据协议检测是否存在两端在所述数据通道上均支持的数据协议；其中，所述第三提议属性行是所述发送端根据所述发送端在所述数据通道上支持的数据协议生成的；
所述处理器1120，还用于若检测出存在两端在所述数据通道上均支持的数据协议，则根据两端在所述数据通道上均支持的数据协议生成对应于所述第三提议属性行的第三应答属性行，以便所述发送端根据所述第三应答属性行确定 在所述数据通道上传输的数据协议。
在图11所示实施例的第五种可能的实施方式中，
所述处理器1120，还用于根据所述第三提议属性行以及两端在所述数据通道上均支持的数据协议确定所需应答的第二提议属性行；其中，所述所需应答的第二提议属性行中的属性值包括的标签与两端在所述数据通道上均支持的数据协议对应的协议标识在所述第三提议属性行中关联的标签相同；
所述处理器1120，还用于生成对应于所述所需应答的第二提议属性行的第二应答属性行，所述第二应答属性行还包括标签，所述第二应答属性行中的标签与其对应的第二提议属性行中的标签相同。
应当理解的是，在本文中使用的，除非上下文清楚地支持例外情况，单数形式“一个”(“a”、“an”、“the”)旨在也包括复数形式。还应当理解的是，在本文中使用的“和/或”是指包括一个或者一个以上相关联地列出的项目的任意和所有可能组合。
上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。
本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。
以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (32)

  1. 一种数据通道建立方法，其特征在于，所述方法包括：
    发送端向接收端发送携带有第一提议属性行和第二提议属性行的提议消息；其中，所述第一提议属性行包括所述发送端支持的数据通道协商方式的信息，所述第二提议属性行包括本次请求的数据通道协商方式的信息，所述本次请求的数据通道协商方式为所述发送端支持的数据通道协商方式中的一种；
    发送端接收所述接收端发送的应答消息，所述应答消息是所述接收端根据所述第一提议属性行、所述第二提议属性行以及所述接收端支持的数据通道协商方式确定的；
    发送端根据所述应答消息与所述接收端之间建立数据通道；
    其中，所述发送端和所述接收端中的至少一端支持两种或者两种以上数据通道协商方式。
  2. 根据权利要求1所述的方法，其特征在于，所述发送端和所述接收端中的一端支持的数据通道协商方式包括数据通道建立协议DCEP方式和会话描述协议SDP方式，且另一端支持的数据通道协商方式包括所述DCEP方式和所述SDP方式中的至少一种。
  3. 根据权利要求1或2所述的方法，其特征在于，
    若所述本次请求的数据通道协商方式为DCEP方式，则所述第二提议属性行还包括任意流标识符，所述任意流标识符用于表示所述数据通道关联的流标识为任意的，以便所述接收端在确定出两端均支持的数据通道协商方式包括DCEP方式时，根据所述任意流标识符确定同意采用的数据通道协商方式为所述DCEP方式；
    或者，
    若所述本次请求的数据通道协商方式为DCEP方式，则所述第二提议属性行还包括任意流标识符，所述任意流标识符用于表示所述数据通道关联的流标识为任意的，以便所述接收端在确定出两端均支持的数据通道协商方式有且只有SDP方式时，生成包括所述数据通道关联的流标识为指定流标识符的第二应答属性行，所述指定流标识符是所述接收端确定的；
    或者，
    若所述本次请求的数据通道协商方式为SDP方式，则所述第二提议属性行还包括指定流标识符，所述指定流标识符用于表示所述数据通道关联的流标识为指定的，以便所述接收端在确定出两端均支持的数据通道协商方式包括SDP方式时，根据所述指定流标识符确定同意采用的数据通道协商方式为所述SDP方式；
    或者，
    若所述本次请求的数据通道协商方式为SDP方式，则所述第二提议属性行还包括指定流标识符，所述指定流标识符用于表示所述数据通道关联的流标识为指定的，以便所述接收端在确定出两端均支持的数据通道协商方式有且只有DCEP方式时，确定同意采用的数据通道协商方式为所述DCEP方式。
  4. 根据权利要求1至3任一所述的方法，其特征在于，所述提议消息还包括第三提议属性行，所述第三提议属性行包括所述发送端在所述数据通道上支持的数据协议的信息，以便所述接收端根据所述第三提议属性行和所述接收端在所述数据通道上支持的数据协议确定出两端在所述数据通道上均支持的数据协议。
  5. 根据权利要求4所述的方法，其特征在于，所述方法还包括：
    发送端根据所述发送端在所述数据通道上支持的数据协议对应的应用的数量a确定本次请求建立的所述数据通道的数量a，a≥1；其中，每种数据协议对应于至少一种应用；
    发送端根据所述本次请求的数据通道协商方式生成a个所述第二提议属性行。
  6. 根据权利要求5所述的方法，其特征在于，所述发送端根据所述本次请求的数据通道协商方式生成a个所述第二提议属性行，包括：
    若所述本次请求的数据通道协商方式为DCEP方式，则生成a个所述第二提议属性行；其中，每个第二提议属性行包括一个流标识和一个标签，且不同的第二提议属性行中包括的流标识均为任意流标识符，不同的第二提议属性行 中包括的标签为互不相同的标签，每个标签对应于一条数据通道；
    或者，
    若所述本次请求的数据通道协商方式为SDP方式，则生成a个所述第二提议属性行；其中，每个第二提议属性行包括一个流标识和一个标签，且不同的第二提议属性行中包括的流标识为互不相同的指定流标识符，不同的第二提议属性行中包括的标签为互不相同的标签，每个标签对应于一条数据通道。
  7. 根据权利要求6所述的方法，其特征在于，所述方法还包括：
    对于所述发送端在所述数据通道上支持的每一个数据协议，发送端获取所述数据协议对应的应用的数量；
    发送端根据所述数据协议对应的应用的数量为所述数据协议分配相同数量的标签，每个标签为a个所述第二提议属性行中包括的a个互不相同的标签中的一个；
    发送端将所述数据协议对应的协议标识与所述数据协议所分配的标签进行关联；
    发送端生成包括各个所述数据协议对应的协议标识以及每个协议标识关联的标签的第三提议属性行。
  8. 根据权利要求2至7任一所述的方法，其特征在于，所述发送端根据所述应答消息与所述接收端之间建立数据通道，包括：
    当所述应答消息中携带有对应于所述第二提议属性行的第二应答属性行时，通过所述SDP方式与所述接收端之间建立所述数据通道；
    其中，所述第二应答属性行是所述接收端确定同意采用的数据通道协商方式为所述SDP方式时生成的。
  9. 根据权利要求2至7任一所述的方法，其特征在于，所述发送端根据所述应答消息与所述接收端之间建立数据通道，包括：
    当所述应答消息中未携带有对应于所述第二提议属性行的第二应答属性行时，根据所述应答消息中携带的对应于所述第一提议属性行的第一应答属性行检测两端是否均支持所述DCEP方式；
    若检测出两端均支持所述DCEP方式，则通过所述DCEP方式与所述接收端之间建立所述数据通道。
  10. 根据权利要求4至7任一所述的方法，其特征在于，所述发送端接收所述接收端发送的应答消息之后，还包括：
    发送端读取所述应答消息中携带的对应于所述第三提议属性行的第三应答属性行，所述第三应答属性行是所述接收端根据所述第三提议属性行和所述接收端在所述数据通道上支持的数据协议确定出两端在所述数据通道上均支持的数据协议后生成的；
    发送端根据所述第三应答属性行确定在所述数据通道上传输的数据协议。
  11. 一种数据通道建立方法，其特征在于，所述方法包括：
    接收端接收发送端发送的携带有第一提议属性行和第二提议属性行的提议消息；其中，所述第一提议属性行包括所述发送端支持的数据通道协商方式的信息，所述第二提议属性行包括本次请求的数据通道协商方式的信息，所述本次请求的数据通道协商方式为所述发送端支持的数据通道协商方式中的一种；
    接收端根据所述第一提议属性行、所述第二提议属性行以及接收端支持的数据通道协商方式确定应答消息；
    接收端向所述发送端发送所述应答消息，以便所述发送端根据所述应答消息与所述接收端之间建立数据通道；
    其中，所述接收端和所述发送端中的至少一端支持两种或者两种以上数据通道协商方式。
  12. 根据权利要求11所述的方法，其特征在于，所述接收端和所述发送端中的一端支持的数据通道协商方式包括数据通道建立协议DCEP方式和会话描述协议SDP方式，且另一端支持的数据通道协商方式包括所述DCEP方式和所述SDP方式中的至少一种。
  13. 根据权利要求11或12所述的方法，其特征在于，所述接收端根据所述第一提议属性行、所述第二提议属性行以及接收端支持的数据通道协商方式 确定应答消息，包括：
    根据所述第一提议属性行和所述接收端支持的数据通道协商方式确定两端均支持的数据通道协商方式；
    若所述两端均支持的数据通道协商方式有且只有DCEP方式，则确定同意采用的数据通道协商方式为所述DCEP方式，并生成携带有所述第一应答属性行的应答消息，以便所述发送端根据所述第一应答属性行检测出两端均支持所述DCEP方式后，通过所述DCEP方式与所述接收端之间建立所述数据通道；
    若所述两端均支持的数据通道协商方式有且只有SDP方式，则确定同意采用的数据通道协商方式为所述SDP方式，并生成携带有所述第一应答属性行和第二应答属性行的应答消息，以便所述发送端读取所述第二应答属性行后，通过所述SDP方式与所述接收端之间建立所述数据通道；
    若所述两端均支持的数据通道协商方式为DCEP方式和SDP方式，则判断所述第二提议属性行中包括的所述数据通道关联的流标识为任意流标识符还是指定流标识符；其中，所述任意流标识符表示所述本次请求的数据通道协商方式为所述DCEP方式，所述指定流标识符表示所述本次请求的数据通道协商方式为所述SDP方式；若为所述任意流标识符，则确定同意采用的数据通道协商方式为所述DCEP方式，并生成携带有所述第一应答属性行的应答消息，以便所述发送端根据所述第一应答属性行检测出两端均支持所述DCEP方式后，通过所述DCEP方式与所述接收端之间建立所述数据通道；若为所述指定流标识符，则确定同意采用的数据通道协商方式为所述SDP方式，并生成携带有所述第一应答属性行和第二应答属性行的应答消息，以便所述发送端读取所述第二应答属性行后，通过所述SDP方式与所述接收端之间建立所述数据通道。
  14. 根据权利要求13所述的方法，其特征在于，所述第二应答属性行还包括指定流标识符；其中，当所述第二提议属性行中的流标识为所述任意流标识符时，所述第二应答属性行中的所述指定流标识符是所述接收端确定的；当所述第二提议属性行中的流标识为所述指定流标识符时，所述第二应答属性行中的所述指定流标识符与所述第二提议属性行中的所述指定流标识符相同。
  15. 根据权利要求11至14任一所述的方法，其特征在于，所述方法还包 括：
    当所述提议消息中还包括第三提议属性行时，接收端根据所述第三提议属性行和所述接收端在所述数据通道上支持的数据协议检测是否存在两端在所述数据通道上均支持的数据协议；其中，所述第三提议属性行是所述发送端根据所述发送端在所述数据通道上支持的数据协议生成的；
    若检测出存在两端在所述数据通道上均支持的数据协议，则接收端根据两端在所述数据通道上均支持的数据协议生成对应于所述第三提议属性行的第三应答属性行，以便所述发送端根据所述第三应答属性行确定在所述数据通道上传输的数据协议。
  16. 根据权利要求15所述的方法，其特征在于，所述方法还包括：
    接收端根据所述第三提议属性行以及两端在所述数据通道上均支持的数据协议确定所需应答的第二提议属性行；其中，所述所需应答的第二提议属性行中的属性值包括的标签与两端在所述数据通道上均支持的数据协议对应的协议标识在所述第三提议属性行中关联的标签相同；
    接收端生成对应于所述所需应答的第二提议属性行的第二应答属性行，所述第二应答属性行还包括标签，所述第二应答属性行中的标签与其对应的第二提议属性行中的标签相同。
  17. 一种通信设备，其特征在于，所述通信设备包括：
    发送模块，用于向接收端发送携带有第一提议属性行和第二提议属性行的提议消息；其中，所述第一提议属性行包括所述发送端支持的数据通道协商方式的信息，所述第二提议属性行包括本次请求的数据通道协商方式的信息，所述本次请求的数据通道协商方式为所述发送端支持的数据通道协商方式中的一种；
    应答接收模块，用于接收所述接收端发送的应答消息，所述应答消息是所述接收端根据所述第一提议属性行、所述第二提议属性行以及所述接收端支持的数据通道协商方式确定的；
    通道建立模块，用于根据所述应答消息与所述接收端之间建立数据通道；
    其中，所述发送端和所述接收端中的至少一端支持两种或者两种以上数据 通道协商方式。
  18. 根据权利要求17所述的通信设备，其特征在于，所述发送端和所述接收端中的一端支持的数据通道协商方式包括数据通道建立协议DCEP方式和会话描述协议SDP方式，且另一端支持的数据通道协商方式包括所述DCEP方式和所述SDP方式中的至少一种。
  19. 根据权利要求17或18所述的通信设备，其特征在于，
    若所述本次请求的数据通道协商方式为DCEP方式，则所述第二提议属性行还包括任意流标识符，所述任意流标识符用于表示所述数据通道关联的流标识为任意的，以便所述接收端在确定出两端均支持的数据通道协商方式包括DCEP方式时，根据所述任意流标识符确定同意采用的数据通道协商方式为所述DCEP方式；
    或者，
    若所述本次请求的数据通道协商方式为DCEP方式，则所述第二提议属性行还包括任意流标识符，所述任意流标识符用于表示所述数据通道关联的流标识为任意的，以便所述接收端在确定出两端均支持的数据通道协商方式有且只有SDP方式时，生成包括所述数据通道关联的流标识为指定流标识符的第二应答属性行，所述指定流标识符是所述接收端确定的；
    或者，
    若所述本次请求的数据通道协商方式为SDP方式，则所述第二提议属性行还包括指定流标识符，所述指定流标识符用于表示所述数据通道关联的流标识为指定的，以便所述接收端在确定出两端均支持的数据通道协商方式包括SDP方式时，根据所述指定流标识符确定同意采用的数据通道协商方式为所述SDP方式；
    或者，
    若所述本次请求的数据通道协商方式为SDP方式，则所述第二提议属性行还包括指定流标识符，所述指定流标识符用于表示所述数据通道关联的流标识为指定的，以便所述接收端在确定出两端均支持的数据通道协商方式有且只有DCEP方式时，确定同意采用的数据通道协商方式为所述DCEP方式。
  20. 根据权利要求17至19任一所述的通信设备，其特征在于，所述提议消息还包括第三提议属性行，所述第三提议属性行包括所述发送端在所述数据通道上支持的数据协议的信息，以便所述接收端根据所述第三提议属性行和所述接收端在所述数据通道上支持的数据协议确定出两端在所述数据通道上均支持的数据协议。
  21. 根据权利要求20所述的通信设备，其特征在于，所述通信设备还包括：
    数量确定模块，用于根据所述发送端在所述数据通道上支持的数据协议对应的应用的数量a确定本次请求建立的所述数据通道的数量a，a≥1；其中，每种数据协议对应于至少一种应用；
    生成模块，用于根据所述本次请求的数据通道协商方式生成a个所述第二提议属性行。
  22. 根据权利要求21所述的通信设备，其特征在于，所述生成模块，包括：第一生成单元；或者，第二生成单元；
    所述第一生成单元，用于若所述本次请求的数据通道协商方式为DCEP方式，则生成a个所述第二提议属性行；其中，每个第二提议属性行包括一个流标识和一个标签，且不同的第二提议属性行中包括的流标识均为任意流标识符，不同的第二提议属性行中包括的标签为互不相同的标签，每个标签对应于一条数据通道；
    所述第二生成单元，用于若所述本次请求的数据通道协商方式为SDP方式，则生成a个所述第二提议属性行；其中，每个第二提议属性行包括一个流标识和一个标签，且不同的第二提议属性行中包括的流标识为互不相同的指定流标识符，不同的第二提议属性行中包括的标签为互不相同的标签，每个标签对应于一条数据通道。
  23. 根据权利要求22所述的通信设备，其特征在于，所述通信设备还包括：
    数量获取模块，用于对于所述发送端在所述数据通道上支持的每一个数据协议，获取所述数据协议对应的应用的数量；
    标签分配模块，用于根据所述数据协议对应的应用的数量为所述数据协议分配相同数量的标签，每个标签为a个所述第二提议属性行中包括的a个互不相同的标签中的一个；
    标签关联模块，用于将所述数据协议对应的协议标识与所述数据协议所分配得的标签进行关联；
    属性行生成模块，用于生成包括各个所述数据协议对应的协议标识以及每个协议标识关联的标签的第三提议属性行。
  24. 根据权利要求18至23任一所述的通信设备，其特征在于，所述通道建立模块，包括：第一建立单元；
    所述第一建立单元，用于当所述应答消息中携带有对应于所述第二提议属性行的第二应答属性行时，通过所述SDP方式与所述接收端之间建立所述数据通道；
    其中，所述第二应答属性行是所述接收端确定同意采用的数据通道协商方式为所述SDP方式时生成的。
  25. 根据权利要求18至23任一所述的通信设备，其特征在于，所述通道建立模块，包括：方式检测单元和第二建立单元；
    所述方式检测单元，用于当所述应答消息中未携带有对应于所述第二提议属性行的第二应答属性行时，根据所述应答消息中携带的对应于所述第一提议属性行的第一应答属性行检测两端是否均支持所述DCEP方式；
    所述第二建立单元，用于若检测出两端均支持所述DCEP方式，则通过所述DCEP方式与所述接收端之间建立所述数据通道。
  26. 根据权利要求20至23任一所述的通信设备，其特征在于，所述通信设备还包括：
    应答读取模块，用于读取所述应答消息中携带的对应于所述第三提议属性行的第三应答属性行，所述第三应答属性行是所述接收端根据所述第三提议属性行和所述接收端在所述数据通道上支持的数据协议确定出两端在所述数据通道上均支持的数据协议后生成的；
    协议确定模块，用于根据所述第三应答属性行确定在所述数据通道上传输的数据协议。
  27. 一种通信设备，其特征在于，所述通信设备包括：
    接收模块，用于接收发送端发送的携带有第一提议属性行和第二提议属性行的提议消息；其中，所述第一提议属性行包括所述发送端支持的数据通道协商方式的信息，所述第二提议属性行包括本次请求的数据通道协商方式的信息，所述本次请求的数据通道协商方式为所述发送端支持的数据通道协商方式中的一种；
    应答确定模块，用于根据所述第一提议属性行、所述第二提议属性行以及接收端支持的数据通道协商方式确定应答消息；
    应答发送模块，用于向所述发送端发送所述应答消息，以便所述发送端根据所述应答消息与所述接收端之间建立数据通道；
    其中，所述接收端和所述发送端中的至少一端支持两种或者两种以上数据通道协商方式。
  28. 根据权利要求27所述的通信设备，其特征在于，所述接收端和所述发送端中的一端支持的数据通道协商方式包括数据通道建立协议DCEP方式和会话描述协议SDP方式，且另一端支持的数据通道协商方式包括所述DCEP方式和所述SDP方式中的至少一种。
  29. 根据权利要求27或28所述的通信设备，其特征在于，所述应答确定模块，包括：方式确定单元，和下面至少一个单元：第一应答单元，第二应答单元，和第三应答单元；
    所述方式确定单元，用于根据所述第一提议属性行和所述接收端支持的数据通道协商方式确定两端均支持的数据通道协商方式；
    所述第一应答单元，用于若所述两端均支持的数据通道协商方式有且只有DCEP方式，则确定同意采用的数据通道协商方式为所述DCEP方式，并生成携带有所述第一应答属性行的应答消息，以便所述发送端根据所述第一应答属性行检测出两端均支持所述DCEP方式后，通过所述DCEP方式与所述接收端之 间建立所述数据通道；
    所述第二应答单元，用于若所述两端均支持的数据通道协商方式有且只有SDP方式，则确定同意采用的数据通道协商方式为所述SDP方式，并生成携带有所述第一应答属性行和第二应答属性行的应答消息，以便所述发送端读取所述第二应答属性行后，通过所述SDP方式与所述接收端之间建立所述数据通道；
    所述第三应答单元，用于若所述两端均支持的数据通道协商方式为DCEP方式和SDP方式，则判断所述第二提议属性行中包括的所述数据通道关联的流标识为任意流标识符还是指定流标识符；其中，所述任意流标识符表示所述本次请求的数据通道协商方式为所述DCEP方式，所述指定流标识符表示所述本次请求的数据通道协商方式为所述SDP方式；若为所述任意流标识符，则确定同意采用的数据通道协商方式为所述DCEP方式，并生成携带有所述第一应答属性行的应答消息，以便所述发送端根据所述第一应答属性行检测出两端均支持所述DCEP方式后，通过所述DCEP方式与所述接收端之间建立所述数据通道；若为所述指定流标识符，则确定同意采用的数据通道协商方式为所述SDP方式，并生成携带有所述第一应答属性行和第二应答属性行的应答消息，以便所述发送端读取所述第二应答属性行后，通过所述SDP方式与所述接收端之间建立所述数据通道。
  30. 根据权利要求29所述的通信设备，其特征在于，所述第二应答属性行还包括指定流标识符；其中，当所述第二提议属性行中的流标识为所述任意流标识符时，所述第二应答属性行中的所述指定流标识符是所述接收端确定的；当所述第二提议属性行中的流标识为所述指定流标识符时，所述第二应答属性行中的所述指定流标识符与所述第二提议属性行中的所述指定流标识符相同。
  31. 根据权利要求27至30任一所述的通信设备，其特征在于，所述通信设备还包括：
    协议检测模块，用于当所述提议消息中还包括第三提议属性行时，根据所述第三提议属性行和所述接收端在所述数据通道上支持的数据协议检测是否存在两端在所述数据通道上均支持的数据协议；其中，所述第三提议属性行是所述发送端根据所述发送端在所述数据通道上支持的数据协议生成的；
    协议应答模块，用于若检测出存在两端在所述数据通道上均支持的数据协议，则根据两端在所述数据通道上均支持的数据协议生成对应于所述第三提议属性行的第三应答属性行，以便所述发送端根据所述第三应答属性行确定在所述数据通道上传输的数据协议。
  32. 根据权利要求31所述的通信设备，其特征在于，所述通信设备还包括：
    确定模块，用于根据所述第三提议属性行以及两端在所述数据通道上均支持的数据协议确定所需应答的第二提议属性行；其中，所述所需应答的第二提议属性行中的属性值包括的标签与两端在所述数据通道上均支持的数据协议对应的协议标识在所述第三提议属性行中关联的标签相同；
    应答模块，用于生成对应于所述所需应答的第二提议属性行的第二应答属性行，所述第二应答属性行还包括标签，所述第二应答属性行中的标签与其对应的第二提议属性行中的标签相同。
PCT/CN2015/078972 2014-05-29 2015-05-14 数据通道建立方法和通信设备 WO2015180570A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201410232844.9 2014-05-29
CN201410232844.9A CN105227418B (zh) 2014-05-29 2014-05-29 数据通道建立方法和通信设备

Publications (1)

Publication Number Publication Date
WO2015180570A1 true WO2015180570A1 (zh) 2015-12-03

Family

ID=54698069

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2015/078972 WO2015180570A1 (zh) 2014-05-29 2015-05-14 数据通道建立方法和通信设备

Country Status (2)

Country Link
CN (1) CN105227418B (zh)
WO (1) WO2015180570A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023178590A1 (en) * 2022-03-24 2023-09-28 Qualcomm Incorporated Service-based architecture for providing a data channel associated with an internet protocol multimedia subsystem
WO2023185854A1 (zh) * 2022-03-29 2023-10-05 中国移动通信有限公司研究院 一种信息处理方法、装置、通信设备和存储介质

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113348685B (zh) * 2019-01-25 2023-06-06 华为技术有限公司 一种建立蓝牙数据通道的方法及装置
CN112738644B (zh) * 2021-04-01 2021-07-09 浙江华创视讯科技有限公司 一种基于WebRTC的视频流传输方法和装置
CN113556404A (zh) * 2021-08-03 2021-10-26 广东九博科技股份有限公司 一种设备内部单盘间的通信方法及系统
CN115941761A (zh) * 2021-08-04 2023-04-07 中国移动通信有限公司研究院 一种通信、数据通道的建立方法、设备及存储介质
CN117177304A (zh) * 2022-05-25 2023-12-05 中国移动通信有限公司研究院 协商方法、装置、网络设备及终端

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101309223A (zh) * 2008-07-02 2008-11-19 中兴通讯股份有限公司 数据通道建立方法及系统

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101022358A (zh) * 2006-10-17 2007-08-22 信息产业部电信研究院 在ip电信网系统中实现资源聚类和管理控制的方法
CN101990227B (zh) * 2009-08-07 2015-10-21 中兴通讯股份有限公司 接入服务网络网元间数据通道的建立方法及装置
US8863126B2 (en) * 2011-12-29 2014-10-14 Oracle International Corporation Java virtual machine embedded in a native mobile application

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101309223A (zh) * 2008-07-02 2008-11-19 中兴通讯股份有限公司 数据通道建立方法及系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
EJZAK, R. ET AL.: "SDP-based WebRTC data channel negotiation", IETF INTERNET -DRAFT, 14 October 2013 (2013-10-14) *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023178590A1 (en) * 2022-03-24 2023-09-28 Qualcomm Incorporated Service-based architecture for providing a data channel associated with an internet protocol multimedia subsystem
WO2023185854A1 (zh) * 2022-03-29 2023-10-05 中国移动通信有限公司研究院 一种信息处理方法、装置、通信设备和存储介质

Also Published As

Publication number Publication date
CN105227418B (zh) 2018-10-09
CN105227418A (zh) 2016-01-06

Similar Documents

Publication Publication Date Title
WO2015180570A1 (zh) 数据通道建立方法和通信设备
US7904521B2 (en) Method for transferring chat messages by establishing chat room data transfer channel
US10354618B2 (en) Wireless communication system for offline participation in a display session
US8473617B2 (en) Media client architecture for networked communication devices
JP5064414B2 (ja) Ｉｐマルチメディアサブシステムを基盤とする双方向メディアセッション確立システム、方法、および、装置
EP2077022B1 (en) Methods of network-initiated partial session transfer
CN106850399B (zh) 一种基于WebRTC技术即时消息的通信方法
US20060149811A1 (en) Method for remotely controlling media devices via a communication network
JP2006525693A (ja) マルチメディア・ストリーミングにおけるクライアント速度機能のシグナリング方法
EP2129044A1 (en) Method, system and service for transferring session control power
WO2013097457A1 (zh) 云计算环境中实现voip通话的方法、装置和系统
CN102215276A (zh) 一种视频监控系统及媒体穿越网络地址转换设备的方法
WO2019184262A1 (zh) 多类型媒体数据网络地址转换穿越方法、终端及系统
WO2010025676A1 (zh) 实现流媒体通信的方法、装置及系统
WO2022241990A1 (zh) 一种媒体传输链路管理方法、装置及存储介质
WO2018050116A9 (zh) 一种视频会议系统中端口复用方法和服务器和计算机存储介质
US9912623B2 (en) Systems and methods for adaptive context-aware control of multimedia communication sessions
CN101626345A (zh) 一种报文处理方法及家庭网关中的实时流协议应用层网关
WO2012113240A1 (zh) 一种多媒体会话的协商方法、相关设备和系统
CN109361671A (zh) 一种基于sip协议的流媒体传输架构方法
CN104994067A (zh) Sip网络访问rtsp监控网络的系统及方法
WO2017152566A1 (zh) 一种协商媒体编解码的方法，及一种终端设备
WO2023071656A1 (zh) 信息传输方法及装置
WO2008086741A1 (fr) Procédé, dispositif et système pour réaliser un service de télécopie et. 38 sur internet
WO2023005316A1 (zh) 通信方法、信令控制网元、媒体控制网元及通信系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15798757

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15798757

Country of ref document: EP

Kind code of ref document: A1