CN1980225A - 一种第三方控制业务的实现方法 - Google Patents

Abstract

本发明公开了一种第三方控制业务的实现方法，在以会话发起协议提供业务的网络中，对第三方控制的业务包括步骤：业务签约用户已经建立了两个呼叫联系，处理所述业务的应用服务器作为背靠背用户代理处于所述业务签约用户的呼叫信令路径中；该业务签约用户发起第三方控制业务的呼叫操作，发送携带所述呼叫的会话标识的业务操作信息；所述应用服务器收到业务操作信息，根据背靠背用户代理机制定位出所述会话标识对应的会话；所述应用服务器对该会话进行重定向操作，完成所述业务处理。本发明实现方法由于不需要MGCF对SIP REFER消息的支持，实现了CONF和ECT业务，大大简化了业务实现流程，便于业务的推广。

Description

一种第三方控制业务的实现方法

技术领域

本发明涉及一种分组交换网络中的第三方控制业务，尤其涉及呼叫转移和会议实现方法。

背景技术

目前，随着分组技术的不断成熟，基于电路交换的传统电信网络正在向着基于分组交换的宽带电信网发展，而使用SIP(Session InitiationProtocol，会话发起协议，以下简称SIP)作为分组电信核心网的呼叫控制信令则是当前的技术发展趋势之一，如ITU-T和ETSI等标准组织对NGN(Next Genteration Network，下一代网络)的研究，在这种新的分组电信网络中，新的分组终端SIP终端将逐步取代传统的终端话机。

其中，ETSI下属的TISPAN(Telecommunications and Internet ConvergedServices and Protocols for Advanced Networking)将在NGN中向SIP终端用户提供的具有传统业务特征的业务统称为PSTN/ISDN simulation services。TISPAN成立了多个工作项目(Work Item，WI)来研究这些simulation业务，如WI 03023(DTS/TISPAN-03023-NGN-R1 NGN CONF)研究CONF(Conference，会议业务，以下简称CONF)，WI 03055(DTS/TISPAN-03055-NGN-R1 Explicit Communication Transfer)研究显式呼叫转移ECT(Explicit Communication Transfer，以下简称：ECT)业务。

CONF业务可以使用户能够参与和控制一个有许多用户加入的通话，ECT业务使一个通话中的一方能够将该通话转移至第三方，更详尽的业务描述可以参看WI 03023和WI 03055当前最新的标准草案。

在WI 03023和WI 03055当前制订的这两个业务标准中，都使用了相同的技术来实现业务流程，分别分析如下：

1)CONF会议业务流程分析

在CONF会议的业务实现流程中，用户可以邀请一个和其已建立会话关系的用户加入到一个会议中，用户发送SIP REFER消息(会话发起协议参照信息消息)来实现这个功能。在SIP REFER消息中，Request-URI中设置会议标识；Refer-To中设置被邀请用户标识，当被邀请用户有多个注册终端时，还需要在Refer-To中采用全球可路由的用户代理URI(GloballyRoutable User Agent URIs，以下简称为GRUU；Uniform Resource Identifier，统一资源标识，以下简称：URI)来标识和发起邀请用户建立了会话关系的那个被邀请用户终端；Refer-To的method参数设置为“INVITE”；Replaces(替换参数)中设置两个用户之间已经建立的会话Dialog标识，指示该会话将会被会议和被邀请用户之间建立的新会话所代替；

这个SIP REFER消息将根据Request-URI设置的会议标识路由到处理CONF会议业务的应用服务器AS(Application Server，以下简称AS)，AS将根据前述的会话发起协议参照信息SIP REFER消息中的设置内容，向被邀请用户(终端)发送会话发起协议邀请信息SIP INVITE消息(会话发起协议邀请消息)，并且将SIP REFER消息中携带的Replaces信息继续由SIPINVITE消息携带，使会议和被邀请用户(终端)之间建立新的会话，同时被邀请用户(终端)根据SIP INVITE消息中的Replaces信息释放两个用户之间已经建立的会话。

在WI 03023当前标准草案中，给出了一个信令流程示例，如图1所示，其流程简介如下；

步骤1)：用户UE-A发起一个会话，呼叫一个PSTN/ISDN用户。

步骤2～14)：用户UE-A和PSTN/ISDN用户之间会话建立成功，开始通话。

