CN103095664A - Ip多媒体会话建立方法和系统 - Google Patents

Abstract

本发明涉及IP多媒体会话。更具体地，本发明尤其涉及在不利用中心服务器的前提下建立IP多媒体会话的方法和系统。根据本发明的一个方面，提供了一种用于建立IP多媒体会话的方法，包括：接收多个IP多媒体会话参与设备的注册请求；在所述参与设备中选择服务设备；以及利用所选择的服务设备在所述多个参与设备间建立IP多媒体会话。利用该方法，能够不依赖于中心服务器而在参与者之间建立IP多媒体会话。

Description

IP多媒体会话建立方法和系统

技术领域

本发明涉及IP多媒体会话。更具体地，本发明尤其涉及在不利用中心服务器的前提下建立IP多媒体会话的方法和系统。

背景技术

目前，随着电信网和国际互联网的融合趋势进一步加强，通过网际协议IP(Internet Protocol)传输语音/视频等多媒体信号的技术得到日益广泛的应用。在多媒体信号传输过程中，建立IP多媒体会话是至关重要的一步，目前存在很多用于建立IP多媒体会话的公有或私有协议，例如会话初始协议SIP以及Skype等。IP多媒体子系统IMS(IP Multimedia Sub-system)是IP多媒体会话的一种典型应用，IMS是由3GPP定义的网络结构，其采用会话初始协议SIP建立多媒体会话。通过IP多媒体子系统，终端设备可以利用网际协议IP(InternetProtocol)进行多媒体信息的传输，例如语音、图像、视频等内容。其具体的应用可能包括举行电话会议、视频会议等。

传统的IP多媒体会话的建立是依赖于中心服务器的(例如IMS系统)。中心服务器包括中心应用服务器AS(Application Server)以及中心媒体服务器MS(Media Server)，其中应用服务器AS用于建立IP多媒体会话(例如根据会话初始协议SIP建立会话)并控制会话的业务逻辑，而媒体服务器MS则用于传输、处理实际的多媒体信号。这种依赖于中心服务器的IP多媒体会话的好处是能够支持SIP、Skype等公有或私有会话协议从而处理复杂的业务逻辑，并且其定义的接口与IETF的因特网标准也是一致的。但是，依赖于中心服务器来建立并维持IP多媒体会话具有过度依赖中心服务器的缺点，中心服务器端的计算压力较大，且没有充分利用终端设备的计算能力。例如，如果企业内容有少部分位于同一城市的员工想召开电话会议，也必须借助该企业位于国外的远程中心服务器建立IP多媒体会话，从而导致过度的远程传输。

另一种建立IP多媒体会话的方法是在点对点传输P2P环境下利用SIP等协议建立IP多媒体会话(如P2P-SIP)，它的好处是不依赖于任何的中心服务器，但显著的缺点是：P2P点对点传输的规范导致所建立的IP多媒体会话环境中不存在任何具有应用服务或媒体服务功能的终端，所有的“点”与其它的“点”之间都是两两互联，因此发现设备、建立会话、协商、控制的过程十分复杂，并且仅能支持简单的语音或视频通信，而不能像传统的IP多媒体会话一样支持复杂的业务逻辑。

发明内容

考虑到上述存在的问题，本发明的目的之一在于提供一种能够不依赖于中心服务器而在参与者之间建立IP多媒体会话，并且所建立的IP多媒体会话能够像传统的IP多媒体会话一样支持复杂的业务逻辑的方法和系统。本发明的另一目的在于提供一种能够根据IP多媒体会话环境中的设备运行情况动态切换媒体服务设备或应用服务设备的方法和系统。

根据本发明的一个方面，提供了一种用于建立IP多媒体会话的方法，包括：接收多个IP多媒体会话参与设备的注册请求；在所述参与设备中选择服务设备；以及利用所选择的服务设备在所述多个参与设备间建立IP多媒体会话。

根据本发明的一个实施例，所述服务设备包括下列中的一个或多个：应用服务设备或媒体服务设备。

根据本发明的另一方面，提供了一种用于建立IP多媒体会话的系统，包括：注册请求接收装置，被配置为接收多个IP多媒体会话参与设备的注册请求；服务设备选择装置，被配置为在所述多个参与设备中选择服务设备；以及IP多媒体会话建立装置，被配置为利用所选择的服务设备在所述多个参与设备间建立IP多媒体会话。。

