CN101369906A

CN101369906A - 一种会议业务实现方法及设备

Info

Publication number: CN101369906A
Application number: CNA2007101405700A
Authority: CN
Inventors: 王鹏
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2007-08-13
Filing date: 2007-08-13
Publication date: 2009-02-18
Anticipated expiration: 2027-08-13
Also published as: CN101369906B

Abstract

本发明公开了一种会议业务实现方法，包括以下步骤：会议服务功能接收来自会议发起者的建立会议请求，所述请求中包括已建立的会话初始协议SIP会话的与会标识参数；所述会议服务功能根据所述与会标识参数通知与会者加入会议。本发明还公开了一种会议发起设备和会议服务功能。本发明的实施例中，可以体现召集与会者入会的业务请求与当前业务之间关系。

Description

一种会议业务实现方法及设备

技术领域

本发明涉及通信技术领域，尤其涉及一种会议业务实现方法及设备。

背景技术

目前，随着分组技术的不断成熟，基于电路交换的传统电信网络正在向着基于分组交换的宽带电信网发展，而使用SIP(Session Initiation Protocol，会话发起协议)作为分组电信核心网的呼叫控制信令则是当前的技术发展趋势之一，如ITU-T(International Telecommunication Union-TelecommunicationStandardization Sector，国际电信联盟-电信标准部)和ETSI(EuropeanTelecommunications Standards Institute，欧洲电信标准协会)等标准组织对NGN(Next Generation Network，下一代网络)的研究，在这种新的分组电信网络中，新的分组终端(如SIP终端)将逐步取代传统的终端话机。

会议业务为由多个用户组成的，每个用户同时与多个其他与会方进行即时语音、视频以及数据等多种形式通信的一种通信业务。该业务为多个用户同时进行交流提供了有效的通信平台，是目前应用最为广泛的业务之一，特别是在企业内部用户之间。

会议业务本身有多种形式，如预订会议和即时会议。其中，预定会议中，用户可以通过会议服务系统提供的方法或者界面提前预订会议的开始以及结束时间、与会方、会议类型(例如：单纯的语音会议、视频会议、数据会议及多种类型会议的复合等)。在预订的会议时间段内会议服务系统可以主动将与会方召集入会，也可以被动地等待与会方加入会议，或者也可以是由某一会议召集者通过会议服务系统提供的方式召集与会方加入会议，如登录会议服务系统，使用会议服务系统提供的界面将用户呼叫入会。

即时会议特别适用于突发性的会议，如用户在突发事件发生时无需预约会议资源，而是在和与会方建立呼叫后立即将一对一的普通呼叫切换为会议业务模式。在完成切换后所有用户立即可以享受与所有通信方进行通信的目的。如常见的三方通信业务中，一个用户在与其他两个用户分别建立会话后，将呼叫切换为三方通信模式(会议业务的一种特殊形式)，此时三个用户可以同时与其他用户进行通信。因此，即时会议的最大特点是用户会话开始时就已经与会议的某一方处于通信状态。

参考图1，为一个会议业务系统，包括会议服务功能、会议发起者和至少一个会议参与者。以下以包括两个会议参与者为例进行说明，但所有的方法同样适用于有多个会议参与者。

现有技术中用于创建会议业务的流程如图2所示，包括以下步骤：

步骤s201，会议发起者UEA如果需要将UEB(sip:userb@example.com)以及UEC(sip:userc@example.com)加入会议，那么UEA需要向会议服务功能发送携带Conference URI(Uniform Resource Identifier，统一资源标识)List(会议统一资源标识列表)的INVITE消息，其消息格式如下：

INVITE sip:conf@example.com SIP/2.0

From:sip:usera@example.com

Content-Type:application/resource-lists+xml

Content-Disposition:recipient-list

Content-Length:...(注：此处略去了对会议业务没有影响的部分头域和消息体，如SDP等)

<？xml version＝＂1.0＂encoding＝＂UTF-8＂？>

<resource-lists xmlns＝＂urn:ietf:params:xml:ns:resource-lists＂

xmlns:cp＝＂urn:ietf:params:xml:ns:copyControl＂>

<list>

</list>

</resource-lists>

其中通过resource-List+xml消息体携带需要加入会议的用户的URI，消息中通过输入uri＝“sip:userb@example.com”和uri＝“sip:userc@example.com”命令表示需要将那些用户召集入会。

步骤s202，会议服务功能收到上述INVITE消息后，如果还没有创建会议则在本地创建会议(即申请或分配会议资源)，将UEA加入会议，否则直接将UEA加入已经创建的会议。

步骤s203，会议服务功能向UEA返回对INVITE请求的200 OK成功响应消息。

步骤s204，UEA收到该响应消息后，需要向会议服务功能返回ACK确认消息。上述INVITE-200 OK-ACK消息过程中不但完成了会议的创建，同时在UEA和会议服务功能之间完成了一次媒体协商，在UEA和会议资源之间建立了用于进行会议资源和UEA之间的媒体流传递的通道。

步骤s205，会议服务功能向UEB发起会话请求INVITE B，请求将UEB加入会议。

步骤s206，UEB收到加入会议的会话请求消息后，需要提示用户有新的呼叫呼入，并根据用户的选择确定是否接受该会话请求。如果用户确认接受该会话请求，那么UEB向会议服务功能返回对INVITE消息的200 OK成功响应消息。

步骤s207，会议服务功能收到200 OK响应消息后需要向UEB返回ACK确认消息。

步骤s208，会议服务功能向UEC发起会话请求INVITE C，请求将UEC加入会议。

步骤s209，UEC收到加入会议的会话请求消息后，需要提示用户有新的呼叫呼入，并根据用户的选择确定是否接受该会话请求。如果用户确认接受该会话请求，那么UEC向会议服务功能返回对INVITE消息的200 OK成功响应消息。

步骤s210，会议服务功能收到200 OK响应消息后需要向UEC返回ACK确认消息。

在步骤s205到步骤s207以及步骤s208到步骤s210的过程中，INVITE-200OK-ACK不但分别完成了将UEB、UEC邀请加入会议，同时在会议服务功能和UEB、UEC之间分别完成了一次媒体协商，在会议服务功能和UEB、UEC之间分别建立了一个用于媒体流传递的媒体通道。

步骤s211，UEA、UEB和UEC被加入该会议业务。

然而，现有技术存在如下问题：

