一种实现呼叫腿转移的方法 【技术领域】
本发明涉及通信系统中呼叫转移技术，特别是指一种实现呼叫腿转移的方法。
背景技术
在电信网络开放的业务体系中，应用服务器对下层复杂的电信网络能力进行封装和抽象，提供简单、开放的业务能力接口给应用，应用使用开放的业务能力接口来开发业务。
多方呼叫是指一个呼叫中有三个或者三个以上的呼叫方，每个呼叫方称为一个呼叫腿。在多方呼叫的开放接口中，如parlay API和OSA API，只抽象了增加和释放呼叫腿的管理功能，而无法实现将一个呼叫腿从一个呼叫转移到另一个呼叫的功能。即如果一个呼叫中的呼叫腿要加入到另外一个呼叫中，只能先断掉与源呼叫之间的连接，再与目地呼叫建立连接才能实现。这种加入到另外一个呼叫的方式，对于用户来说，需要断掉连接重新加入，呼叫腿在源呼叫中的数据和状态在加入到新呼叫后都发生变化，因此，这种方式不仅步骤烦琐，而且许多必要的信息也丢失。
因此，现有的技术方案无法真正实现呼叫腿转移业务功能。
【发明内容】
有鉴于此，本发明的目的是提供一种实现呼叫腿转移的方法，使应用实现呼叫腿转移的相关业务。
一种实现呼叫腿转移的方法包括：
A.预先设置呼叫腿转移接口，用于将源呼叫中指定呼叫腿转移至目的呼叫，所述呼叫腿转移接口的接口引用参数为待转移的呼叫腿标识和目的呼叫标识；
B.当应用要转移呼叫腿时，根据待转移的呼叫腿和目的呼叫确定接口引用参数，然后根据接口引用参数调用所述呼叫腿转移接口，将所述呼叫腿转移到目的呼叫。
将所述呼叫腿转移到目的呼叫进一步包括：
B1、应用通知源呼叫将呼叫腿转移到目的呼叫；
B2、源呼叫断开该呼叫腿所占用的资源，设置该呼叫腿的呼叫信息，向目的呼叫发出呼叫腿转移请求；
B3、目的呼叫收到来自源呼叫的请求后，判断自身可用资源是否够用，如果够用，则为该呼叫腿分配资源，呼叫腿转移成功，否则，呼叫腿转移失败。
在步骤B3之后，该方法进一步包括：目的呼叫通知应用转移结果。
所述步骤B2进一步包括：通知所述呼叫腿对应的用户终端，该呼叫腿要转移到目的呼叫中。
步骤B2中所述呼叫信息至少包括呼叫标识、媒体类型、计费策略和终端信息，所述设置该呼叫腿的呼叫信息是仅将呼叫信息中所属源呼叫标识更改为目的呼叫标识。
所述源呼叫和目的呼叫为多方呼叫。
所述呼叫腿转移接口是在原有Parlay规范的多方呼叫IpMultiPartyCall接口中进一步增加呼叫腿转移功能而设置。
本发明通过向应用提供呼叫转移接口，当需要转移呼叫腿时，简单调用该接口即可实现呼叫腿转移，对应用来说，开发具有呼叫腿转移功能特性的业务方便、简单。
【附图说明】
图1为本发明开放呼叫转移接口的示意图；
图2实现本发明方法的流程示意图；
图3为呼叫腿转移接口提供方法的具体流程示意图；
图4为以基于web的多方聊天业务为例进行呼叫腿转移示意图；
图5为应用本发明方法的具体流程示意图。
【具体实施方式】
为使本发明的目的、技术方案、及优点更加清楚明白，以下参照附图并举实施例，对本发明进一步详细说明。
本发明的方法是将呼叫腿转移功能抽象的开放接口提供给应用，应用通过调用该接口可以实现呼叫腿转移等一些具有相关功能特性的业务，如呼叫保持，呼叫转接等。
参见图1所示，本发明提供接口的网络结构可以分为三层：上层、中间层和下层。其中，上层为业务应用层，中间层为能力抽象层，下层为电信网络层。能力抽象层将下层电信网络能力进行抽象，封装成多个独立的功能，如呼叫控制、消息、移动管理等，这些功能提供相应的接口给应用，应用调用不同的接口使用下层的网络能力得到电信业务。每个独立功能由一些小功能组成，本发明提供的呼叫腿转移的功能属于呼叫控制功能中的一个小功能。
参见图2所示，实现本发明的方法包括以下步骤：
步骤201、预先设置呼叫腿转移接口，用于将源呼叫中指定的呼叫腿转移至目的呼叫，所述呼叫腿转移接口的接口引用参数为待转移的呼叫腿标识和目的呼叫标识，输出参数为转移结果；
步骤202、当应用要转移呼叫腿时，根据待转移的呼叫腿和目的呼叫确定接口引用参数，然后根据接口引用参数调用所述呼叫腿转移接口，使呼叫腿断开占用源呼叫中的资源，为呼叫腿分配目的呼叫中的资源，将呼叫腿转移到目的呼叫，并且向应用返回转移结果。
参见图3所述，呼叫腿转移接口提供的方法包括以下步骤：
步骤301、应用通知源呼叫要将某呼叫腿转移到目的呼叫；
步骤302、源呼叫断开该呼叫腿所占用的资源，设置该呼叫腿的呼叫信息，然后向目的呼叫发出将所述呼叫腿转移的请求。这里，呼叫信息至少包括呼叫标识、媒体类型、计费策略和终端信息，该呼叫腿的呼叫信息主要是通过更改呼叫信息中所属呼叫标识来设置，呼叫信息中的媒体类型、计费策略和用户终端信息可以保持不变。
步骤303、目的呼叫收到来自源呼叫方的请求后，判断自身可用资源是否够用，如果够用，则为该呼叫腿分配资源，呼叫腿转移成功，否则，呼叫腿转移失败。
步骤304、目的呼叫将转移结果通知源呼叫，源呼叫再将该转移结果通知应用。
从上述过程可以看出，呼叫腿转移的方法是断开呼叫腿所占用源呼叫中的资源，并且将该呼叫腿的呼叫信息中涉及源呼叫的信息更改为目的呼叫信息，原有状态和数据保持不变。然后为该呼叫腿分配目的呼叫中的资源，从而使该呼叫腿在源呼叫中悬置，转移到目的呼叫中，与目的呼叫中每个呼叫方可以进行通信。当然，在所述步骤302中，可以通知所述呼叫腿对应的用户终端，该呼叫腿转移到目的呼叫中，使用户终端及时了解自身所处的呼叫环境。而且，上面所述资源可以为信道资源。当然，呼叫腿转移接口可以通过新定义来实现，也可以在原有接口中增加呼叫腿转移功能来实现。
本发明可以直接定义一个开放接口IrpMultiPartyCall，包括destCall：inIpMultiPartyCall和legID：TpCallLegIdentifier参数，通过该接口提供呼叫腿转移的方法。其中，destCall：in IpMultiPartyCall，为呼叫腿要转移到的目的呼叫的接口引用；legID：TpCallLegIdentifier，为要转移的呼叫腿标识，包括呼叫腿的ID和呼叫腿的接口引用。并且，调用该接口后返回一个布尔型的数值，表示呼叫腿转移成功与否，返回值为true，表示成功；返回值为false，表示失败。
本发明还可以在Parlay API多方呼叫的IpMultipartyCall接口中增加呼叫腿转移的方法来实现呼叫腿从一个呼叫转移到另一个呼叫。可以包括destCall：in IpMultiPartyCall和legID：TpCallLegIdentifier参数。其中，destCall：in IpMultiPartyCall，为呼叫腿要转移到的目的呼叫的接口引用；legID：TpCallLegIdentifier，要转移的呼叫腿标识，包括呼叫腿的ID和呼叫腿的接口引用。并且，该方法返回一个布尔型的数值，表示呼叫腿转移成功与否，返回值为true，表示成功；返回值为false，表示失败。
需要强调的是，要实现呼叫腿移动功能，必须具备两个前提条件：一是需要移动到新的呼叫的呼叫腿预先要断开源呼叫分配的资源连接；二是在呼叫腿移动前新的目的呼叫已经建立。
下面结合图4，以基于web的多方聊天业务来详细说明本发明方法的应用。
基于web的多方聊天业务主要是提供一个web页面，通过该页面可以创建多方呼叫，也可以看到当前存在的所有呼叫以及该呼叫中存在的呼叫者。
参见图4所示，28800001和2880002为呼叫标识，分别对应两个呼叫。在图4中可以看出，呼叫28800001进行了10分20秒，该呼叫中有张三、李四、王五和秦七共四个人，他们中每个人都被称作呼叫中的一方，在呼叫模型中呼叫中的每一方称作一个呼叫腿。在呼叫2880002中共有三方，分别为陈八、赵九和韩十，该呼叫进行了5分钟。
参见图4左边部分所示，在呼叫腿移动前，在呼叫28800001中，张三的号码为2870001，已进行的通话时长共9分钟，目前处于连接状态；李四的号码为2870002，已进行的通话时长共2分钟，目前处于连接状态；王五的号码为2870003，已进行的通话时长共3分钟，目前处于连接状态；秦七的号码为2870004，已进行的通话时长为5分钟，目前处于连接状态。在呼叫28800002中，陈八的号码为2870004，已进行的通话时长共5分钟，目前处于连接状态；赵九的号码2870002，已进行的通话时长共2分钟，目前处于连接状态；韩十的号码为2870002，已进行的通话时长共5分钟，目前处于连接状态。
在呼叫过程中，李四在web页面上，或者是有权限的其他人拖动李四的呼叫腿，从呼叫28800001移动到呼叫28800002中。这相当于李四或其它有权限的人发出呼叫转移请求，应用将调用呼叫转移接口，完成呼叫腿转移。
参见图4右边部分所示，在呼叫腿移动后，呼叫28800001中李四处于保持(Hold)状态，其呼叫腿被悬置，不能再和该呼叫中的其他三人进行通话。李四加入到呼叫28800002中，可以和陈八、赵九和韩十进行通话。
当然，当李四结束在28800002中的通话后，也可以将呼叫腿重新移回呼叫28800001，由于在李四离开期间，其呼叫数据保持不变，比如媒体类型、计费信息等，因此李四可以继续和张三、王五、秦七进行通话。
另外，当28800001中的呼叫方李四代表的呼叫腿处于保持(Hold)状态后，李四可以随时释放该呼叫腿，也就是说李四可以离开该呼叫。而后，如果李四还想要加入28800001呼叫，那么李四就要重新建立新的连接。
参见图5所示，基于图3所述的呼叫腿转移业务，进行呼叫的具体过程如下：
步骤501～504、首先用户A通过web触发业务应用(Application)发起一个多方呼叫请求；应用创建一个多方呼叫，并且将MPCC Call1作为该呼叫的标识；然后MPCC Call1根据用户A设定的呼叫方号码创建呼叫腿，并且将callLeg1作为该呼叫腿的标识。
步骤505～508、用户B通过web触发业务应用Application发起另一个多方呼叫；应用创建一个多方呼叫，并且利用MPCC Call2来标识该呼叫；MPCC Call2根据用户B设定的呼叫方号码来创建呼叫腿；并且使用callLeg2来标识该呼叫腿。
步骤509～510、在呼叫进行过程中，用户A通过web拖动呼叫腿callLeg1，将其从呼叫MPCC call1拖到MPCC call2；然后应用Application通知MPCCCall1将呼叫腿callLeg1移到呼叫MPCC call2。
步骤511～512、MPCC call1收到该通知后，根据应用传送的moveLeg中的legID：TpCallLegIdentifier找到要移动的呼叫腿，通知callLeg1对应的呼叫方用户，该呼叫腿将由呼叫MPCC call1转移到MPCC call2；然后MPCCcall1断开呼叫MPCC call1为callLeg1分配的资源。此后，callLeg1已经被悬置，无法和MPCC call1中的其他呼叫方进行通讯。
步骤513、然后，MPCC call1通知callLeg1将其所属的呼叫信息进行更改，即将呼叫腿callLeg1中关于MPCC call1的一些信息更改为MPCC call2的信息，如呼叫的标识和接口引用等。当然，呼叫腿callLeg1中的其他信息保持不变，如呼叫的媒体类型，计费策略，终端信息等。
步骤514、MPCC call1根据应用传送的moveLeg中destCall：inIpMultiPartyCall找到呼叫腿移动的目的呼叫MPCC call2，然后给MPCC call2发送通知，请求将呼叫腿callLeg1加入到MPCC call2呼叫中，并将呼叫腿的标识的引用传给MPCC call2。
步骤515～516、在MPCC call2收到来自MPCC call1的请求后，为callLeg1分配资源，MPCC call2将执行结果，如True或False，通知MPCCcall。在资源分配成功后，呼叫腿callLeg1可以和MPCC call2呼叫中的其他呼叫腿进行通讯。当然，资源分配的成功与否与MPCC call2中的可用资源是否够用以及MPCC call2是否愿意接受该呼叫腿有关。
步骤517、MPCC call1收到来自MPCC call2的执行结果后，判断该呼叫腿是否转移成功，若转移成功，向应用返回true，如果转移失败，向应用返回false。
以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。