步骤15)：用户UE-A申请创建一个会议，向处理会议业务的AS发起一个会话。

步骤16～24)：用户UE-A申请的会议创建成功。

步骤25)：用户UE-A邀请和他正在通话的PSTN/ISDN用户加入到会议中，向处理会议业务的AS发送SIP REFER消息。

步骤26～30)：SIP REFER消息到达处理会议业务的AS，AS发送SIPNOTIFY消息通知用户UE-A接收了这个REFER消息。

步骤31)：处理会议业务的AS根据收到的SIP REFER消息中设置的相关内容，向PSTN/ISDN用户发起会话，发送SIP INVITE消息。

步骤32～41)：由于PSTN/ISDN用户属于传统电路域用户，电路域和分组域之间将由媒体网关控制功能MGCF(Media Gateway ControlFunctions)处理互通呼叫，SIP INVITE消息发送到MGCF，MGCF将“代替”PSTN/ISDN用户和会议之间创建会话，将PSTN/ISDN用户加入会议。处理会议业务的AS发送SIP NOTIFY消息通知用户UE-A，REFER请求的操作成功。

步骤42～47)：MGCF根据SIP INVITE消息中的Replaces信息，释放Replaces信息中设置的Dialog标识指定的会话(用户UE-A和PSTN/ISDN用户之间已经建立的会话)。

更详尽的流程解释可参见WI 03023当前标准草案，在此不再详细描述。

2)ECT显示呼叫转移业务流程分析

在ECT转移业务的实现流程中，用户B和用户A、用户C分别建立了两个会话，用户B可以使用户A和用户C之间建立新会话，并且使自己退出原先已经建立的两个会话，用户B通过向用户A发送SIP REFER消息来实现这个功能，在SIP REFER消息中，Refer-To中设置了用户C标识，当用户C有多个注册终端时，还可以在Refer-To中采用GRUU来标识和用户B建立了会话关系的那个用户C终端；Refer-To的method参数设置为“INVITE”；Replaces中设置用户B和用户C之间已经建立的会话Dialog标识，指示该会话将会被用户C和用户A之间建立的新会话所代替；Target-Dialog(目标会话参数)中设置用户B和用户A之间已经建立的会话Dialog标识。

用户A收到这个SIP REFER消息后，根据前述的SIP REFER消息中的设置内容，通过Target-Dialog信息确认这是和自己正在会话的用户B发来的呼叫转移请求，向用户C(终端)发送SIP INVITE消息，并且将SIP REFER消息中携带的Replaces信息继续由SIP INVITE消息携带，使用户A和用户C之间建立新的会话，同时用户C根据SIP INVITE消息中的Replaces信息释放其和用户B已经建立的会话。用户A和用户C之间的新会话建立后，用户B将释放其和用户A已经建立的会话。

详尽的流程解释可参见WI 03055当前标准草案，在此不再详细描述。

由此可以看到，在CONF和ECT业务实现流程中，其存在的相同技术点是：用户使用SIP REFER消息来发起业务操作请求、使用GRUU来标识区分和发起业务操作请求用户有会话联系的终端、使用Replaces来指示要被替代释放的会话Dialog标识等。

这些相同的技术方案也使CONF和ECT的业务实现流程存在相同的缺点：

首先，在互通场景下，MGCF需要处理SIP REFER消息，此时MGCF相当于一个SIP UA(UserAgent，用户代理)处理业务，但MGCF的原来功能只是处理分组域和电路域之间的互通呼叫，MGCF能否作为一个SIPUA处理业务目前在标准组织中还存在很大争议，如果最终MGCF的功能维持不变，则使用SIP REFER的技术方案无法满足互通场景下的业务实现流程。

其次，除发起业务操作请求的用户终端外，对参与业务的其他用户终端也有特殊要求，而这些用户其实并没有签约CONF/ECT业务，如果这些用户终端不支持REFER/Refer-To、Replaces、Target-Dialog等操作，则签约了CONF/ECT业务的用户仍然无法成功应用业务。

此外，GRUU机制目前还只是IETF标准组织的一个草案，如果CONF/ECT业务的签约用户终端不支持GRUU机制，则业务也无法应用成功。

从前面分析可以看出，TISPAN WI 03023和WI 03055标准草案的缺点在于签约用户发起的SIP REFER操起被要求发送给参与业务的其他用户终端，从而引起对这些用户终端以及MGCF在业务配合上的特殊要求。