现有技术中无法体现召集与会者入会的业请求与当前业务之间关系。例如，在接收到上述INVITE请求时如果UEB正在进行会话/通话，可能会直接拒绝INVITE请求，而导致邀请UEB入会失败。特别是在UEA向会议服务功能发起会议请求之前如果UEA与UEB之间已经建立呼叫，那么UEB已经处于会话状态，此时如果会议服务功能向UEB发起INVITE请求，UEB无法得知该INVITE请求与已经建立的与UEA会话之间的关系，因此UEB可能会拒绝新的INVITE请求，也有可能会接受新的INVITE请求同时保留与UEA之间的会话。因此，无论采取哪种处理方式显然都不是用户所希望的，特别是在实现即时会议时与会方在会议开始之前总是与会议发起者处于会话状态。

发明内容

本发明实施例提供一种会议业务实现方法及设备，可以体现召集与会者入会的业请求与当前业务之间关系。

本发明实施例提供了一种会议业务实现方法，包括以下步骤：

会议服务功能接收来自会议发起者的建立会议请求，所述建立会议请求中包括已建立的会话初始协议SIP会话的与会标识参数；

所述会议服务功能根据所述与会标识参数构建召集入会请求，通知与会者加入会议。

如上所述的会议业务实现方法，所述与会标识参数包括远端目标，所述会议服务功能将所述远端目标作为召集入会请求的请求统一资源标识Request-URI。

如上所述会议业务实现方法，所述与会标识参数包括SIP会话标识，用于所述远端目标通过匹配到一个已存在的会话加入会议。

如上所述会议业务实现方法，所述会议服务功能将所述SIP会话标识作为召集入会请求Replaces头域、Join头域或者Dialog-ID参数，供所述与会者使用新会话替换已存在会话。

本发明实施例还提供了一种会议服务功能实体，包括：

接收单元，用于接收来自会话发起终端的建立会议请求，所述请求中包括与会标识参数；

会议加入单元，与所述接收单元连接，用于根据所述与会标识参数通知与会者加入会议。

本发明实施例还提供了一种会议发起终端，包括：

建立会议请求生成单元，用于根据已存在会话参数生成建立会议请求，所述请求中包括远端目标；

建立会议请求发送单元，与所述建立会议请求生成单元连接，用于使会议服务功能通知所述远端目标加入会议。

本发明的实施例中，当会议发起者与与会者之间已建立会话，且需要建立会议业务时，通过在会议发起者的建立会议请求中携带已建立的会话初始协议SIP会话的与会标识参数，使会议服务功能获知会议发起者的业请求与当前业务(即会议发起者与与会者之间已建立的会话)之间关系。同时，会议服务功能通过召集入会请求中的请求统一资源标识指示目标实体，并通过会话标识通知与会者用新会话替换原会话，保证了业务的连续性。

附图说明

图1是现有技术中一种会议业务系统结构图；

图2是现有技术中一种创建会议业务的流程图；

图3是本发明实施例一中加入会议业务流程图；

图4是本发明实施例二中加入会议业务流程图；

图5是本发明实施例三中存在迂回路径的系统示意图；

图6是本发明实施例四中加入会议业务流程图；

图7是本发明实施例五中加入会议业务流程图；

图8是本发明实施例IMS UE发起会议业务流程图；

图9是本发明实施例中一种会话服务器结构图；

图10是本发明实施例中一种会议发起终端结构图。

具体实施方式

下面结合具体实施例进行详细说明。

本发明实施例是会议发起终端UEA生成INVITE消息时如果UEA和UEB之间已经建立了会话，则UEA和UEB之间存在SIP协议相关的标识，包括:会话标识Dialog(如Dialog-ab)、远端目标的标识Remote-target和路由集Route-set。其中，Dialog-ab包括Call-ID(呼叫标识，如Call-ID-ab)、Remote-tag(远端标签，如Remote-tag-ab)、Local-tag(本端标签，如Local-tag-ab)，Dialog-ab分别从建立会话的SIP协议交互过程中的Call-ID、From以及To头域的Tag参数获取。远端目标的标识Remote-target是一个SIP URI用于标识SIP会话的对端实体，是从建立会话或者可以修改远端目标的SIP协议交互过程中对端发送过来的SIP消息Contact头域中获取的，例如“sip:remote-target-ab@example.com”。路由集Route-set是SIP会话内的消息所需要经过的SIP实体的地址列表，是从建立会话的SIP协议交互过程中的Record-Route头域获取，例如，Route-set中包含两个路由项：sip:proxy-ab1.example.com和sip:proxy-ab2.example.com。

如果UEA和UEB之间已经存在SIP会话，并且UEA需要将正在与自己进行通信的UEB(sip:b@example.com)加入会议，那么UEA需要首先根据正在进行的会话提取出上述信息，并根据上述信息生成用于将UEB加入会议的与会标识参数并作为URI List表项。那么与会标识参数的生成方法为：将Remote-target作为URI，然后在URI的基础上增加Replaces(替换)或者Join(加入)参数或扩展参数Dialog-ID携带的会话标识(Call-ID，To-Tag，From-tag)，以及可选的增加Route参数携带Route-set、以及会议服务功能在呼叫UEB时需要经过的其他一些网络实体的地址，将最终生成的URI作为URI List的表项内容。此外，还可选地增加会话或业务状态保持参数，用于指示是否需要保持当前的会话或业务状态。如果UEA和UEB之间不存在SIP会话，则URI-List的生成方法为：将UEB的URI作为URI List的表项内容。同样可以根据上述方法生成将用户C加入会议的URI List表项。

本发明实施例一中加入会议业务流程如图3所示，包括以下步骤：

假设UEA与UEB、以及UEA与UEC之间分别已经建立了直接的SIP会话。

步骤s401，UEA向会议服务功能发送INVITE消息，该INVITE消息格式如下：

INVITE sip:conf@example.com SIP/2.0

From:sip:usera@example.com

Content-Type:application/resource-lists+xml

Content-Disposition:recipient-list

Content-Length:...(注:此处略去了对会议业务没有影响的部分头域和消息体，如SDP等)

<？xml version＝＂1.0＂encoding＝＂UTF-8＂？>

<resource-lists xmlns＝＂urn:ietf:params:xml:ns:resource-lists＂

xmlns:cp＝＂urn:ietf:params:xml:ns:copyControl＂>

<list>

<entry uri＝＂sip:remote-target-ab@example.com？Replaces＝call-id-ab％3B

to-tag％3Dremote-tag-ab％3Bfrom-tag％3Dlocal-tag-ab％3Bkeepsessionstate

&Route＝sip％3Aproxy-ab1.example.com％3Bsip％3Aproxy-ab2.example.com＂cp:copyControl＝＂to＂/>

<entryuri＝＂sip:remote-target-ac@example.com？Replaces＝call-id-ac％3B