根据本发明的方法和系统，可以不依赖于中心服务器而在参与IP多媒体会话的参与设备中选择担任媒体服务设备和应用服务设备的参与设备，从而构建边缘化的IP多媒体会话以节省中心服务器端的运算资源，同时所建立的边缘化的IP多媒体会话由于同样具有媒体服务设备和应用服务设备，因此也可以支持像传统的依赖于中心服务器的IP多媒体会话环境所能支持的复杂业务逻辑。另外，根据本发明的方法和系统，还可以根据IP多媒体会话环境中的设备运行情况动态切换媒体服务设备或应用服务设备。

附图说明

通过对结合附图所示出的实施方式进行详细说明，本发明的上述以及其他特征将更加明显，本发明附图中相同的标号表示相同或相似的部件。在附图中，

图1示出了适于用来实现本发明实施方式的示例性计算系统100的框图。

图2示出了根据本发明一个实施例的用于建立IP多媒体会话的方法的流程图；

图3示出了根据本发明另一实施例的用于建立IP多媒体会话的方法的流程图；

图4示出了根据本发明一个实施例的用于建立IP多媒体会话的系统的框图；

图5示出了根据本发明一实施例的用于基于SIP协议建立IP多媒体会话(初始建立阶段)的信令流程图；

图6示出了根据本发明一实施例的用于基于SIP协议建立IP多媒体会话(切换阶段)的信令流程图；

图7示出了以SIP协议为例选择媒体服务设备和应用服务设备的示意图；

图8示出了以SIP协议为例切换媒体服务设备和应用服务设备的示意图。

具体实施方式

在下文中，将参考附图通过实施方式对本发明提供的用于建立IP多媒体会话的方法和系统进行详细地描述。

所属技术领域的技术人员知道，本发明的多个方面可以体现为系统、方法或计算机程序产品。因此，本发明的多个方面可以具体实现为以下形式，即，可以是完全的硬件、完全的软件(包括固件、驻留软件、微代码等)、或者本文一般称为“电路”、“模块”或“系统”的软件部分与硬件部分的组合。此外，本发明的多个方面还可以采取体现在一个或多个计算机可读介质中的计算机程序产品的形式，该计算机可读介质中包含计算机可用的程序码。

可以使用一个或多个计算机可读的介质的任何组合。计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质例如可以是——但不限于——电的、磁的、光的、电磁的、红外线的、或半导体的系统、装置、器件或任何以上的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括以下：有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任何合适的组合。在本文件的语境中，计算机可读存储介质可以是任何包含或存储程序的有形的介质，该程序被指令执行系统、装置或者器件使用或者与其结合使用。

计算机可读的信号介质可包括在基带中或者作为载波一部分传播的、其中体现计算机可读的程序码的传播的数据信号。这种传播的信号可以采用多种形式，包括——但不限于——电磁信号、光信号或任何以上合适的组合。计算机可读的信号介质可以是并非为计算机可读存储介质、但是能发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序的任何计算机可读介质。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括——但不限于——无线、电线、光缆、RF等等，或者任何合适的上述组合。

计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括—但不限于——无线、电线、光缆、RF等等，或者任何合适的上述组合。

用于执行本发明的操作的计算机程序码，可以以一种或多种程序设计语言的任何组合来编写，所述程序设计语言包括面向对象的程序设计语言-诸如Java、Smalltalk、C++之类，还包括常规的过程式程序设计语言-诸如“C”程序设计语言或类似的程序设计语言。程序码可以完全地在用户的计算上执行、部分地在用户的计算机上执行、作为一个独立的软件包执行、部分在用户的计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在后一种情形中，远程计算机可以通过任何种类的网络——包括局域网(LAN)或广域网(WAN)-连接到用户的计算机，或者，可以(例如利用因特网服务提供商来通过因特网)连接到外部计算机。