因此，现有技术还有待于继续改进和发展。

发明内容

本发明的目的在于提供一种新的CONF和ECT的业务实现流程，该业务实现流程不需要MGCF对SIP REFER消息的支持、对参与业务的其他用户终端没有特殊要求，不需要使用GRUU机制，大大简化业务实现流程，便于业务的推广。

本发明的技术方案包括：

一种第三方控制业务的实现方法，在以会话发起协议提供业务的网络中，对第三方控制的业务包括步骤：

A)业务签约用户已经建立了两个呼叫联系，处理所述业务的应用服务器作为背靠背用户代理处于所述业务签约用户的呼叫信令路径中；

B)所述业务签约用户发起第三方控制业务的操作，发送携带所述呼叫的会话标识的业务操作信息；

C)所述应用服务器收到业务操作信息，根据背靠背用户代理机制定位出所述会话标识对应需要被重定向的会话；

D)所述应用服务器对所述需被重定向的会话进行重定向操作，完成所述业务处理。

所述的方法，其中，所述第三方控制的操作为所述业务签约用户发起的会话发起协议参照信息操作，所述业务操作信息携带于该会话发起协议参照信息消息中。

所述的方法，其中，所述会话标识设置在所述会话发起协议参照信息消息的替换参数和/或目标会话参数中。

所述的方法，其中，所述重定向操作为所述应用服务器发起再邀请消息。

所述的方法，其中，所述第三方控制的业务是会议业务或显式呼叫转移业务。

所述的方法，其中，所述步骤D还包括：如果应用服务器处理的是显式呼叫转移业务，则还需要释放所述会话标识对应的会话。

本发明所提供的一种呼叫转移和会议的实现方法，由于不需要MGCF对SIP REFER消息的支持、对参与业务的其他用户终端没有特殊要求，不需要使用GRUU机制，而是由处理CONF或ECT业务的AS作为B2BUA(Back to Back User Agent，背靠背用户代理)事先处于签约用户的呼叫信令路径中，并截获签约用户发起的SIP REFER操作，采用重定向技术，从而实现了CONF和ECT业务，大大简化了业务实现流程，便于业务的推广。

附图说明

图1为现有技术的CONF会议业务流程示意图；

图2为本发明方法的第一较佳实施例的流程示意图；

图3为本发明方法的第二较佳实施例的流程示意图；

图4为本发明方法的第三较佳实施例的流程示意图。

具体实施方式

以下结合附图，将对本发明的各较佳实施例进行较为详细的说明。

本发明将提出一种新的CONF和ECT的业务实现流程，该业务实现流程为一第三方控制的业务，不需要MGCF对会话发起协议参照信息SIPREFER消息的支持、对参与业务的其他用户终端没有特殊要求，不需要支持参照操作REFER、参照目标参数Refer-To、替换参数Replaces、目标会话参数Target-Dialog等操作，只需要支持基本的SIP协议机制、不需要使用GRUU机制，签约用户使用SIP REFER消息发起业务操作请求，签约用户的处理CONF/ECT业务的AS作为B2BUA事先处于签约用户的信令路径中，并截获SIP REFER消息，使用重定向技术，即可完成相应的业务处理。

本发明方法的关键技术就在于签约用户的处理CONF/ECT业务的AS作为B2BUA事先处于签约用户的信令路径中，并在收到SIP REFER消息后，不把该消息发送给参与业务的其他用户终端，而是使用一种重定向技术，以完成相应的业务处理。

下面通过三个具体的实施例来说明采用本发明技术所实现的CONF和ECT的业务流程，需要说明的是，本发明中所作的流程图示和文字说明仅为突出本发明的关键技术所作的解释，并不表示一个完整的呼叫和业务控制流程，也没有穷尽所有可能的分支流程。

如图2所示的本发明方法的实施例一，其场景和现有技术图1的会议业务场景类似，不同的是被叫用户与主叫用户一样是一个SIP用户，而不是现有技术的PSTN/ISDN用户：SIP用户UE-A是业务签约用户，SIP用户UE-A和SIP用户UE-B建立通话，SIP用户UE-A申请会议资源创建成功，SIP用户UE-A发起第三方控制操作-REFER操作将用户UE-B也加入会议中。其流程解释如下：