to-tag％3Dremote-tag-ac％3Bfrom-tag％3Dlocal-tag-ac％3Bkeepsessionstate

&Route＝sip％3Aproxy-ac1.example.com％3Bsip％3Aproxy-ac2.example.com＂cp:copyControl＝＂to＂/>

</list>

</resource-lists>

或者:

INVITE sip:conf@example.com SIP/2.0

From:sip:usera@example.com

Content-Type:application/resource-lists+xml

Content-Disposition:recipient-list

<？xml version＝＂1.0＂encoding＝＂UTF-8＂？>

<resource-listsxmlns＝＂urn:ietf:params:xml:ns:resource-lists＂

xmlns:cp＝＂urn:ietf:params:xml:ns:copyControl＂>

<list>

<entry uri＝＂sip:remote-target-ab@example.com？Join＝call-id-ab％3B

to-tag％3Dremote-tag-ab％3Bfrom-tag％3Dlocal-tag-ab％3Bkeepsessionstate

<entry uri＝＂sip:remote-target-ac@example.com？Join＝call-id-ac％3B

to-tag％3Dremote-tag-ac％3Bfrom-tag％3Dlocal-tag-ac％3Bkeepsessionstate

</list>

</resource-lists>

或者:

INVITE sip:conf@example.com SIP/2.0

From:sip:usera@example.com

Content-Type:application/resource-lists+xml

Content-Disposition:recipient-list

<？xml version＝＂1.0＂encoding＝＂UTF-8＂？>

<resource-lists xmlns＝＂urn:ietf:params:xml:ns:resource-lists＂

xmlns:cp＝＂urn:ietf:params:xml:ns:copyControl＂>

<list>

<entry uri＝＂sip:remote-target-ab@example.com？Dialog-ID＝call-id-ab％3B

to-tag％3Dremote-tag-ab％3Bfrom-tag％3Dlocal-tag-ab％3Bkeepsessionstate

<entry uri＝＂sip:remote-target-ac@example.com？Dialog-ID＝call-id-ac％3B

to-tag％3Dremote-tag-ac％3Bfrom-tag％3Dlocal-tag-ac％3Bkeepsessionstate

</list>

</resource-lists>

其中，URI List需要包含呼叫AB/AC中的Remote Target，同时需要通过Replaces参数或者Join参数或者扩展参数Dialog-ID携带Dialog ID以及通过Route参数携带Route-set，通过KeepSessionState标志指示需要保持会话状态。其中KeepSessionState标志作为Replaces参数或者Join参数或扩展参数Dialog-ID的一个子参数，实际应用中可以作为一个独立的参数，如定义一个会话状态的域名空间urn:ietf:params:xml:ns:sessionstate，并定义该域名空间的一个元素sessionstate，sessionstate的取值nochange表示不改变会话状态，具体格式如下：

<？xml version＝＂1.0＂encoding＝＂UTF-8＂？>

<resource-lists xmlns＝＂urn:ietf:params:xml:ns:resource-lists＂

xmlns:cp＝＂urn:ietf:params:xml:ns:copyControl＂

xmlns:ss＝＂urn:ietf:params:xml:ns:sessionstate＂>

<list>

<entry uri＝＂sip:remote-target-ab@example.com？Replace＝call-id-ab％3B

to-tag％3Dremote-tag-ab％3Bfrom-tag％3Dlocal-tag-ab

&Route＝sip％3Aproxy-ab1.example.com％3Bsip％3Aproxy-ab2.example.com＂cp:copyControl＝＂to＂ss:sessionstate＝＂nochange＂/>

<entry uri＝＂sip:remote-target-ac@example.com？Replace＝call-id-ac％3B

to-tag％3Dremote-tag-ac％3Bfrom-tag％3Dlocal-tag-ac％3Bkeepsessionstate

&Route＝sip％3Aproxy-ac1.example.com％3Bsip％3Aproxy-ac2.example.com＂cp:copyControl＝＂to＂ss:sessionstate＝＂nochange＂/>

</list>

</resource-lists>

步骤s402，会议服务功能收到INVITE消息后，需要根据现有技术中会议服务功能的处理方式进行处理，如，申请/分配会议资源、将UEA加入会议等。

步骤s403，会议服务功能向UEA返回200 OK响应消息。

步骤s404，UEA收到该响应消息后向会议服务功能返回ACK确认消息。该INVITE-200 OK-ACK消息过程中不但完成了会议的创建，还同时在UEA和会议服务功能之间完成了一次媒体协商，在UEA和会议资源之间建立了用于进行会议资源和UEA之间的媒体流传递的媒体通道。

步骤s409，会议服务功能请求将UEB加入会议，具体为：会议服务功能需要根据URI-List表项将与会者召集入会，即向URI List中表项所对应的UEB发送INVITE请求，请求将UEB加入会议。其中如果URI List中通过Replaces参数携带会话标识，INVITE请求通过Replaces头域携带会话标识；如果URI List中通过Join参数携带会话标识，INVITE请求通过Join头域携带会话标识；如果URIList中通过Dialog-ID参数携带会话标识，会议服务功能根据业务需要在INVITE请求中通过Replaces或者Join头域携带会话标识，如果需要保留已经建立的会话则INVITE请求通过Join头域携带会话标识，如果不需要保留已经建立的会话则INVITE请求通过Replaces头域携带会话标识。

其中，对于携带Replaces头域的INVITE请求，根据目前SIP协议定义UEB可以直接接受该INVITE请求并释放原有的SIP会话。当然UEB也可以定义自己的本地策略，如果是SIP终端那么可以提示用户相关的信息修改，请求用户确认是否接受修改。但是不会向用户显示“有新的呼叫”。因此采用这种方案不会存在新请求被拒绝或新旧会话同时存在的情况。同时对于Replaces头域因为只是完成SIP会话的替换，因此通信双方不会修改业务状态，因此同时可以避免当前会话状态丢失的问题。

其中，对于携带Join头域的INVITE请求，根据目前SIP协议定义，UEB在本地创建会议，接受该INVITE请求并将新建立的呼叫和原有的呼叫加入本地创建的会议中。

根据上述INVITE请求消息中携带的URI List生成分别将UEB和UEC邀请加入会议的INVITE请求消息。其中Remote-target作为新的召集UEB和UEC入会的INVITE请求消息的Request-URI用于指示由Remote-target所标识远端目标对召集入会请求进行处理，因为UEA与UEB以及UEA与UEC/AC之间建立了直接SIP会话，所以Remote-target所标识的远端目标分别为UEB和UEC；Replaces参数或者Join携带的Dialog ID会作为Replaces头域或者Join头域携带在新的INVITE消息中用于指示远端目标匹配到一个已存在的会话并使用召集入会请求替换匹配到的原有会话，Route参数携带的Route-Set参数携带的Route-Set会携带在Route头域中用于所述召集入会请求被路由到达最终目标。此INVITE请求会替换UEB与UEA已经建立的会话，因此可以确保UEB正确接受该INVITE请求并保持原有会话的状态，其消息格式如下：