以下参照按照本发明实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述本发明的多个方面。要明白的是，流程图和/或框图的每个方框以及流程图和/或框图中各方框的组合，都可以由计算机程序指令实现。这些计算机程序指令可以提供给通用计算机、专用计算机或其它可编程数据处理装置的处理器，从而生产出一种机器，使得通过计算机或其它可编程数据处理装置执行的这些指令，产生实现流程图和/或框图中的方框中规定的功能/操作的装置。

也可以把这些计算机程序指令存储在能指令计算机或其它可编程数据处理装置以特定方式工作的计算机可读介质中，这样，存储在计算机可读介质中的指令产生一个包括实现流程图和/或框图中的方框中规定的功能/操作的指令装置(instruction means)的制造品。

也可以把计算机程序指令加载到计算机或其它可编程数据处理装置上，使得在计算机或其它可编程数据处理装置上执行一系列操作步骤，以产生计算机实现的过程，从而在计算机或其它可编程装置上执行的指令就提供实现流程图和/或框图中的方框中规定的功能/操作的过程。

下面参看图1。图1示出了适于用来实现本发明实施方式的示例性计算系统100的框图。如所示，计算机系统100可以包括：CPU(中央处理单元)101、RAM(随机存取存储器)102、ROM(只读存储器)103、系统总线104、硬盘控制器105、键盘控制器106、串行接口控制器107、并行接口控制器108、显示控制器109、硬盘110、键盘111、串行外部设备112、并行外部设备113和显示器114。在这些设备中，与系统总线104耦合的有CPU 101、RAM 102、ROM 103、硬盘控制器105、键盘控制器106、串行控制器107、并行控制器108和显示控制器109。硬盘110与硬盘控制器105耦合，键盘111与键盘控制器106耦合，串行外部设备112与串行接口控制器107耦合，并行外部设备113与并行接口控制器108耦合，以及显示器114与显示控制器109耦合。应当理解，图1所述的结构框图仅仅为了示例的目的而示出的，而不是对本发明范围的限制。在某些情况下，可以根据具体情况而增加或者减少某些设备。

图2示出了根据本发明一个实施例的用于建立IP多媒体会话的方法的流程图。

图2所示的方法从步骤201开始，在步骤201中，接收多个IP多媒体会话参与设备的注册请求。IP多媒体会话参与设备指的是请求建立或加入IP多媒体会话的终端设备，其可能包括移动电话、个人掌上电脑PDA、台式计算机等任何可以接收或传输多媒体信号的电子设备。根据本发明的一个实施例，参与设备的注册请求是在建立IP多媒体会话前预先向远程目录服务器(Directory Server)提交的。例如，预定某时刻召开一个电话会议，那么受邀请的终端可以在预定时刻前主动或自动地向远程目录服务器注册。根据本发明的另一实施例，参与设备的注册请求是在建立多媒体会话的过程中向担任主持设备(Moderator Device)的参与设备发出的，主持设备的作用仅仅是主持IP多媒体会话的建立过程，并不意味着主持设备即为媒体服务器或应用服务器。

根据本发明的一个实施例，IP多媒体会话参与设备支持用于激活媒体服务功能或应用服务功能的IP多媒体会话协议栈。根据本发明的一个实施例，IP多媒体会话协议栈为会话初始协议SIP协议栈。根据本发明的另一实施例，IP多媒体会话协议栈为Skype协议栈。当然，任何其它公有或私有的IP多媒体会话协议均可用于实现本发明。

接下来，图2所示的方法进行至步骤202，在所述参与设备中选择服务设备。根据本发明一实施例，服务设备包括媒体服务设备、应用服务设备中的至少之一。媒体服务设备即为担任媒体服务器MS角色的参与设备，而应用服务设备即为担任应用服务器AS角色的参与设备。在IP多媒体会话中，应用服务器AS用于建立IP多媒体会话(例如根据会话初始协议SIP建立会话)并控制会话的业务逻辑，而媒体服务器MS则用于传输、处理实际的多媒体信号。

根据本发明的一个实施例，根据参与设备的服务质量QoS参数选择媒体服务设备和应用服务设备。QoS参数包括可用性、吞吐量、时延、时延变化(抖动)、丢包率、乱序率等。根据本发明的另一实施例，根据参与设备的硬件性能选择媒体服务设备和应用服务设备。设备的性能参数包括CPU频率、CPU使用状态、内存大小、内存使用状态、带宽、带宽使用率等。根据本发明再一实施例，综合结合参与设备的QoS参数和硬件性能选择媒体服务设备和应用服务设备。