用户UE-A呼叫用户UE-B，发起的SIP INVITE消息，该消息的会话标识假设为Dialog 1，如图2中所示的“INVITE[1]”即表示会话Dialog 1的SIP INVITE消息。

处理CONF业务的AS接收到该SIP INVITE[1]消息，采用SIP协议中的B2BUA机制，终结该会话，并重新向用户UE-B发起一个新的会话SIPINVITE[2]消息，该消息的会话标识假设为Dialog 2。用户UE-B接收到该SIP INVITE[2]消息，应答，发送200 OK[2]响应码。

处理CONF业务的AS接收到该200 OK[2]响应码，转换为200 OK[1]响应码，向主叫用户UE-A发送。用户UE-A接收到该200 OK[1]响应码，发起ACK[1]确认消息。处理CONF业务的AS接收到该ACK[1]确认消息，转换为ACK[2]确认消息，向被叫用户UE-B发送。

用户UE-A和用户UE-B之间的会话建立成功，可以开始通话，用户终端之间可以相互传递媒体流。

和现有技术图1的会议业务实现流程相比，本发明方法很明显的区别在于：处理CONF业务的AS被加入到SIP用户UE-A向被叫用户发起的呼叫信令路径中，该AS采用B2BUA机制，和主叫用户之间创建了Dialog 1的会话，和被叫用户之间创建了Dialog 2的会话。

用户UE-A发起对会议资源的申请，并创建成功，这段流程同现有技术图1的步骤15～24相同，省略说明。用户UE-A发起SIP REFER操作，将用户UE-B也加入到已经创建的会议中。在该REFER消息中，Request-URI设置为已经创建的会议标识conf@home.net，Refer-To设置为用户UE-B的标识，Replaces设置为Dialog 1会话标识。该REFER消息设置的内容即表示希望会议向用户UE-B发起会话请求，邀请其加入会议中。

处理CONF业务的AS收到并解析该SIP REFER消息，根据B2BUA机制判断Replaces中设置的Dialog 1会话标识在被叫这一段对应的是会话标识Dialog 2，则将用户UE-B的会话Dialog 2采用重定向技术将其加入到已经创建的会议中，向用户UE-B再次发送SIP INVITE[2]消息，消息中携带已经创建的会议的SDP信息，由于是再次发送，一般也将该INVITE称为再邀请消息Re-INVITE。

这里可以看到，本发明该实施例中没有采用GRUU机制，即使被叫用户有多个注册终端、有多个同时存在的会话，本实施例中AS通过Replaces中的设置，可以唯一定位对被叫用户的哪一个会话进行重定向。

而在现有技术的图1业务流程中，由于AS没有采用B2BUA和重定向技术，当被叫用户有多个注册终端、有多个同时存在的会话，只能通过GRUU(当然也可能是其它替代技术)先将会话发送到某个被叫用户终端上，Replaces中的设置也只在该被叫用户终端上发挥作用。

所述用户UE-B接收到该SIP Re-INVITE[2]消息，和AS就该消息中携带的会议的SDP信息，进行双方的SDP信息协商，协商过程本实施例略。用户UE-B应答该INVITE[2]消息，发送200 OK[2]响应码。

AS收到该200 OK[2]响应码，发送ACK[2]确认消息。AS和用户UE-B之间的会话Dialog 2的重定向过程完成，用户UE-B先前已经建立的会话Dialog 2被重定向至已经创建的会议中(会话Dialog 2先前的对端SDP信息为用户UE-A的，现在变成了会议的)，即用户UE-B加入到会议中。

本发明方法的第二较佳实施例中，如图3所示的，其场景和现有技术图1的会议业务场景完全相同：SIP用户UE-A是业务签约用户，SIP用户UE-A和PSTN/ISDN用户B建立通话，SIP用户UE-A申请会议资源创建成功，SIP用户UE-A发起REFER操作将用户B也加入会议中。

与本发明方法的实施例一的业务实现流程一样，用户UE-A向PSTN/ISDN用户B发起的呼叫信令路径经过了处理CONF业务的AS，AS采用B2BUA机制分别创建了两段会话，和主叫用户UE-A之间创建了会话Dialog 1，和MGCF之间创建了会话Dialog 2。