INVITE sip:remote-target-ab@example.com SIP/2.0

Replace:call-id-ab；to-tag＝remote-tag-ab；from-tag＝local-tag-ab

Route:sip:proxy-ab1.example.com，sip:proxy-ab2.example.com

From:sip:conf@example.com

<略去了对会议业务没有影响的部分头域和消息体，如SDP等>

步骤s410，UEB收到加入会议的会话请求消息后，向会议服务功能返回对INVITE的200 OK成功响应消息。

步骤s411，会议服务功能收到200 OK响应消息后，向UEB返回ACK确认消息。在这个过程中INVITE-200 OK-ACK不但完成了将UEB邀请加入会议，同时在会议服务功能和UEB之间分别完成了一次媒体协商，在会议服务功能和UEB之间分别建立了一个用于媒体流传递的媒体通道。

步骤s412，UEB收到上述带有Replaces头域的INVITE请求后会根据Replaces头域定位到与UEA建立的一个SIP会话。因为该INVITE请求是对已经存在的SIP会话的替换，因此不会提示用户有新的呼叫呼入，根据本地策略进行处理后返回对该INVITE请求的200 OK响应消息，并且会向UEA发送BYE请求释放被替换的SIP会话。由于根据上述INVITE请求构造的到UEB的INVITE请求携带Replaces头域，而且Replaces头域中会携带UEB与UEA之间所建立的SIP会话的标识。因此UEB需要根据Replaces头域中携带的Dialog ID信息在本地定位到一个已经存在的SIP Dialog。在向会议服务功能返回200OK后需要向会议发起者发送BYE请求，释放被替换的SIP Dialog。同样因为该请求中携带Replaces头域指示是对已经存在的一个SIP会话的替换，因此收到该请求消息后UEB应当接受该请求并保持当前会话的状态，如当前会话的媒体流的数目、每条媒体流的方向、或者还包括所使用的编解码格式等保持不变。

UEB收到上述带有Join头域的INVITE请求后会根据Join头域定位到与UEA建立的一个SIP会话，在本地创建会议，接受INVITE请求并将新建立的SIP会话以及根据Join头域定位到SIP会话对应的SIP会话加入新创建的会议中。因为使用Join头域指示请求加入已经存在的会话，因此UEB不会释放原有会话，因此不需要执行步骤s413。

步骤s413，会议发起者UEA收到BYE请求后向UEB返回200OK确认SIP会话被释放。

步骤s414，同理，将UEC加入会议。

步骤s415，最终UEA、UEB、UEC被加入会议。

本发明实施例中URI List携带的不是UEB、UEC的标识，不直接向UEB、UEC发送INVITE请求，而是向与UEA建立SIP会话的Remote-Target发送INVITE请求，该远端目标可以是中间实体，也可以是用户终端。如果在UEA与UEB以及UEA与UEC之间不存在中间实体时，Remote Target就是UEB、UEC，因此实际上可能还是向UEB、UEC发送INVITE请求，但这种情况可以看作是一种特殊情况。

使用携带Replaces头域的INVITE请求建立新的会话并释放原有会话(替换)隐含的表示需要保持现有会话。这种方式并不能完全保证当前会话的状态能够得到保持。为了进一步保证当前会话状态能够被保持，本发明实施例二在实施例一的基础上采取了一种改进方法。在步骤S401会议服务功能接收到INVITE请求后，会议服务功能向UEB发送INVITE请求，其中通过一个现有参数或者扩展参数表示需要保持当前会话状态，具体消息格式如下所示：即为通过一个Replaces头域参数“keepsessionstate”指示需要保持当前会话参数，当然也可以通过一个单独的头域或者其他参数携带方式进行这种指示。

INVITE sip:remote-target-ab@example.com SIP/2.0

Replace:call-id-ab；to-tag＝remote-tag-ab；

from-tag＝local-tag-ab；keepsessionstate

Route:sip:proxy-ab1.example.com，sip:proxy-ab2.example.com

From:sip:conf@example.com

<略去了对会议业务没有影响的部分头域和消息体，如SDP等>

为了进一步保证当前会话状态能够被保持，本发明实施例二在实施例一的基础上采取了另一种改进方法。会议服务功能首先向UEB查询当前会话或者业务信息，然后在获取到当前业务信息后构造一个确保当前会话状态不会被修改的INVITE请求，以保证当前会话状态的保持(如调整会议资源媒体资源状态使发送的INVITE请求消息中携带的媒体流状态和查询得到的当前会话状态中的媒体流状态保持一致)。具体查询方法如图4所示，其中除了以下几步外，其他步骤与图3中步骤相同：

步骤s405，会议服务功能向UEB发送SUBSCRIBE请求，其中Event头域指示为订阅会话或业务(例如设置为session-state)，表示需要获取UEB上已经存在的会话或业务的状态。会议服务功能将URI List中获取得到的RemoteTarget作为SUBSCRIBE的Request URI，这样可以确保请求消息被发送到UEB。进一步，会议服务功能可以在SUBSCRIBE消息中携带从URI List中获取得到的Dialog ID，这样UEB就可以直接返回Dialog ID所对应的会话或者业务的会话/业务状态。进一步，如果URI List中相应的表项中包含有Route Set，那么会议服务功能可以将Route Set中部分或者全部SIP-URI作为SUBSCRIBE请求的Route头域，当然还可以根据本地策略加入其他一些Route地址。一个实际的SUBSCRIBE消息举例如下，

SUBSCRIBE sip:remote-target-ab@example.com SIP/2.0

Event:session-state；dialog-id＝call-id-ab％3B

to-tag％3Dremote-tag-ab％3Bfrom-tag％3Dlocal-tag-ab

Route:sip:proxy-ab1.example.com，sip:proxy-ab2.example.com

From:sip:conf@example.com

其中将Dialog ID作为Event头域的一个参数，实际上可以采用包括消息体、单独的一个消息头域等方式携带。

步骤s406，UEB接收到发送消息后返回200 OK响应。

步骤s407，UEB向会议服务功能返回NOTIFY消息，其中携带有会话/业务状态信息。

