专利名称：一种处理分叉业务的方法
技术领域：
本发明涉及通信技术领域，特别是指一种处理分叉业务的方法。
背景技术：
会话发起协议(SIP，Session Initiation Protocol)是由IETF(Interne工程任务组)提出的IP电话信令协议。正如其名字所隐含的，SIP用于发起会话，控制多个参与者参加的多媒体会话的建立和终结，并能动态调整和修改会话属性，如会话带宽要求、传输的媒体类型(语音、视频和文本等)、媒体的编解码格式、对组播和单播的支持等。
SIP协议具有很多特性，其中一个非常有用的特性是分叉(fork)功能，即一个有状态代理服务器可以分叉转发一个请求，从而实现将一个请求消息路由到多个目的地，且该多个目的地将分别返回应答消息，即多个目的地都按照收到一个正常的请求进行相应的处理。这样，如果接收方签约了分叉功能，只要发送方发出一个呼叫后，有状态代理服务器将该呼叫发送到多个目的地。这个特色使SIP能够支持一些传统电话通信服务，如多方通话或分机接听。其中有状态代理服务器是指代理服务器会记住它所收到的每个请求的信息，如事务状态，以及作为某一请求的处理结果而发送的任何请求的信息，这些信息将会影响它对后续的、和先前接收的某一请求相关的消息的处理。
根据SIP协议的描述，对多个目的地返回的多个应答消息，可以由代理服务器处理，也可以直接转发给呼叫的发起方处理。
多媒体子系统(IMS)叠加在分组域网络之上，由于IMS网络的结构做到了和底层承载网络无关，因此IMS实现了和用户使用终端类型的无关性以及和接入网络类型的无关性，因此，IMS不仅可以应用在3GPP网络构架上，还可以应用在其它多种网络构架上。在IMS中，使用SIP协议作为IP多媒体会话的信令控制协议。3GPP在选用SIP作为信令控制协议的时候，只使用了一种处理方式，即对于使用分叉业务导致的多个应答，交给呼叫的发起方进行处理，有状态代理服务器只是负责转发消息。
现有的处理分叉业务的方法有以下两种，下面分别说明。
图1所示为现有技术一的处理流程示意图。该方法主要思路是当发起会话请求的客户端接收到第一个最终响应后，立刻给发送最终响应的客户端返回一个应答(ACK)作为确认，然后删除其它存在的为同一个会话建立的并已挂起的分支对话。之后，与第一个返回最终响应的客户端进行交互，并开始传输数据。在本流程中，客户端A是发起会话请求的客户端，接收方签约了分叉功能，即接收方的目的客户端为客户端B和C两个客户端，代理服务器(Proxy Server)是一个有状态的代理服务器，现有技术一的具体流程如下步骤101，客户端A发送邀请(INVITE)请求给代理服务器；步骤102a、102b，代理服务器根据接收方的签约信息，执行分叉功能，复制INVITE请求，分别转发给客户端B和客户端C；步骤103a、103b，收到INVITE请求的客户端B和C分别对INVITE请求做出临时响应，分别返回183(Session Progress会话进行中)响应给代理服务器；步骤104a、104b，代理服务器分别转发收到的183响应给客户端A；步骤105a、105b，客户端A发送临时确认PRACK(provisionalacknowledgement)给代理服务器，用于确认收到的183响应；步骤106a、106b，代理服务器分别转发收到的PRACK消息给客户端B和客户端C；步骤107a、107b，客户端B和C对收到PRACK作出响应，分别返回200 OK给代理服务器；
步骤108a、108b，代理服务器分别转发收到的200 OK消息给客户端A；步骤109，客户端B完成了媒体协商和资源预留，返回一个针对INVITE的最终响应200 OK给代理服务器；步骤110，代理服务器将这个最终响应转发给客户端A；步骤111，客户端A返回ACK消息给代理服务器，确认收到最终响应200 OK；步骤112，代理服务器转发ACK消息给对应的客户端B；此时，客户端A根据协商成功的媒体描述分配所需的资源，开始向客户端B传输数据；步骤113，客户端A发现针对该会话还存在其他对话没有收到最终响应，则立刻发起针对这些对话的删除过程，即客户端A发送取消(CANCEL)请求给代理服务器；步骤114，代理服务器转发CANCEL消息给对应的客户端C；步骤115，客户端C收到CANCEL之后执行删除对话，释放资源等操作，然后返回200 OK作为删除对话执行成功的响应；步骤116，代理服务器转发这个200 OK响应给客户端A，至此，客户端A完成了和客户端C之间的对话的删除过程。
上述接收客户端可以是自动应答设备，也可以是非自动应答设备。
从上述流程中可以看出，发起会话请求的客户端一旦收到第一个最终响应，将立刻取消针对该会话的其它挂起的对话，即立刻取消已经收到了临时响应，但还没有收到最终响应且也没有发送CANCEL消息的对话。
虽然发起会话请求的客户端发送了CANCEL消息，却无法保证自身不会收到针对该会话的其他分支的最终响应，这是因为，这些最终响应消息可能在CANCEL消息发送和处理之前就已经产生了。比如，对于实现了自动应答的设备，接收方处理能力很高，执行媒体协商和资源预留的过程很快就完成了，因此，当发起会话请求的客户端发送了CANCEL消息之后，可能还要收到后续的最终响应的200 OK消息。对于这些最终响应，同样需要发起方作适当的处理，即先确认这个最终响应，然后再通过发送删除(BYE)消息发起对话的删除过程；同时，由于接收方收到CANCEL消息之后可能发现要取消的挂起的对话已经不存在了，因为该对话已经发送了最终响应消息，该对话的状态已经发生了变化，但这时接收方还需作相应的处理。
通过以上分析可以看出，对于现有技术一的方案而言，无论是会话的发起方还是接收方，都需要保存大量的会话状态，还要能够区分正常的分叉功能导致的各类异常状态和真正的会话异常状态，使得业务逻辑及处理过程都非常复杂。而且，采用现有技术一的方法，在接收方响应速度比较快时，发起方对同一个对话需要进行两次处理，一次是针对处于挂起状态的对话进行的处理，另一次是收到该同一对话的最终响应后对该对话进行的处理，虽然两次处理时的状态不一样，但是，这两次处理的目的都是要取消这个已经没有意义的对话，不过是由于处理方法的不善，导致需要两次取消过程，造成了大量的冗余信令。
图2所示为现有技术二的处理流程示意图。该方法主要思路是当发起会话请求的客户端接收到第一个最终响应后，立刻给发送最终响应的客户端返回一个应答(ACK)作为确认，然后与该第一个返回最终响应的客户端进行交互，并开始传输数据。此时，发起会话请求的客户端中将存在多个针对同一个会话的挂起的对话，当发送方后续又收到了针对这次会话的其它分支对话的最终响应后，先发送ACK确认这个对话，然后立刻发送BYE删除这个对话。在本流程中，客户端A是发起会话请求的客户端，接收方签约了分叉功能，即接收方的目的客户端为客户端B和C两个客户端，代理服务器(Proxy Server)是一个有状态的代理服务器，现有技术二的具体流程如下步骤201，客户端A发送邀请(INVITE)请求给代理服务器；步骤202a、202b，代理服务器根据接收方的签约信息，执行分叉功能，复制INVITE请求，分别转发给客户端B和客户端C；
步骤203a、203b，收到INVITE请求的客户端B和C分别对INVITE请求做出临时响应，分别返回183(Session Progress会话进行中)响应给代理服务器；步骤204a、204b，代理服务器分别转发收到的183响应给客户端A；步骤205a、205b，客户端A发送PRACK给代理服务器，用于确认收到的183响应；步骤206a、206b，代理服务器分别转发收到的PRACK消息给客户端B和客户端C；步骤207a、207b，客户端B和C对收到PRACK作出响应，分别返回200 OK给代理服务器；步骤208a、208b，代理服务器分别转发收到的200 OK消息给客户端A；步骤209，客户端B完成了媒体协商和资源预留，返回一个针对INVITE的最终响应200 OK给代理服务器；步骤210，代理服务器将这个最终响应转发给客户端A；步骤211，客户端A返回ACK消息给代理服务器，确认收到最终响应200 OK；步骤212，代理服务器转发ACK消息给对应的客户端B；此时，客户端A根据协商成功的媒体描述分配所需的资源，开始向客户端B传输数据；步骤213，客户端C也完成了媒体协商和资源预留，返回一个针对INVITE的最终响应200 OK给代理服务器；步骤214，代理服务器将这个最终响应转发给客户端A；步骤215，客户端A返回ACK消息给代理服务器，确认收到最终响应200 OK；步骤216，代理服务器转发ACK消息给对应的客户端C；步骤217，由于客户端A已经和客户端B建立了会话，因此，A立刻发起针对这些后续对话的删除过程，发送BYE请求给代理服务器；
步骤218，代理服务器转发BYE消息给对应的客户端C；步骤219，客户端C收到BYE之后执行删除对话，释放资源等操作，然后返回200 OK作为删除对话执行成功的响应；步骤220，代理服务器转发这个200 OK响应给客户端A，至此，客户端A处完成了和客户端C之间的对话的删除过程。
上述接收客户端可以是自动应答设备，也可以是非自动应答设备。
在现有技术二的实现方案中，发起会话请求的客户端一旦收到第一个最终响应200 OK消息，就返回ACK确认，然后建立会话开始数据传输过程，而对于该会话中的其它已经挂起的且没有发送CANCEL消息分支对话，发起方不作任何后续处理，只有当这些对话所在的分支有最终响应200 OK到达时，才进行处理，即先确认这个对话的建立，然后立刻删除。
现有技术二虽然解决了对同一个对话处理两次的问题，但其还存在很大缺陷当签约了分叉功能的发送方接收到第一个最终响应之后，其余分支上的对话如何处理，没有明确说明，虽然通过后续收到其他分支上的对话的最终响应，可以删除该对话，但是这意味着接收方要先完成媒体的协商，预留资源，完成所有建立会话所需的处理之后，得到的结果就是删除这个对话。这不但是对客户端及服务器资源的浪费，如果在媒体协商过程中需要用户的交互，那么这时候对用户的使用感受来说也非常不好用户已经做好了接受会话的准备，却收到对方删除会话的消息。更何况接收方不是一定会返回最终响应的，如果由于某些原因，发起方始终没有收到某个分支对话的最终响应，则发起方和代理服务器就必须一直维持这些对话的状态信息，只有通过定时器才能够删除这些对话，资源的使用率低。
发明内容
有鉴于此，本发明的目的在于提供一种处理分叉业务的方法，既简化对使用分叉功能的会话的处理和实现，还可以节省资源，同时避免了给用户带来不舒服的使用感受。
为达到上述目的，本发明的技术方案是这样实现的一种处理分叉业务的方法，该方法包括以下步骤a、会话发起方客户端接收到来自接收方客户端的最终响应后，判断该最终响应是否为针对会话请求INVITE收到的第一个最终响应，如果是，则启动一个对该会话的所有对话均有效的定时器，同时构造并发送针对该最终响应的确认信息，建立会话，之后执行步骤c，否则执行步骤b；b、直接构造并发送针对该最终响应的确认信息，然后构造并发送删除消息删除本步骤中建立的会话，之后执行步骤c；c、会话发起方客户端判断定时器的定时时间是否超时，如果是，执行步骤d，否则判断是否收到最终响应，如果是，执行步骤a，否则重复执行步骤c；d、构造并发送删除消息删除本会话中处于挂起状态的对话后，按照正常流程继续后续处理。
较佳地，步骤c所述会话发起方客户端判断出定时器的定时时间超时后，进一步包括，判断当前是否还存在未处理的已挂起的对话，如果存在，再执行步骤d，否则按照正常流程继续后续处理。
较佳地，所述接收方客户端包括自动应答设备和非自动应答设备，或者所述接收方客户端仅包括自动应答设备，或者所述接收方客户端仅包括非自动应答设备。
较佳地，所述定时器的定时时间长度大于等于自动应答设备所需的应答时间，且小于等于非自动应答设备所需的应答时间。
较佳地，所述删除本会话中处于挂起状态的对话的删除消息为BYE消息。
较佳地，所述删除本会话中处于挂起状态的对话的删除消息为CANCEL消息。
较佳地，所述会话发起方客户端发送给接收方客户端的信息以及接收到的来自接收方客户端的信息是经有状态代理服务器转发的。
应用本发明，当发起方的客户端收到第一个最终响应时，为针对该会话的其他挂起的对话设置一个通用的定时器，在定时器超时之前，发起方客户端将按照正常的收到最终响应的处理来执行对话的删除过程，不会涉及到挂起对话的处理，当定时器超时之后，发起方客户端发送BYE或者CANCEL请求删除还存在的已挂起的对话。这样，通过合理的设置定时器的时长，对接收方处理速度较快的对话，在定时器超时之前就已经返回了200 OK最终响应，发起方客户端将按照正常的收到最终响应的处理来执行对话的删除过程，不会涉及到挂起对话的处理，而对于需要用户交互而导致响应时间较长的接收方，发起方客户端将使用BYE或者CANCEL消息删除这些对话，这样在接收方避免了先建立会话又立刻被删除的情况。应用本发明，不但可以简化对使用分叉功能的会话的处理和实现，还节省了客户端和服务器的大量资源，同时避免了给用户带来不舒服的使用感受。本发明实现简单，且能够为运营商的实际运营带来很多好处和便利。
图1所示为现有技术一的处理流程示意图；图2所示为现有技术二的处理流程示意图；图3所示为应用本发明会话发起方接收到最终响应后的处理流程示意图；图4所示为应用本发明会话发起方判断定时器超时后的处理流程示意图；图5所示为应用本发明的处理流程示意图。
具体实施例方式
下面结合附图对本发明再做进一步地详细说明。
本发明的思路是当发起方的客户端收到第一个最终响应时，为针对该会话的其他挂起的对话设置一个通用的定时器，在定时器超时之前，发起方客户端将按照正常的收到最终响应的处理来执行对话的删除过程，不会涉及到挂起对话的处理，当定时器超时之后，发起方客户端发送BYE或者CANCEL请求删除还存在的已挂起的对话。
图3所示为应用本发明会话发起方接收到最终响应后的处理流程示意图。
步骤301，当会话发起方客户端收到一个针对INVITE请求的最终响应200 OK消息后，首先判断这个最终响应是否是针对该会话请求收到的第一个最终响应，如果是，执行步骤302～303，否则执行步骤304～305；步骤302～303，启动一个定时器T，该定时器对该会话的所有对话有效；同时针对该200 OK响应，构造ACK消息作为确认，建立会话；步骤304～305，先对收到的200 OK消息作出确认，然后立刻构造BYE消息删除刚刚建立的会话，这是因为，如果收到的针对INVITE请求的最终响应200 OK消息不是该客户端收到的第一个最终响应，说明针对INVITE请求已建立起了会话，因此这个200 OK对应的会话需要被删除。
图4所示为应用本发明会话发起方判断定时器超时后的处理流程示意图。当定时器T超时之后，客户端首先检查针对该INVITE请求建立的对话中是否还有挂起的且未处理的对话，如果有，构造BYE或者CANCEL消息，删除这些挂起的对话，然后照正常流程执行后续处理；如果没有，则客户端继续按照正常流程执行后续处理。
针对图3和图4，需要说明几个问题。
首先是定时器T的定时长度的选取。根据对接收方客户端处理会话请求的分析，一个接收方客户端存在两种应答方式，一种是不需要用户干预的自动应答方式，一般针对一些以机器或者设备作为客户端的情况，或者用户在终端设备上设置了由终端设备执行自动应答的情况，这种应答因为是设备自动执行的，因此处理速度很快，一般可以在几秒之内处理完；另一种是需要用户进行交互之后才可以应答的非自动应答方式，这种方法普遍用于各种需要用户进行决策的情况下，因为存在人机交互过程，或者人的选择和决定过程，因此返回最终应答所需的处理时间较长，通常至少需要十多秒。经上述分析，定时器T的定时长度设置为十秒以内且接近十秒的时间，即大于等于自动应答设备所需的应答时间，同时小于等于非自动应答设备所需的应答时间。当然，这里给出的定时器时长只是一个经过分析之后的建议值，随着设备处理能力的提高，这个定时器时长的设置也会不断发生变化，因此，具体实现时，这个值应该是运营商通过实验和测试确定的一个实践值。
由于定时器的定时长度是经分析以及通过多次实验和测试后得到的，因此，通过定时时间可以将两种应答方式的处理情况区分开，且保证两种应答方式之间不会发生冲突，即不会发生定时器T超时之后，还有自动应答的最终响应没有收到的情况，同时也不会发生定时器T超时之前，用户已经完成了和终端设备的交互过程，返回了最终响应的情况。
当然，应用本发明的处理方法，对接收方没有任何限制，其可以既包含自动应答设备又包含非自动应答设备，还可以仅由自动应答设备组成，或者仅由非自动应答设备组成。
其次，当定时器超时之后，会话发起方的客户端可以使用BYE消息删除挂起的对话，也可以使用CANCEL消息。BYE消息可以删除已经建立的会话，也可以删除挂起的对话，即两种情况的处理都可以适用；CANCEL请求则只用来删除挂起的对话，由于在本发明所示的处理过程中只涉及到删除挂起的对话，因此这两种消息都可以使用。
图5所示为应用本发明的处理流程示意图。在本流程中，客户端A是发起会话请求的客户端，接收方签约了分叉功能，即接收方的目的客户端为客户端B、C和D，代理服务器(Proxy Server)是一个有状态的代理服务器，具体流程如下步骤501，客户端A发送邀请(INVITE)请求给代理服务器；步骤502a、502b、502c，代理服务器根据接收方的签约信息，执行分叉功能，复制INVITE请求，分别转发给客户端B、客户端C和客户端D；
步骤503a、503b、503c，收到INVITE请求的客户端B、C和D分别对INVITE请求做出临时响应，分别返回183(Session Progress会话进行中)响应给代理服务器；步骤504a、504b、504c，代理服务器分别转发收到的183响应给客户端A；步骤505a、505b、505c，客户端A发送PRACK给代理服务器，用于确认收到的183响应；步骤506a、506b、506c，代理服务器分别转发收到的PRACK消息给客户端B、客户端C和客户端D；步骤507a、507b、507c，客户端B、C和D对收到PRACK作出响应，分别返回200 OK给代理服务器；步骤508a、508b、508c，代理服务器分别转发收到的200 OK消息给客户端A；步骤509，客户端B完成了媒体协商和资源预留，返回一个针对INVITE的最终响应200 OK给代理服务器；步骤510，代理服务器将这个最终响应转发给客户端A；客户端判断出其为针对INVEITE请求收到的第一个最终响应后，启动定时器T，然后再执行步骤511；步骤511，客户端A返回ACK消息给代理服务器，确认收到最终响应200 OK；步骤512，代理服务器转发ACK消息给对应的客户端B；此时，客户端A根据协商成功的媒体描述分配所需的资源，开始向客户端B传输数据；步骤513，在定时器T超时之前，客户端C完成了媒体协商和资源预留，返回一个针对INVITE的最终响应200 OK给代理服务器；步骤514，代理服务器将这个最终响应转发给客户端A；步骤515，客户端A返回ACK消息给代理服务器，确认收到最终响应200 OK；步骤516，代理服务器转发ACK消息给对应的客户端C；步骤517，因为客户端A已经和客户端B建立了会话，因此，A立刻发起针对这些后续对话的删除过程，发送BYE请求给代理服务器；步骤518，代理服务器转发BYE消息给对应的客户端C；步骤519，客户端C收到BYE之后执行删除对话，释放资源等操作，然后返回200 OK作为删除对话执行成功的响应；步骤520，代理服务器转发这个200 OK响应给客户端A，至此，A处完成了和C之间的对话的删除过程；步骤521，当客户端A判断出定时器T超时后，发现针对这个INVITE请求建立的会话中还有一个对话被挂起，则发送BYE消息给代理服务器，执行该对话的删除过程；步骤522，代理服务器转发BYE消息给对应的客户端D；步骤523，客户端D收到BYE之后执行删除对话，释放资源等操作，然后返回200 OK作为删除对话执行成功的响应；步骤524，代理服务器转发这个200 OK响应给客户端A，至此，客户端A处完成了和客户端D之间的对话的删除过程。
在上述步骤521中，当客户端A判断出定时器T超时后，发现针对这个INVITE请求建立的会话中还有一个对话被挂起，也可以发送CANCEL消息给代理服务器，执行该对话的删除过程。相应地，代理服务器转发CANCEL消息给客户端A，由客户端A继续执行后续操作。
以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
权利要求
1.一种处理分叉业务的方法，其特征在于，该方法包括以下步骤a、会话发起方客户端接收到来自接收方客户端的最终响应后，判断该最终响应是否为针对会话请求INVITE收到的第一个最终响应，如果是，则启动一个对该会话的所有对话均有效的定时器，同时构造并发送针对该最终响应的确认信息，建立会话，之后执行步骤c，否则执行步骤b；b、直接构造并发送针对该最终响应的确认信息，然后构造并发送删除消息删除本步骤中建立的会话，之后执行步骤c；c、会话发起方客户端判断定时器的定时时间是否超时，如果是，执行步骤d，否则判断是否收到最终响应，如果是，执行步骤a，否则重复执行步骤c；d、构造并发送删除消息删除本会话中处于挂起状态的对话后，按照正常流程继续后续处理。
2.根据权利要求1所述的方法，其特征在于，步骤c所述会话发起方客户端判断出定时器的定时时间超时后，进一步包括，判断当前是否还存在未处理的已挂起的对话，如果存在，再执行步骤d，否则按照正常流程继续后续处理。
3.根据权利要求1或2所述的方法，其特征在于，所述接收方客户端包括自动应答设备和非自动应答设备，或者所述接收方客户端仅包括自动应答设备，或者所述接收方客户端仅包括非自动应答设备。
4.根据权利要求3所述的方法，其特征在于，所述定时器的定时时间长度大于等于自动应答设备所需的应答时间，且小于等于非自动应答设备所需的应答时间。
5.根据权利要求1所述的方法，其特征在于，所述删除本会话中处于挂起状态的对话的删除消息为BYE消息。
6.根据权利要求1所述的方法，其特征在于，所述删除本会话中处于挂起状态的对话的删除消息为CANCEL消息。
7.根据权利要求1所述的方法，其特征在于，所述会话发起方客户端发送给接收方客户端的信息以及接收到的来自接收方客户端的信息是经有状态代理服务器转发的。
全文摘要
本发明提供了一种处理分叉业务的方法，关键是，当发起方客户端收到第一个最终响应时，为针对该会话的其它挂起的对话设置一个通用的定时器，在定时器超时之前，发起方客户端将按照正常的收到最终响应的处理来执行对话的删除过程，不会涉及到挂起对话的处理，当定时器超时之后，发起方客户端发送BYE或者CANCEL请求删除还存在的已挂起的对话。通过合理的设置定时器的时长，避免了先建立会话又立刻被删除的情况。应用本发明，不但可以简化对使用分叉功能的会话的处理和实现，还节省了客户端和服务器的大量资源，同时避免了给用户带来不舒服的使用感受。
文档编号H04L12/54GK1756256SQ20041008107
公开日2006年4月5日 申请日期2004年9月30日 优先权日2004年9月30日
发明者武亚娟 申请人:华为技术有限公司