根据本发明的一个实施例，将参与设备中性能最好或者QoS参数指标最好的设备选为媒体服务设备。将参与设备中性能其次或者Qos参数指标其次的设备选为应用服务设备。这样做的理由是：媒体服务设备主要用于传输实际的多媒体信号，因此对设备性能要求较高。当然本领域技术人员应当理解，如何依据各种参数、指标选择媒体服务设备或应用服务设备完全可以取决于预定的选择规则，并不影响实现本发明的发明目的。

根据本发明的一个实施例，步骤202中的选择过程可能包括协商。例如，某个参与设备的性能综合评分很高，本应被选为服务设备，但是该参与设备或其它参与设备出于数据安全考虑不同意将其选为媒体服务设备，宁愿选择性能一般的参与设备作为服务设备，这种协商也是允许的，也属于“选择”的范畴。

根据本发明的一个实施例，媒体服务设备与应用服务设备为同一参与设备。根据本发明的另一实施例，媒体服务设备与应用服务设备为不同的参与设备。

接下来，进行至步骤203，利用所选择的媒体服务设备和应用服务设备在多个参与设备间建立IP多媒体会话。由于已经在参与设备中选中了媒体服务设备和应用服务设备，从而相当于具有了传统IP多媒体会话中的媒体服务器和应用服务器，因此可以根据具体的会话协议，利用本领域的公知技术常识在步骤203中建立起多个参与设备间的IP多媒体会话。

图7中给出了一个以SIP协议为例选择媒体服务设备和应用服务设备的示意图。如图7所示，参与设备A-E试图在不借助中心服务器的情况下建立IP多媒体会话，依据QoS参数指标和设备性能指标对参与设备A-E的性能作出综合评分：设备A为2.2分，设备B是6.0分，设备C是12.4分，设备D是6.8分，设备E是5.0分。那么假设预定的规则是：“综合评分最高的参与设备选为媒体服务设备，综合评分第二高的设备选为应用服务设备”，则选择设备C为媒体服务设备，选择设备D为应用服务设备。进一步如图4中所示，虚线表示SIP信令传输流，而实线表示实际多媒体信号传输流。因此图7中所有的参与设备所接收到的多媒体信号(实线)均来自设备C，而所有的SIP信令均来自设备D。在图7所示出的建立好的IP多媒体会话中，只有参与设备在其中，而并不依赖于中心媒体服务器或中心应用服务器。

如上所述可以看出，通过图2及图7所示的方法，能够不依赖于中心服务器而在参与者之间建立IP多媒体会话。并且由于图4中示出的IP多媒体会话并非基于P2P的点到点传输(例如设备A和设备B之间传输多媒体信号是通过设备C进行的，而并非直接传输)，因此图4中所建立的IP多媒体会话也能够像传统的IP多媒体会话一样支持复杂的业务逻辑的方法和系统。

图3示出了根据本发明另一实施例的用于建立IP多媒体会话的方法的流程图。

图3所示的方法从步骤301开始。在步骤301中，设定性能指标参数阈值范围。考虑到IP多媒体会话建立起之后，有可能在运行过程中先前被选为媒体服务设备或应用服务设备的参与设备的性能发生变化，这种变化产生的原因有多种，例如包括但不限于：有新的参与设备加入IP多媒体会话、被选为媒体服务设备或应用服务设备的参与设备执行其它工作负载等。因此，需要在IP多媒体会话建立后根据需要动态地切换媒体服务设备或应用服务设备。设定性能指标阈值参数范围的目的就是触发所述切换操作。参数阈值范围可以根据经验性的历史数据设定，或者根据系统、网络环境的变化而随时调整。

接下来在步骤302中，监控所选择的媒体服务设备和应用服务设备。根据本发明一实施例，这里所指的监控包括监控服务设备的QoS参数。关于QoS参数的具体含义在上文已有说明。根据本发明一实施例，监控是实时的、连续的。根据本发明另一实施例，监控是按照一定的时间间隔进行取样的。