如果步骤s405中带有Dialog ID参数，那么UEB根据Dialog ID定位本地一个已经存在的SIP会话，然后将定位到的SIP会话所对应的会话/业务状态返回给订阅者(会议服务功能)。

为一个实际的NOTIFY消息格式如下：

NOTIFY sip:conf@example.com SIP/2.0

Event:session-state；state＝terminated

Route:sip:proxy-ab1.example.com，sip:proxy-ab2.example.com

Content-type:application/session-state+xml

<略去了对会议业务没有影响的部分头域和消息体，如SDP等>

<？xml version＝＂1.0＂？>

<session-state-infoxmlns＝＂urn:ietf:params:xml:ns:session-state-info＂

version＝＂4＂state＝＂full＂entity＝＂sip:remote-target-ab@example.com＂>

<session-infocall-id＝＂call-id-ab＂local-tag＝＂remote-tag-a＂

remote-tag＝＂local-tag-ab＂direction＝＂initiator＂>

<local-media-description description＝”SDP-fragment”>

m＝audio 40000 RTP/AVP 0

c＝IN IP4 ueb.example.com

a＝rtpmap:0PCMU/80000

a＝sendonly

</local-media-description>

<remote-media-description description＝”SDP-fragment”>

m＝audio 40000 RTP/AVP 0

c＝IN IP4 uea.example.com

a＝rtpmap:0 PCMU/80000

a＝sendonly

</remote-media-description>

</session-info>

</session-state-info>

本实例中通过携带application/session-state+xml消息体以及在该消息体中携带本端以及对端的媒体信息。

步骤s408，会议服务功能返回对步骤s407的200 OK响应。

接收到步骤s407后，会议服务功能可以调整会议资源使发送的步骤s409和NOTIFY消息中所携带的remote-media-description中所对应的媒体流数目以及各个媒体流的媒体方向保持一致，进一步还可以保持个媒体流的编解码方式、PT(Payload Type，净荷类型)值等信息保持一致。

收到由这种方法所产生的步骤s409消息后UEB因为新的INVITE中所携带的SDP(Session Description Protocol，会话描述协议)描述和被替换的会话中对端的媒体描述出了连接地址、端口等之外其他信息完全一致，因此在返回200OK时甚至不需要做任何特殊处理就可以继续保持当前会话的状态。

本发明实施例三中，当UEA和会议服务功能以及UEA和UEB之间存在相同的路由集时，根据上述方法将会造成SIP信令上的迂回，如图5所示，路径1代表UEA与UEB之间建立的会话所经过的Proxy；路径3代表会议服务功能经过P1、P2到达UEB；路径2代表UEA与会议服务功能之间所经过的Proxy；路径4代表优化后的会议服务功能与UEB之间所经过的Proxy。

为了减少会议服务功能与UEB之间的SIP消息路由迂回，会议服务功能需要根据接收到的URI List的Route参数中所携带的Route Set，在去除UEA与会议服务功能之间的SIP会话的Route Set之后再作为发送到UEB的INVITE以及SUBSCRIBE消息的Route头域。这样会议服务功能到UEB之间的信令路由就可以直接通过P2抵达UEB而避免了信令迂回。优化后的INVITE消息如下：

INVITE sip:remote-target-ab@example.com SIP/2.0

Replace:call-id-ab；to-tag＝remote-tag-ab；from-tag＝local-tag-ab

Route:sip:proxy-ab2.example.com

From:sip:conf@example.com

<略去了对会议业务没有影响的部分头域和消息体，如SDP等>

优化后的SUBSCRIBE消息如下所示：

SUBSCRIBE sip:remote-target-ab@example.com SIP/2.0

Event:session-state；dialog-id＝call-id-ab％3B

to-tag％3Dremote-tag-ab％3Bfrom-tag％3Dlocal-tag-ab

Route:sip:proxy-ab2.example.com

From:sip:conf@example.com

<略去了对会议业务没有影响的部分头域和消息体，如SDP等>

其中，P1、P2分别为sip:proxy-ab1.example.com和sip:proxy-ab2.example.com。

除了以上策略处理之外，会议服务功能可以按照其他的策略构造请求将UEB加入会议的请求消息。此处会议服务功能可以根据本地策略生成INVITE请求的部分参数。

本发明实施例四中，如果已经存在一个AS等实体作为B2BUA(Back-To-Back UserAgent，背靠背用户代理)在呼叫UEA和UEB的路径上，如图6所示，假设离UEA最近的一个这种类型的实体为IEA(Intermediary EntityA，中间实体A)，那么在UEA和IEA之间会存在一个SIP会话Dialog1，同时在IEA和UEB存在一个或多个SIP会话。

其中Dialog1中Remote-Target将为IEA的一个URI(如sip:iea.example.com)。那么，UEA发送到会议服务功能的与UEB相关的URI List表项如下：

<entry uri＝＂sip:iea.example.com？Replace＝call-id-a-iea

％3Bto-tag％3Dremote-tag-a-iea％3Bfrom-tag％3Dlocal-tag-a-iea

&Route＝sip％3Aproxy-a-ieal.example.com％3Bsip％3Aproxy-a-iea2.example.com＂

其中：会话标识(Dialog ID)中Call-ID、Local-Target、Remote-Target分别为call-ID-a-iea、local-tag-a-iea、remote-tag-a-iea。Route-Set为sip:proxy-a-ieal.example.com、sip:proxy-a-iea2.example.com。

会议服务功能发送的INVITE消息格式为：

INVITE sip:iea.example.com SIP/2.0

Replace:call-id-a-iea；to-tag＝remote-tag-a-iea；from-tag＝local-tag-a-iea

Route:sip:proxy-a-ieal.example.com，sip:proxy-a-iea2.example.com

From:sip:conf@example.com

<略去了对会议业务没有影响的部分头域和消息体，如SDP等>

中间实体A收到上述消息后，因为上述消息的Request-URI是指向IEA实体，并且消息携带的Replaces头域或者Join头域携带的Dialog ID可以匹配到IEA上已经实际存在的SIP Dialog。因此中间实体A需要接受新的INVITE请求。进一步如果是消息携带的Replaces头域携带的Dialog ID匹配到IEA上已经实际存在的SIP Dialog，那么原来的SIP Dialog被INVITE新创建的Dialog所替换，因此中间实体A需要释放原SIP Dialog。

另外，中间实体A在对INVITE请求处理时可能需要向UEB发起媒体修改过程，也可能需要进行其他一些必要的处理操作。这些处理与中间实体A本身的业务逻辑等相关。其中，IEA没有任何额外的技术需求，仅仅要求IEA以及UEB等实体按照SIP协议已有相关技术进行处理即可。从上述消息可以看出，该INVITE请求消息将会被发送到IEA并且会被IEA终结，Dialog1会被新的INVITE产生的Dialog替换。