所述用户UE-A和用户B之间通话建立成功后，发起对会议资源的申请，并创建成功。用户UE-A发起REFER操作，将用户B也加入到已经创建的会议中，流程解释如下：

用户UE-A发起SIP REFER操作，和实施例一不同的是，在该REFER消息中采用另外一种设置方式，也同样可以达到将被叫用户加入到会议中的效果：Request-URI设置为用户B的标识，Refer-To设置为已经创建的会议标识conf@home.net，Replaces设置为Dialog 1会话标识。该REFER消息设置的内容则表示希望用户B向会议发起会话请求，以加入会议中。

处理CONF业务的AS收到并解析该SIP REFER消息，根据B2BUA机制判断Replaces中设置的Dialog 1会话标识在被叫这一段对应的是会话标识Dialog 2，则将该会话Dialog 2采用重定向技术将其加入到已经创建的会议中，向被叫用户B(MGCF)发送Re-INVITE[2]消息，消息中携带已经创建的会议的SDP信息。

所述MGCF接收到该SIP Re-INVITE[2]消息，和AS就该消息中携带的会议的SDP信息，进行双方的SDP信息协商，协商过程为现有技术所公知，故不再赘述。MGCF应答该INVITE[2]消息，发送200 OK[2]响应码。

AS收到该200 OK[2]响应码，发送ACK[2]确认消息。AS和MGCF(用户B)之间的会话Dialog 2的重定向过程完成，用户B加入到会议中。

本发明方法的第三较佳实施例中，如图4所示：SIP用户UE-B是业务签约用户，用户UE-A和用户UE-B之间建立通话，用户UE-B和用户UE-C之间建立通话，用户UE-B发起第三方控制REFER操作，使用户UE-A和用户UE-C之间建立通话，而用户UE-B则退出和用户UE-A、UE-C之间先前已经建立的通话。

与上述实施例一的业务实现流程一样，用户UE-B和用户UE-A之间的呼叫信令路径经过了处理ECT业务的AS，AS采用B2BUA机制分别创建了两段会话，和用户UE-A之间创建了会话Dialog 1，和用户UE-B之间创建了会话Dialog 2；同样，用户UE-B和用户UE-C之间的呼叫信令路径也经过了处理ECT业务的AS，AS采用B2BUA机制分别创建了两段会话，和用户UE-B之间创建了会话Dialog 3，和用户UE-C之间创建了会话Dialog4。

所述用户UE-B发起REFER操作，使用户UE-A和用户UE-C之间建立通话，流程解释如下：

用户UE-A发起SIP REFER操作，在该REFER消息中，Request-URI设置为用户UE-A标识，Refer-To设置为用户UE-C标识，Target-Dialog设置为Dialog 2会话标识，Replaces设置为Dialog 3会话标识。该REFER消息设置的内容表示希望用户UE-A向用户UE-C发起呼叫请求。

当然，如实施例二所述，该REFER消息也可以采用另外一种设置方式而到达同样的效果：Request-URI设置为用户UE-C标识，Refer-To设置为用户UE-A标识，Target-Dialog设置为Dialog 3会话标识，Replaces设置为Dialog 2会话标识，以表示希望用户UE-C向用户UE-A发起呼叫请求。

处理ECT业务的AS收到并解析该SIP REFER消息，根据B2BUA机制判断Target-Dialog中设置的Dialog 2会话标识在用户UE-A这一段对应的是会话标识Dialog 1，则将该会话Dialog 1重定向至用户UE-C，用户UE-A发送Re-INVITE[1]消息，消息中携带用户UE-C的SDP信息。

用户UE-A接收到该SIP Re-INVITE[1]消息，和AS就该消息中携带的用户UE-C的SDP信息，进行双方的SDP信息协商，协商过程本实施例略。UE-A应答该INVITE[1]消息，发送200 OK[1]响应码。

AS收到该200 OK[1]响应码，获得了已经协商完毕的用户UE-A的SDP信息，并根据B2BUA机制判断Replaces中设置的Dialog 3会话标识在用户UE-C这一段对应的是会话标识Dialog 4，则将该会话Dialog 4重定向至用户UE-A，用户UE-C发送Re-INVITE[4]消息，消息中携带已经协商完毕的用户UE-A的SDP信息。