在步骤303中，判断所监控到的媒体服务设备或应用服务设备的QoS参数是否超过所设定的阈值范围的下限值。如果超过下限值，则说明服务设备的QoS水平已经下降到一定程度，应当进行切换服务设备的准备工作。于是进入步骤304，判断目标服务设备是否已定位。这里所指的目标服务设备即为一旦真的触发切换所要切换至的服务设备，包括目标应用服务设备和目标媒体服务设备。如果步骤303的判断结果为否，则返回步骤302，继续监控并判断。

如果在步骤304的判断结果为否，则进行至步骤306，定位要切换至的目标媒体服务设备或目标应用服务设备。这里定位目标服务设备的操作类似于图2所示的方法中的步骤202选择媒体服务设备和应用服务设备的操作，同样是依据设备的硬件性能和QoS参数指标进行选择。需要指出的是，步骤306与步骤202不同之处在于：步骤306中定位要切换至的目标服务设备既可以是中心服务器，也可以是其它参与设备(例如新加入IP多媒体会话的参与设备)。之所以目标服务设备可能包括中心服务器(中心应用服务器和中心媒体服务器)，是因为新加入的参与设备可能导致所有的参与设备的QoS参数均不满足担任媒体服务设备或应用服务设备的要求，因此只能切换至中心服务器。这一点也说明了利用本发明的技术方案可以实现在参与设备间自行组建的不依赖于中心服务器的IP多媒体会话可以随时自由地切换至传统的依赖于中心服务器的会话模式。

接下来进行至步骤307，将当前信令控制参数与信息同步至所定位的目标应用服务设备。由于此时真正进行切换的时机尚未到来，而仅仅是切换前的预备阶段，因此必须在原应用服务设备和目标应用服务设备上同时处理、传输信令控制信息，而不能将原应用服务设备灭活。根据本发明一实施例，信令控制信息包括诸如在电话会议中哪个参与设备在何种条件下有权限听到语音等内容。

除了同步信令控制参数与信息外，还需要在步骤308中将当前媒体控制参数与信息同步至所定位的目标媒体服务设备。根据本发明一实施例，步骤308中同步的仅仅是媒体控制参数与信息，而并非实际的多媒体信号。也就是说，实际的多媒体信号仍然仅仅由原媒体服务设备传输，不会同时由所定位的目标媒体服务设备传输。这样做的原因是：如果同时传输两套多媒体信号，会造成大量的带宽和计算资源的浪费。虽然只传输一套多媒体信号可能导致将来真正切换时出现部分多媒体数据包丢失的情况，但是可以利用现有技术中比较成熟的丢包解决方案来克服此问题，并不需要在准备切换的阶段就传输两套多媒体信号。当然，这只是一种优选实施例，本领域技术人员如果不考虑带宽和计算资源的消耗问题，完全可以像信令控制信息那样在准备切换的阶段就传输两套多媒体信号。

随后，图3所示的方法返回至步骤302，继续监控。

如果在步骤304中的判断结果为是，那么进行至步骤305，判断监控到的服务设备的QoS参数值是否超过预定参数阈值的上限。如果否，那么说明仍不需要真正进行切换，返回至步骤302继续监控并进行后续的判断参数值的步骤。如果步骤305的判断结果为是，则说明已经到了真正进行切换的时机，从而进行至步骤309，通知多个参与设备监听新的端口。之所以要监听新的端口，是因为在准备切换阶段信令信息就已经由原应用服务设备和目标应用服务设备同时传输，因此每个参与设备都需要启动两个端口来同时接收由这两个应用服务设备发出的信令控制信息(准备切换阶段)，而到了真正切换时，对应于原应用服务设备的端口就没有必要继续使用了，因此需要通知参与设备监听对应于目标应用服务设备的端口。以SIP协议为例，通常计算机启动默认的5060端口监听SIP信息，那么在切换准备阶段，为了监听目标应用服务设备的SIP信息，必须启动一个新的端口(如5061)来接收。到了真正切换应用服务设备时，就通知参与设备关闭原5060端口并监听5061端口，以便接收来自新的应用服务设备的SIP信息。