从上述的处理过程可以看出因为会议服务功能向UEA看到的最近的一个Dialog端点发起INVITE请求并且只是替换UEA和最近的一个Dialog端点之间的会话，因此不会影响该实体与远端用户(UEB、UEC)之间的网络实体对业已存在的呼叫的处理。并且由会议服务功能发起和创建的新的SIP会话会经过UEA与上述Dialog端点实体之间A的Proxy等网络实体，因此这些网络实体也会获得新的SIP会话是对原有会话的替换，因此可以继续使用任何已经应用的业务逻辑对新的Dialog以及SIP会话进行控制，因此使用本发明保持了对正在执行的业务没有影响。

本发明实施例六中，当IEA为会议服务功能时，Dialog1本身将会存在于UEA和会议服务功能之间。因此上述会议服务功能发送INVITE到IEA的过程将变成了会议服务功能内部的处理过程，或者会议服务功能也可以向自己发送如上所述的方法进行处理(相当于上面的一个实施例中会议服务功能与中间实体A在物理上变成了一个实体)，如图7所示：

1、会议服务功能接收到带有URI List的INVITE请求时，申请/分配会议资源、将UEA加入会议，并向UEA返回200 OK响应消息，UEA收到该响应请求后会向会议服务功能返回ACK确认消息。该INVITE-200 OK-ACK消息过程中不但完成了会议的创建，还同时在UEA和会议服务功能之间完成了一次媒体协商，在UEA和会议资源之间建立了用于进行会议资源和UEA之间的媒体流传递的媒体通道。

2、会议服务功能需要根据每个URI-List表项分别将所有与会者召集入会，如果URI List的Remote Target指向自己，那么可以按照图6所示方式进行处理(中间实体A将与会议服务功能为同一实体)，或者会议服务功能直接根据Replaces参数在本地匹配一个已经存在的SIP会话，然后向会议发起者发送BYE请求释放被替换的SIP会话，或者会议服务功能直接根据Join参数在本地匹配一个已经存在的SIP会话，然后将匹配到的SIP会话所对应的SIP会话加入会议，或者会议服务功能直接根据Dialog-ID参数在本地匹配一个已经存在的SIP会话，然后将匹配到的SIP会话所对应的SIP会话加入会议，然后可选地向会议发起者发送BYE请求释放被匹配到的SIP会话。

3、会议服务功能在对INVITE请求处理时可能需要向UEB发起媒体修改过程，也可能需要进行其他一些必要的处理操作，这些处理与会议服务功能本身的实现相关。

本发明实施例七为在IMS网络中的应用。其中，IMS(IP多媒体子系统)是一种可实现分组话音和分组数据，及提供统一的多媒体业务和应用的网络。IMS具体为采用IP分组域作为其控制信令和媒体传输的承载通道，其中，控制信令为基于SIP的呼叫控制信令。

在IMS中，主要包括以下功能实体：MRF(Media Resource Function，媒体资源功能)，用于支持与承载(媒体)相关的媒体资源服务，例如会议、对用户公告或者进行承载编解码转换等功能；MRF进一步可以分为MRFC(Media Resource Function Control，媒体资源控制功能)和MRFP(MediaResource Function Control Process，媒体资源处理功能)，MRFC负责解释从S-CSCF(服务呼叫会话控制功能)收到的SIP信令并控制MRFP提供相应的媒体资源服务功能。MGCF(媒体网关控制功能)是IMS用户和电路交换CS用户之间可以进行通信的网关。所有来自或者到CS用户的呼叫控制信令都会经过MGCF。P-CSCF(代理呼叫会话控制功能)是IMS系统中用户的第一个接触点，所有SIP信令流，无论来自UE或者发给UE都必须经过P-CSCF。AS(应用服务器)负责业务的提供，如会议业务等。S-CSCF为UE进行会话控制和注册服务。

其中，AS和S-CSCF在网络结构上完全分离，IMS业务需要通过S-CSCF触发至AS进行处理，且多个AS之间可以协同工作以提供相应业务。在IMS网络中，会议发起者可以为IMS UE、AS、MGCF或者其他发起会议业务的功能实体，会议服务功能则为提供会议功能的应用服务器AS。

当由IMS UE发起会议业务时，会议业务由用户签约的会议业务的AS或者公共的会议业务AS提供会议业务器。在这个业务过程中IMS UE充当会议发起者的角色，需要按照本发明的会议发起者的行为进行处理，同时提供会议业务功能的会议业务AS充当会议服务功能的角色，需要按照本发明的会议服务功能的行为进行处理。

另外，根据现有IMS网络业务触发规则，如果用户签约了会议业务，那么用户发起的或者到用户的会议业务都会经过为该用户提供会议业务的AS。因此在IMS网络中将使用图6和图7所对应的业务实现方案，如图8所示，在发起会议业务之前UEA与UEB以及UEC之间已经建立了SIP会话。

某一AS或者中间实体AS1作为B2BUA位于A与B的呼叫路径中，在UEA和AS1之间不存在其他AS等作为B2BUA的中间实体，AS1不是为UEA提供会议功能的会议服务AS。所以在UEA和会议服务AS之间存在会话b1以及在AS1和用户B之间存在一个或者多个SIP会话。P-CSCF和S-CSCF分别作为SIP代理服务器位于b1的路径上，同时UEA并未与UEC建立呼叫。

会议服务AS作为B2BUA位于呼叫路径A与C的呼叫路径中，并且在UEA和会议服务AS之间不存在其他AS等作为B2BUA的中间实体，所以在UEA和会议服务AS之间存在会话c1以及在会议服务AS和UEC之间存在一个或者多个SIP会话。P-CSCF和S-CSCF分别作为SIP代理服务器位于c1的路径上，UEA并未与UEC建立呼叫。

用户A与D之间在UEA发起会议业务之前没有建立呼叫。

UEA发起会议业务将用户A、B、C、D加入会议的业务流程如图8所示：

步骤S1801，UEA发起会议业务，经过P-CSCF以及S-CSCF路由到达会议服务AS，希望将UEB、UEC以及UED加入会议中，这时UEA向AS发起包含会议URI List的会议建立请求，其中URI List中包含如下三个表项：

表项一：会话b1的远端目标remote target、会话标识Dialog ID，可选的包括Route Set以及指示保持业务状态的标志，其中会话b1的remote-target指向AS1；