用户UE-C收到该SIP Re-INVITE[4]消息，应答，发送200 OK[4]响应码。AS收到该200 OK[4]响应码，向用户UE-A发送ACK[1]确认消息。AS向用户UE-C发送ACK[4]确认消息。

用户UE-A和用户UE-C之间的呼叫已经建立，可以看到，这个呼叫仍然是通过AS采用B2BUA机制分别和用户UE-A和用户UE-C之间创建了两段会话：Dialog 1和Dialog 4。

AS需要将用户UE-B退出先前已经创建的、和用户UE-A关联的会话Dialog 2以及和用户UE-C关联的会话Dialog 3，发送SIPBYE[2]消息，释放会话Dialog 2。

用户UE-B收到该BYE[2]消息，释放会话Dialog 2，发送200 OK[2]响应码。AS发送SIP BYE[3]消息，释放会话Dialog 3。

用户UE-B收到该BYE[3]消息，释放会话Dialog 3，发送200 OK[3]响应码。

通过上述三个实施例可以看到，本发明方法处理CONF或ECT业务的AS必须作为B2BUA事先处于签约用户的呼叫信令路径中；其次，AS根据签约用户发起的SIP REFER消息中Replaces/Target-Dialog设置的会话标识，根据B2BUA机制唯一定位出需要被重定向的会话，这样就不需要使用GRUU机制来定位终端；最后，AS对需要被重定向的会话进行重定向，这样参与业务的其它用户终端/MGCF只需要处理基本SIP协议的Re-INVITE消息，不需要支持REFER/Refer-To、Replaces等操作，从而完成业务处理。

最后需要指出的是，本发明方案并不仅仅适用于CONF和ECT业务，而是对使用SIP REFER操作进行第三方控制的业务都适用，业务签约用户已经和另外两个SIP UA建立了呼叫联系，业务签约用户发起REFER操作，REFER消息中携带这两个SIP UA标识，AS收到REFER消息，采用重定向技术，在这两个SIP UA之间建立呼叫联系，从而达到业务签约用户进行第三方控制的目的。比如对于CONF业务来说，签约用户已经和会议资源和另一个用户B分别建立了两个呼叫联系，通过SIP REFER的第三方控制，使用户B和会议资源之间也建立呼叫联系，即使用户B加入会议。

本发明方法不需要MGCF对SIP REFER消息的支持、对参与业务的其他用户终端没有特殊要求，不需要支持REFER/Refer-To、Replaces、Target-Dialog等操作，只需要支持基本的SIP协议机制；不需要使用GRUU机制，而是由处理CONF或ECT业务的AS作为B2BUA事先处于签约用户的呼叫信令路径中，并截获签约用户发起的SIP REFER操作，采用重定向技术，从而实现CONF和ECT业务，大大简化了业务实现流程，便于业务的推广。

应当理解的是，上述针对具体实施例的描述较为详细，但不能因此而理解为对本发明专利保护范围的限制，本发明的专利保护范围应以所附权利要求为准。

Claims (6)

1、一种第三方控制业务的实现方法，在以会话发起协议提供业务的网络中，对第三方控制的业务包括步骤：

A)业务签约用户已经建立了两个呼叫联系，处理所述业务的应用服务器作为背靠背用户代理处于所述业务签约用户的呼叫信令路径中；

B)所述业务签约用户发起第三方控制业务的操作，发送携带所述呼叫的会话标识的业务操作信息；

C)所述应用服务器收到业务操作信息，根据背靠背用户代理机制定位出所述会话标识对应需要被重定向的会话；

D)所述应用服务器对所述需被重定向的会话进行重定向操作，完成所述业务处理。

2、根据权利要求1所述的方法，其特征在于，所述第三方控制的操作为所述业务签约用户发起的会话发起协议参照信息操作，所述业务操作信息携带于该会话发起协议参照信息消息中。

3、根据权利要求1所述的方法，其特征在于，所述会话标识设置在所述会话发起协议参照信息消息的替换参数和/或目标会话参数中。

4、根据权利要求1所述的方法，其特征在于，所述重定向操作为所述应用服务器发起再邀请消息。

5、根据权利要求1所述的方法，其特征在于，所述第三方控制的业务是会议业务或显式呼叫转移业务。

6、根据权利要求1所述的方法，其特征在于，所述步骤D还包括：如果应用服务器处理的是显式呼叫转移业务，则还需要释放所述会话标识对应的会话。

Images