接下来，在步骤310中，灭活原应用服务设备的应用服务功能。相应地，在步骤311中，灭活原媒体服务设备的媒体服务功能。从而使得实际多媒体信号切换至由目标媒体服务设备进行传输。至此，服务设备的切换完成。

在图3中并未示出关于激活目标应用服务设备或目标媒体服务设备的步骤，这是出于简洁的目的。本领域技术人员应当理解，需要在准备切换阶段激活目标服务设备的服务功能。

此外，图3中的步骤306-308属于准备切换阶段的步骤，作为另一种实施例，由步骤308返回至步骤302、303时，如果步骤303的判断结果为否，可以增加一个步骤：先取消在步骤307和308中的同步操作，并取消对目标服务设备的激活(目标服务设备为参与设备的情形下)，然后再回到步骤302继续监控。需要指出的是，当前图3所示由308直接返回至302是为了在QoS参数重新小于阈值下限时有机会终止切换准备流程(步骤306-308)，从而尽可能地节省资源消耗。本领域技术人员也完全可以由308直接进行至步骤305，也就是直接判断是否超过阈值上限，而不管是否又低于阈值下限。

需要指出的是，在此情形下QoS水平与QoS参数值呈反比：QoS越差，QoS参数值越高。当然，本领域技术人员也可以设置为两者成正比，那么只需相应地先判断是否小于上限值，再判断是否小于下限值即可。

还需要指出的是，虽然图3所示的方法中为了简洁而将媒体服务设备和应用服务设备统称为“服务设备”，但是本领域技术人员应当理解，媒体服务设备和应用服务设备的切换可以是独立监控、独立进行切换的，也就是说，可能只切换媒体服务设备或目标服务设备中的一个。

还需要指出的是，尽管图3示出了根据实时监控的QoS参数确定切换的时机，但是也完全可以在即使媒体服务设备或应用服务设备的QoS参数尚未超过阈值下限或上限时就执行切换操作，例如：由于多个参与设备中的某个设备突然性能提升(可能由于一项工作任务完成)成为性能最佳的设备，而导致原先选定的媒体服务设备或应用服务设备已经不是参与设备中性能最佳的设备(但仍然符合担任服务设备的要求)，那么为了系统性能最优化的目的，也可以在这种情况下切换至那个性能最佳的设备。

图8示出了以SIP协议为例切换媒体服务设备和应用服务设备的示意图。图8中所示的参与设备C和D即为在图7中分别被选为媒体服务设备和应用服务设备的参与设备。现在，如图8所示，有5个新的参与设备(注有“加入”标识及箭头)加入图7所示的已经建立的不依赖中心服务器的基于SIP协议的IP多媒体会话。由于多个新的参与设备加入会话，不可避免地导致参与设备C和D的工作负载加大、带宽消耗增加，从而造成其QoS参数水平下降。假设参与设备C和D的QoS参数值均超过了预定的阈值范围的上限，则实施切换。而根据对各个参与设备的硬件性能和QoS参数水平的综合评分，发现所有的参与设备均不符合担任应用服务设备或媒体服务设备的要求，从而决定将服务设备切换至中心服务器。切换完成之后如图8所示，虚线示出的为SIP信令流传输，实线示出的为实际多媒体信号流传输。

图4示出了根据本发明一个实施例的用于建立IP多媒体会话的系统的框图。图4所示的系统在总体上由系统400所示，包括请求接收装置401，被配置为接收多个IP多媒体会话参与设备的注册请求；服务设备选择装置402，被配置为在所述参与设备中选择服务设备；以及IP多媒体会话建立装置403，被配置为利用所选择的服务设备在所述多个参与设备间建立IP多媒体会话。本领域技术人员应当理解，系统400中的装置401-403分别对应于图2所示的方法中的步骤201-203，在此不再赘述。