表项二：会话c1的远端目标remote target、会话标识Dialog ID，可选的包括Route Set以及指示保持业务状态的标志，其中会话c1的remote-target指向会议服务AS；

表项三：用户D的用户标识，其中不包含Replaces、Join以及Dialog-ID等参数。

步骤S1802，AS与MRF进行交互，如果还没有创建会议则在本地创建会议(即申请或分配会议资源)，将UEA加入会议，否则直接将UEA加入已经创建的会议

步骤S1803，AS向UEA返回200 OK响应消息。

步骤S1804，UEA向AS返回ACK确认消息。

AS将UEB加入会议中，因为URI List的表项一中带有Dialog信息，并且remote target指向AS1，因此，会议服务AS向AS1查询A与B之间的会话状态。

步骤S1805，AS向AS1订阅会话状态，其中指定或不指定获取Dialog b1的会话状态。

步骤S1806，AS1向AS返回响应消息。

步骤S1807，AS1向会议服务AS发送会话状态信息NOTIFY，如果步骤S1805中指定了获取Dialog b1的会话状态，那么仅发送Dialog b1的会话状态。如果步骤S1805中没有指定SIP会话信息，那么AS1向会议服务AS发送包括Dialog b1以及其他可能的Dialog的会话状态，AS需要从中找出所需要的SIP会话的会话状态。

步骤S1808，AS向AS1返回响应消息。

步骤S1809，AS向AS1发起会话请求，其中通过Replaces头域或者Join头域携带从表项一中获取到的Dialog b1的会话标识Dialog ID，通过Route头域携带从表项一中获取到的Route Set。

其中，INVITE请求中携带Replaces头域标识被替换的SIP会话，替换原有会话隐含的表示需要保持现有业务状态，或者INVITE请求中携带Join头域标识请求加入的SIP会话，不会影响现有业务状态。因此步骤S1805～步骤S1808为可选步骤。

如果在步骤S1809之前执行了步骤S1805～步骤S1808，那么AS需要与MRF进行交互(如指定MRF的媒体流的编解码方式、媒体流的方向等)使得使步骤S1809中的媒体描述和b1会话中AS1的的当前会话描述信息处理连接地址、端口之外的其他信息保持一致(包括媒体流的数目、编解码方式，各媒体流的方向、每个编解码的净荷类型等)。这样将确保会话状态不会被改变。

如果在步骤S1809之前未执行步骤S1805～步骤S1808，那么可选地AS在S1809 INVITE消息中指示AS1需要保持当前会话状态。

步骤S1810，AS1收到步骤S1809消息后需要在本地匹配一个已经存在的SIP Dialog(Dialog b1)。然后，如果INVITE请求中带有“保持当前会话状态”指示，那么AS1需要保持当前会话状态。如对于每一个已经建立的媒体流需要保持当前媒体流的方向。如果INVITE请求中不带“保持当前会话状态”指示，那么AS1保持或者不保持当前会话状态。如对于每一个已经建立的媒体流需要保持当前媒体流的方向。因为INVITE请求是对现有SIP会话的替换，因此AS1应当保持当前会话状态，并且AS1向会议服务AS返回200 OK响应消息。

步骤S1811，AS向AS1返回ACK确认消息。

步骤S1812，如果INVITE请求中携带Replaces头域标识被替换的SIP会话，那么AS1向UEA发起释放Dialog b1的BYE请求。

步骤S1813，UEA收到上述BYE请求后向AS1返回对上述BYE请求的响应消息。

步骤S1814，如果步骤S1810造成需要向用户B等实体进行媒体修改，那么AS1向对端发送UPDATE请求进行媒体修改。

步骤S1815，AS1收到200 OK响应消息。

会议服务AS将用户C加入会议中。

步骤S1816，因为表项二中携带的URI地址指向自己，因此AS在本地匹配到一个已经存在的SIP会话Dialog c1，AS将用户加入会议。如果因此造成需要向用户B等实体进行媒体修改，那么AS向对端发送UPDATE，请求进行媒体修改。

步骤S1817，会议服务AS接收到对端返回的200 OK响应消息。

步骤S1818，如果INVITE请求中携带Replaces头域标识被替换的SIP会话，会议服务AS向UEA发起释放Dialog c1的BYE请求。

步骤S1819，UEA收到上述BYE请求后向会议服务AS返回对上述BYE请求的响应消息。

会议服务AS将用户D加入会议中，具体方法为；因为URI List的第三个表项为用户C的用户标识，因此会议服务AS向用户C发起一个会话请求。

步骤S1820，AS向用户C发起初始业务建立请求。

步骤S1821，AS收到用户C的请求应答(对步骤S1809的200 OK响应消息)。

步骤S1822，AS向用户C返回ACK确认消息。

至此用户A、B、C、D进入会议。

根据上述业务流程以及本发明相关处理方式说明不难推导出其他可能的由IMS UE发起的会议业务的具体场景下的业务实现流程。

当由CS域用户发起会议业务，且MGCF收到会议业务请求时，会议业务由用户签约的会议业务的AS或者公共的会议业务AS提供会议业务功能。在这种情况下，MGCF、会议服务功能AS以及其他应用服务器分别按照上述UEA、会议服务其AS以及AS1相同的处理方式进行处理。

当由应用服务器(非提供会议业务的应用服务器或者不是为本次会议业务提供会议业务的应用服务器)发起会议业务时该应用服务器、会议服务AS以及其他应用服务器分别按照上述UEA、会议服务其AS以及AS1相同的处理方式进行处理。

本发明实施例中，当UEA发起创建会议之前如果UEB正在处于挂起等状态，在将UEB加入会议后UEB仍然处于挂起状态。由于本发明实施例中UEB获知INVITE请求与已经建立的与UEA会话之间的关系，因此可以保持已经存在的会话的状态。进而在由PSTN网络向基于SIP协议的网络的演进过程中可以保持既有网络所能够提供的业务。

另外，本发明实施例中考虑会议业务和其他业务的关系。对一个已经建立的通话来说，该通话可以已经触发应用若干种业务，处理这些业务的业务控制网元已经位于该通话的信令路径中，新组成的会议应该是在原来通话基础上的延续，原先已经应用的业务应该被保持，不会导致用户原业务体验发生变化。

本发明实施例还提供了一种会话服务器，如图9所示，包括:接收单元10，用于接收来自会话发起终端的建立会议请求，请求中包括与会者的用户标识参数；会议加入单元20，与接收单元10连接，用于根据所述标识参数通知与会者加入会议；路由选择单元30，与会议加入单元20连接，用于会议服务功能与所述会议发起者已经建立会话时，根据所述建立会议请求中携带的路由集与所述与会者通信；路由优化单元40，与路由选择单元30连接，用于将包含在统一资源列表表项中路由集中，且没有包含在会议发起者与会议服务功能之间的路由集中的路由项作为会议服务功能到与会者的路由。本实施例中的路由优化单元40并不是必须的，是可选的，通过该单元可以优化路径，但没有该单元，本发明同样可以实现。