图5示出了根据本发明一实施例的用于基于SIP协议建立IP多媒体会话(初始建立阶段)的信令流程图。如图5所示，有5个参与设备A-E及目录服务器，其中参与设备A是主持者(Moderator)。主持者的作用是在IP多媒体会话建立前主持在参与设备间选择服务设备的过程，即图5中最上面的文本框中描述的内容。主持者的确认有多种方式，例如可以规定在电话会议中最先打入电话的参与设备为主持者，也可以规定只有台式计算机设备才能担任主持者等。目录服务器的作用是在建立IP多媒体会话前接收参与设备的注册请求，并在IP多媒体会话的建立初始阶段主持选择服务设备的过程。因此，图5中示出的目录服务器及主持者实际上两者有其一即可，不需要同时存在。在选定了设备D为应用服务设备，设备E为媒体服务设备后，开始SIP多媒体会话的建立过程。首先，其它四个参与设备A、B、C、E按照SIP协议规范分别向执行应用服务器的功能的参与设备D发出注册请求，即SIP:REGISTER，设备D接受它们的请求，因此分别返回SIP:OK的信令。需要指出的是，按照SIP协议的规范，如果其它设备不知道哪个设备是应用服务设备，则应用服务设备D可以主动地向其它参与设备发出SIP:INVITE的注册邀请，然后由其它参与设备向设备D返回SIP:OK的信令。还需要指出的是，媒体服务设备E也需要向应用服务设备D进行SIP注册。在四个参与设备均与应用服务设备D注册之后，基于SIP的IP多媒体会话即建立完成，然后在IP多媒体会话运行过程中，如图8所示，所有的参与设备均与设备D进行交互以传输SIP信令流，所有的参与设备均与设备E进行交互以传输媒体控制信息(基于实时传送控制协议RTCP)及实际多媒体信号(基于实时传送协议RTP)。

图6示出了根据本发明一实施例的用于建立IP多媒体会话(切换阶段)的信令流程图。如图6所示，由于新的参与设备加入IP多媒体会话，导致设备D和E的QoS水平下降，不再满足担任应用服务设备和媒体服务设备的要求，因此启动切换准备程序(Standby)，将SIP控制状态和信息同步至中心应用服务器(目标应用服务器)，将媒体控制状态和信息同步至中心媒体服务器(目标媒体服务器)。然后一旦需要真正切换(超过上限阈值)，则设备D通知其它原有的参与设备以及新加入的参与设备(Notify Transferring)，然后依次转移SIP控制权限至中心应用服务器，转移媒体控制权限至中心媒体服务器。转移完成后建立依赖于中心服务器的IP多媒体会话。

附图中的流程图和框图，图示了按照本发明各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，所述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

虽然以上结合具体实例，对本发明的利用远程应用处理本地文件的系统及方法进行了详细描述，但本发明并不限于此。本领域普通技术人员能够在说明书教导之下对本发明进行多种变换、替换和修改而不偏离本发明的精神和范围。应该理解，所有这样的变化、替换、修改仍然落入本发明的保护范围之内。本发明的保护范围由所附权利要求来限定。

Claims (20)

1.一种用于建立IP多媒体会话的方法，包括：

接收多个IP多媒体会话参与设备的注册请求；

在所述多个参与设备中选择服务设备；以及

利用所选择的服务设备在所述多个参与设备间建立IP多媒体会话。

2.如权利要求1所述的方法，其中所述服务设备包括下列中的一个或多个：

应用服务设备或媒体服务设备，其中媒体服务设备用于在所述多个参与设备间控制并传输流媒体内容，并且应用服务设备用于在所述多个参与设备间控制信令流。

3.如权利要求2所述的方法，还包括：

激活所述被选为媒体服务设备的参与设备的媒体服务功能；和/或

激活所述被选为应用服务设备的参与设备的应用服务功能，并且

所述参与设备支持用于激活媒体服务功能或应用服务功能的IP多媒体会话协议栈。

4.如权利要求1所述的方法，其中所建立的IP多媒体会话的信令流程控制协议为会话初始协议SIP，流媒体控制协议为实时传送控制协议RTCP，并且流媒体传输协议为实时传送协议RTP。

5.如权利要求2所述的方法，还包括：

监控所选择的媒体服务设备和所述应用服务设备；

根据预定的服务水平QoS参数阈值及监控结果，判断是否需要进行媒体服务设备的切换；

如果判断结果为是，将所述媒体服务设备切换至目标媒体服务设备；

根据预定的服务水平QoS参数阈值，判断是否需要进行应用服务设备的切换；以及

如果判断结果为是，将所述应用服务设备切换至目标应用服务设备。