其中，会议加入单元20具体包括：当前会话状态获取子单元21，用于从远端目标获取当前会话状态；会话加入子单元22，与所述当前会话状态获取子单元21连接，用于将所述远端目标加入当前会话。本实施例中的当前会话状态获取子单元21并不是必须的，是可选的，通过该单元可以优化效率，但没有该单元，本发明同样可以实现。

本发明实施例还提供了一种会议发起装置，如图10所示，包括：建立会议请求生成单元100，用于根据已存在会话参数生成建立会议请求，请求中包括远端目标；建立会议请求发送单元200，与建立会议请求生成单元100连接，用于使会话服务器通知远端目标加入会议；当前会话状态获取请求单元300，用于向所述远端目标发送订阅/通知请求，要求获得当前会话状态；当前会话状态接收单元400，用于接收所述远端目标向所述会议发起装置发送的当前会话状态。

本发明实施例中，使用新会话替换了原有会话，避免了新会话不被接受，或新旧会话同时存在的问题。另外，可以保持与会方在被加入会议前后的业务状态一致，并保持现有业务的连续性，进而实现会议业务功能并提高用户业务体验。

例如，原先已经建立的通话，是UEA使用了预付费卡(如200卡)才能建立的的国际长途通话(UEA使用的终端没有国际长途权限)，在该通话的信令路径中存在一个处理预付费业务的业务控制网元，UEA新发起的申请会议的呼叫，也经过该预付费业务控制网元，保持了现有业务的连续性。

又如，在原先已经建立的通话过程中，或在该通话的呼叫发起时，UEA、UEB以及/或者UEC临时激活了某个业务，比如计费通知业务，利用本发明UEA、UEB以及/或者UEC组建会议后，可以保持该计费通知业务。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例的方法。

以上公开的仅为本发明的几个具体实施例，但是，本发明并非局限于此，任何本领域的技术人员能思之的变化都应落入本发明的保护范围。

Claims

1.一种会议业务实现方法，其特征在于，包括以下步骤：

会议服务功能接收来自会议发起者的建立会议请求，所述请求中包括已建立的会话初始协议SIP会话的与会标识参数；

2.如权利要求1所述会议业务实现方法，其特征在于，所述与会标识参数包括远端目标的标识，所述会议服务功能将所述远端目标的标识作为召集入会请求的请求统一资源标识Request-URI。

3.如权利要求2所述会议业务实现方法，其特征在于，所述与会标识参数包括SIP会话标识，用于所述远端目标匹配到一个已存在的会话并使用召集入会请求替换匹配到的原有会话。

4.如权利要求3所述会议业务实现方法，其特征在于，所述会议服务功能将所述SIP会话标识作为召集入会请求Replaces头域、Join头域或者Dialog-ID参数，供所述与会者使用新会话替换已存在会话。

5.如权利要求1所述会议业务实现方法，其特征在于，所述请求中进一步包括路由集，所述会议服务功能根据所述路由集将召集入会请求路由到所述远端目标。

6.如权利要求5所述会议业务实现方法，其特征在于，所述会议服务功能将路由集中部分或者全部路由项作为会话请求的Route头域，供所述召集入会请求被路由到达最终目标。

7.如权利要求6所述会议业务实现方法，其特征在于，所述与会标识参数的路由集中，但未包含在会议发起者与会议服务功能之间的SIP会话路由集中的路由项作为召集入会请求的路由。

8.如权利要求1所述会议业务实现方法，其特征在于，所述建立会议请求中进一步包括保持当前会话状态的标志，

所述会议服务功能通知所述远端目标保持当前会话状态。

9.如权利要求2所述会议业务实现方法，其特征在于，所述召集入会请求请求中进一步包括保持当前会话状态的标志，用于所述会议服务功能通知所述远端目标保持当前会话状态。

10.如权利要求9所述会议业务实现方法，其特征在于，所述需要保持当前会话状态的标志携带在Replaces头域或者Join头域中，或者通过一个单独头域或扩展头域或参数携带。

11.如权利要求1所述会议业务实现方法，其特征在于，所述会议服务功能根据所述与会标识参数通知与会者加入会议之前还包括获取当前会话状态：

所述会议服务功能向所述远端目标发送订阅/通知请求，要求获得当前会话状态；

所述远端目标向所述会议服务功能发送当前会话状态。

12.如权利要求1至11中任一项所述会议业务实现方法，其特征在于，所述远端目标包括目标终端或与会议发起者建立SIP会话的中间实体。

13.如权利要求1至11中任一项所述会议发起终端，其特征在于，在IMS网络中所述会议服务功能为包括应用服务器AS；所述会议发起者和与会者包括：IP多媒体服务IMS终端设备、媒体网关控制功能MGCF或应用服务器AS。

14.一种会议服务功能实体，其特征在于，包括：

接收单元，用于接收来自会话发起者的建立会议请求，所述请求中包括与会标识参数；

15.如权利要求14所述会议服务功能实体，其特征在于，还包括：

路由选择单元，与所述会议加入单元连接，用于所述会议服务功能与所述会议发起者已经建立会话时，与所述建立会议请求中的远端目标进行通信。

16.如权利要求15所述会议服务功能实体，其特征在于，还包括：

路由优化单元，与所述路由选择单元连接，用于将包含在统一资源列表表项中路由集中，且没有包含在会议发起者与会议服务功能之间的SIP会话路由集中的路由项作为会议服务功能到与会者的路由。

17.如权利要求14所述会议服务功能实体，其特征在于，会议加入单元具体包括：

当前会话状态获取子单元，用于从远端目标获取当前会话状态；

会议加入子单元，与所述当前会话状态获取子单元连接，用于将所述远端目标加入当前会话。

18.一种会议发起装置，其特征在于，包括：

建立会议请求生成单元，用于根据已存在会话参数生成建立会议请求，所述请求中包括与会标识参数；

建立会议请求发送单元，与所述建立会议请求生成单元连接，用于使会议服务功能通知所述与会者加入会议。

19.如权利要求18所述会议发起装置，其特征在于，还包括：

当前会话状态获取请求单元，用于向所述远端目标发送订阅/通知请求，要求获得当前会话状态；

当前会话状态接收单元，用于接收所述远端目标向所述会议发起装置发送的当前会话状态。