6.如权利要求5所述的方法，其中目标媒体服务设备选自下列之一：另一参与设备或中心媒体服务器；并且目标应用服务设备选自下列之一：另一参与设备或中心应用服务器。

7.如权利要求5或6所述的方法，其中根据预定的服务水平QoS参数阈值及监控结果，判断是否需要进行媒体服务设备或应用服务设备的切换包括：

设定QoS参数阈值的上限值和下限值；

响应于所述媒体服务设备或应用服务设备的QoS参数超过所述下限值，定位要切换至的目标媒体服务设备或目标应用服务设备；

将媒体控制信息或信令控制信息同步至所述目标媒体服务设备或目标应用服务设备；

响应于所述媒体服务设备或应用服务设备的QoS参数超过所述上限值，确定需要进行媒体服务设备或应用服务设备的切换。

8.如权利要求5所述的方法，其中切换所述应用服务设备包括：

通知所述多个参与设备监听新的端口。

9.如权利要求1所述的方法，其中所选择的服务设备为非中心服务器。

10.如权利要求1所述的方法，其中在所述参与设备中选择服务设备包括：

根据所述多个参与设备的硬件性能及QoS参数，选择服务设备。

11.一种用于建立IP多媒体会话的系统，包括：

注册请求接收装置，被配置为接收多个IP多媒体会话参与设备的注册请求；

服务设备选择装置，被配置为在所述多个参与设备中选择服务设备；以及

IP多媒体会话建立装置，被配置为利用所选择的服务设备在所述多个参与设备间建立IP多媒体会话。

12.如权利要求11所述的系统，其中所述服务设备包括下列中的一个或多个：

应用服务设备或媒体服务设备。

13.如权利要求12所述的系统，还包括：

激活装置，被配置为激活所述被选为媒体服务设备的参与设备的媒体服务功能和/或所述被选为应用服务设备的参与设备的应用服务功能，其中媒体服务设备用于在所述多个参与设备间控制并传输流媒体内容，并且应用服务设备用于在所述多个参与设备间控制信令流，并且

所述参与设备支持用于激活媒体服务功能或应用服务功能的IP多媒体会话协议栈。

14.如权利要求11所述的系统，其中所建立的IP多媒体会话的信令流程控制协议为会话初始协议SIP，流媒体控制协议为实时传送控制协议RTCP，并且流媒体传输协议为实时传送协议RTP。

15.如权利要求12所述的系统，还包括：

监控装置，被配置为监控所选择的媒体服务设备和所述应用服务设备；

第一判断装置，被配置为额根据预定的服务水平QoS参数阈值及监控结果，判断是否需要进行媒体服务设备的切换；

媒体服务切换装置，被配置为响应于如果判断结果为是，将所述媒体服务设备切换至目标媒体服务设备；

第二判断装置，被配置为根据预定的服务水平QoS参数阈值，判断是否需要进行应用服务设备的切换；以及

应用服务切换装置，被配置为响应于如果判断结果为是，将所述应用服务设备切换至目标应用服务设备。

16.如权利要求15所述的系统，其中目标媒体服务设备选自下列之一：另一参与设备或中心媒体服务器；并且目标应用服务设备选自下列之一：另一参与设备或中心应用服务器。

17.如权利要求15或16所述的系统，其中第一判断装置及第二判断装置被配置为：

设定QoS参数阈值的上限值和下限值；

响应于所述媒体服务设备或应用服务设备的QoS参数超过所述下限值，定位要切换至的目标媒体服务设备或目标应用服务设备；

将媒体控制信息或信令控制信息同步至所述目标媒体服务设备或目标应用服务设备；

响应于所述媒体服务设备或应用服务设备的QoS参数超过所述上限值，确定需要进行媒体服务设备或应用服务设备的切换。

18.如权利要求15所述的系统，其中媒体服务切换装置或应用服务切换装置被进一步配置为：

通知所述多个参与设备监听新的端口。

19.如权利要求11所述的系统，其中服务设备选择装置所选择的服务设备非中心服务器。

20.如权利要求11所述的系统，其中服务设备选择装置被进一步配置为：

根据所述多个参与设备的硬件性能及QoS参数，选择服务设备。

Images