两个人的电影免费视频_国产精品久久久久久久久成人_97视频在线观看播放_久久这里只有精品777_亚洲熟女少妇二三区_4438x8成人网亚洲av_内谢国产内射夫妻免费视频_人妻精品久久久久中国字幕

一種處理分叉業(yè)務(wù)的方法

文檔序號:7597917閱讀:186來源:國知局
專利名稱:一種處理分叉業(yè)務(wù)的方法
技術(shù)領(lǐng)域
本發(fā)明涉及通信技術(shù)領(lǐng)域,特別是指一種處理分叉業(yè)務(wù)的方法。
背景技術(shù)
會話發(fā)起協(xié)議(SIP,Session Initiation Protocol)是由IETF(Interne工程任務(wù)組)提出的IP電話信令協(xié)議。正如其名字所隱含的,SIP用于發(fā)起會話,控制多個參與者參加的多媒體會話的建立和終結(jié),并能動態(tài)調(diào)整和修改會話屬性,如會話帶寬要求、傳輸?shù)拿襟w類型(語音、視頻和文本等)、媒體的編解碼格式、對組播和單播的支持等。
SIP協(xié)議具有很多特性,其中一個非常有用的特性是分叉(fork)功能,即一個有狀態(tài)代理服務(wù)器可以分叉轉(zhuǎn)發(fā)一個請求,從而實現(xiàn)將一個請求消息路由到多個目的地,且該多個目的地將分別返回應(yīng)答消息,即多個目的地都按照收到一個正常的請求進行相應(yīng)的處理。這樣,如果接收方簽約了分叉功能,只要發(fā)送方發(fā)出一個呼叫后,有狀態(tài)代理服務(wù)器將該呼叫發(fā)送到多個目的地。這個特色使SIP能夠支持一些傳統(tǒng)電話通信服務(wù),如多方通話或分機接聽。其中有狀態(tài)代理服務(wù)器是指代理服務(wù)器會記住它所收到的每個請求的信息,如事務(wù)狀態(tài),以及作為某一請求的處理結(jié)果而發(fā)送的任何請求的信息,這些信息將會影響它對后續(xù)的、和先前接收的某一請求相關(guān)的消息的處理。
根據(jù)SIP協(xié)議的描述,對多個目的地返回的多個應(yīng)答消息,可以由代理服務(wù)器處理,也可以直接轉(zhuǎn)發(fā)給呼叫的發(fā)起方處理。
多媒體子系統(tǒng)(IMS)疊加在分組域網(wǎng)絡(luò)之上,由于IMS網(wǎng)絡(luò)的結(jié)構(gòu)做到了和底層承載網(wǎng)絡(luò)無關(guān),因此IMS實現(xiàn)了和用戶使用終端類型的無關(guān)性以及和接入網(wǎng)絡(luò)類型的無關(guān)性,因此,IMS不僅可以應(yīng)用在3GPP網(wǎng)絡(luò)構(gòu)架上,還可以應(yīng)用在其它多種網(wǎng)絡(luò)構(gòu)架上。在IMS中,使用SIP協(xié)議作為IP多媒體會話的信令控制協(xié)議。3GPP在選用SIP作為信令控制協(xié)議的時候,只使用了一種處理方式,即對于使用分叉業(yè)務(wù)導(dǎo)致的多個應(yīng)答,交給呼叫的發(fā)起方進行處理,有狀態(tài)代理服務(wù)器只是負責(zé)轉(zhuǎn)發(fā)消息。
現(xiàn)有的處理分叉業(yè)務(wù)的方法有以下兩種,下面分別說明。
圖1所示為現(xiàn)有技術(shù)一的處理流程示意圖。該方法主要思路是當(dāng)發(fā)起會話請求的客戶端接收到第一個最終響應(yīng)后,立刻給發(fā)送最終響應(yīng)的客戶端返回一個應(yīng)答(ACK)作為確認,然后刪除其它存在的為同一個會話建立的并已掛起的分支對話。之后,與第一個返回最終響應(yīng)的客戶端進行交互,并開始傳輸數(shù)據(jù)。在本流程中,客戶端A是發(fā)起會話請求的客戶端,接收方簽約了分叉功能,即接收方的目的客戶端為客戶端B和C兩個客戶端,代理服務(wù)器(Proxy Server)是一個有狀態(tài)的代理服務(wù)器,現(xiàn)有技術(shù)一的具體流程如下步驟101,客戶端A發(fā)送邀請(INVITE)請求給代理服務(wù)器;步驟102a、102b,代理服務(wù)器根據(jù)接收方的簽約信息,執(zhí)行分叉功能,復(fù)制INVITE請求,分別轉(zhuǎn)發(fā)給客戶端B和客戶端C;步驟103a、103b,收到INVITE請求的客戶端B和C分別對INVITE請求做出臨時響應(yīng),分別返回183(Session Progress會話進行中)響應(yīng)給代理服務(wù)器;步驟104a、104b,代理服務(wù)器分別轉(zhuǎn)發(fā)收到的183響應(yīng)給客戶端A;步驟105a、105b,客戶端A發(fā)送臨時確認PRACK(provisionalacknowledgement)給代理服務(wù)器,用于確認收到的183響應(yīng);步驟106a、106b,代理服務(wù)器分別轉(zhuǎn)發(fā)收到的PRACK消息給客戶端B和客戶端C;步驟107a、107b,客戶端B和C對收到PRACK作出響應(yīng),分別返回200 OK給代理服務(wù)器;
步驟108a、108b,代理服務(wù)器分別轉(zhuǎn)發(fā)收到的200 OK消息給客戶端A;步驟109,客戶端B完成了媒體協(xié)商和資源預(yù)留,返回一個針對INVITE的最終響應(yīng)200 OK給代理服務(wù)器;步驟110,代理服務(wù)器將這個最終響應(yīng)轉(zhuǎn)發(fā)給客戶端A;步驟111,客戶端A返回ACK消息給代理服務(wù)器,確認收到最終響應(yīng)200 OK;步驟112,代理服務(wù)器轉(zhuǎn)發(fā)ACK消息給對應(yīng)的客戶端B;此時,客戶端A根據(jù)協(xié)商成功的媒體描述分配所需的資源,開始向客戶端B傳輸數(shù)據(jù);步驟113,客戶端A發(fā)現(xiàn)針對該會話還存在其他對話沒有收到最終響應(yīng),則立刻發(fā)起針對這些對話的刪除過程,即客戶端A發(fā)送取消(CANCEL)請求給代理服務(wù)器;步驟114,代理服務(wù)器轉(zhuǎn)發(fā)CANCEL消息給對應(yīng)的客戶端C;步驟115,客戶端C收到CANCEL之后執(zhí)行刪除對話,釋放資源等操作,然后返回200 OK作為刪除對話執(zhí)行成功的響應(yīng);步驟116,代理服務(wù)器轉(zhuǎn)發(fā)這個200 OK響應(yīng)給客戶端A,至此,客戶端A完成了和客戶端C之間的對話的刪除過程。
上述接收客戶端可以是自動應(yīng)答設(shè)備,也可以是非自動應(yīng)答設(shè)備。
從上述流程中可以看出,發(fā)起會話請求的客戶端一旦收到第一個最終響應(yīng),將立刻取消針對該會話的其它掛起的對話,即立刻取消已經(jīng)收到了臨時響應(yīng),但還沒有收到最終響應(yīng)且也沒有發(fā)送CANCEL消息的對話。
雖然發(fā)起會話請求的客戶端發(fā)送了CANCEL消息,卻無法保證自身不會收到針對該會話的其他分支的最終響應(yīng),這是因為,這些最終響應(yīng)消息可能在CANCEL消息發(fā)送和處理之前就已經(jīng)產(chǎn)生了。比如,對于實現(xiàn)了自動應(yīng)答的設(shè)備,接收方處理能力很高,執(zhí)行媒體協(xié)商和資源預(yù)留的過程很快就完成了,因此,當(dāng)發(fā)起會話請求的客戶端發(fā)送了CANCEL消息之后,可能還要收到后續(xù)的最終響應(yīng)的200 OK消息。對于這些最終響應(yīng),同樣需要發(fā)起方作適當(dāng)?shù)奶幚?,即先確認這個最終響應(yīng),然后再通過發(fā)送刪除(BYE)消息發(fā)起對話的刪除過程;同時,由于接收方收到CANCEL消息之后可能發(fā)現(xiàn)要取消的掛起的對話已經(jīng)不存在了,因為該對話已經(jīng)發(fā)送了最終響應(yīng)消息,該對話的狀態(tài)已經(jīng)發(fā)生了變化,但這時接收方還需作相應(yīng)的處理。
通過以上分析可以看出,對于現(xiàn)有技術(shù)一的方案而言,無論是會話的發(fā)起方還是接收方,都需要保存大量的會話狀態(tài),還要能夠區(qū)分正常的分叉功能導(dǎo)致的各類異常狀態(tài)和真正的會話異常狀態(tài),使得業(yè)務(wù)邏輯及處理過程都非常復(fù)雜。而且,采用現(xiàn)有技術(shù)一的方法,在接收方響應(yīng)速度比較快時,發(fā)起方對同一個對話需要進行兩次處理,一次是針對處于掛起狀態(tài)的對話進行的處理,另一次是收到該同一對話的最終響應(yīng)后對該對話進行的處理,雖然兩次處理時的狀態(tài)不一樣,但是,這兩次處理的目的都是要取消這個已經(jīng)沒有意義的對話,不過是由于處理方法的不善,導(dǎo)致需要兩次取消過程,造成了大量的冗余信令。
圖2所示為現(xiàn)有技術(shù)二的處理流程示意圖。該方法主要思路是當(dāng)發(fā)起會話請求的客戶端接收到第一個最終響應(yīng)后,立刻給發(fā)送最終響應(yīng)的客戶端返回一個應(yīng)答(ACK)作為確認,然后與該第一個返回最終響應(yīng)的客戶端進行交互,并開始傳輸數(shù)據(jù)。此時,發(fā)起會話請求的客戶端中將存在多個針對同一個會話的掛起的對話,當(dāng)發(fā)送方后續(xù)又收到了針對這次會話的其它分支對話的最終響應(yīng)后,先發(fā)送ACK確認這個對話,然后立刻發(fā)送BYE刪除這個對話。在本流程中,客戶端A是發(fā)起會話請求的客戶端,接收方簽約了分叉功能,即接收方的目的客戶端為客戶端B和C兩個客戶端,代理服務(wù)器(Proxy Server)是一個有狀態(tài)的代理服務(wù)器,現(xiàn)有技術(shù)二的具體流程如下步驟201,客戶端A發(fā)送邀請(INVITE)請求給代理服務(wù)器;步驟202a、202b,代理服務(wù)器根據(jù)接收方的簽約信息,執(zhí)行分叉功能,復(fù)制INVITE請求,分別轉(zhuǎn)發(fā)給客戶端B和客戶端C;
步驟203a、203b,收到INVITE請求的客戶端B和C分別對INVITE請求做出臨時響應(yīng),分別返回183(Session Progress會話進行中)響應(yīng)給代理服務(wù)器;步驟204a、204b,代理服務(wù)器分別轉(zhuǎn)發(fā)收到的183響應(yīng)給客戶端A;步驟205a、205b,客戶端A發(fā)送PRACK給代理服務(wù)器,用于確認收到的183響應(yīng);步驟206a、206b,代理服務(wù)器分別轉(zhuǎn)發(fā)收到的PRACK消息給客戶端B和客戶端C;步驟207a、207b,客戶端B和C對收到PRACK作出響應(yīng),分別返回200 OK給代理服務(wù)器;步驟208a、208b,代理服務(wù)器分別轉(zhuǎn)發(fā)收到的200 OK消息給客戶端A;步驟209,客戶端B完成了媒體協(xié)商和資源預(yù)留,返回一個針對INVITE的最終響應(yīng)200 OK給代理服務(wù)器;步驟210,代理服務(wù)器將這個最終響應(yīng)轉(zhuǎn)發(fā)給客戶端A;步驟211,客戶端A返回ACK消息給代理服務(wù)器,確認收到最終響應(yīng)200 OK;步驟212,代理服務(wù)器轉(zhuǎn)發(fā)ACK消息給對應(yīng)的客戶端B;此時,客戶端A根據(jù)協(xié)商成功的媒體描述分配所需的資源,開始向客戶端B傳輸數(shù)據(jù);步驟213,客戶端C也完成了媒體協(xié)商和資源預(yù)留,返回一個針對INVITE的最終響應(yīng)200 OK給代理服務(wù)器;步驟214,代理服務(wù)器將這個最終響應(yīng)轉(zhuǎn)發(fā)給客戶端A;步驟215,客戶端A返回ACK消息給代理服務(wù)器,確認收到最終響應(yīng)200 OK;步驟216,代理服務(wù)器轉(zhuǎn)發(fā)ACK消息給對應(yīng)的客戶端C;步驟217,由于客戶端A已經(jīng)和客戶端B建立了會話,因此,A立刻發(fā)起針對這些后續(xù)對話的刪除過程,發(fā)送BYE請求給代理服務(wù)器;
步驟218,代理服務(wù)器轉(zhuǎn)發(fā)BYE消息給對應(yīng)的客戶端C;步驟219,客戶端C收到BYE之后執(zhí)行刪除對話,釋放資源等操作,然后返回200 OK作為刪除對話執(zhí)行成功的響應(yīng);步驟220,代理服務(wù)器轉(zhuǎn)發(fā)這個200 OK響應(yīng)給客戶端A,至此,客戶端A處完成了和客戶端C之間的對話的刪除過程。
上述接收客戶端可以是自動應(yīng)答設(shè)備,也可以是非自動應(yīng)答設(shè)備。
在現(xiàn)有技術(shù)二的實現(xiàn)方案中,發(fā)起會話請求的客戶端一旦收到第一個最終響應(yīng)200 OK消息,就返回ACK確認,然后建立會話開始數(shù)據(jù)傳輸過程,而對于該會話中的其它已經(jīng)掛起的且沒有發(fā)送CANCEL消息分支對話,發(fā)起方不作任何后續(xù)處理,只有當(dāng)這些對話所在的分支有最終響應(yīng)200 OK到達時,才進行處理,即先確認這個對話的建立,然后立刻刪除。
現(xiàn)有技術(shù)二雖然解決了對同一個對話處理兩次的問題,但其還存在很大缺陷當(dāng)簽約了分叉功能的發(fā)送方接收到第一個最終響應(yīng)之后,其余分支上的對話如何處理,沒有明確說明,雖然通過后續(xù)收到其他分支上的對話的最終響應(yīng),可以刪除該對話,但是這意味著接收方要先完成媒體的協(xié)商,預(yù)留資源,完成所有建立會話所需的處理之后,得到的結(jié)果就是刪除這個對話。這不但是對客戶端及服務(wù)器資源的浪費,如果在媒體協(xié)商過程中需要用戶的交互,那么這時候?qū)τ脩舻氖褂酶惺軄碚f也非常不好用戶已經(jīng)做好了接受會話的準備,卻收到對方刪除會話的消息。更何況接收方不是一定會返回最終響應(yīng)的,如果由于某些原因,發(fā)起方始終沒有收到某個分支對話的最終響應(yīng),則發(fā)起方和代理服務(wù)器就必須一直維持這些對話的狀態(tài)信息,只有通過定時器才能夠刪除這些對話,資源的使用率低。

發(fā)明內(nèi)容
有鑒于此,本發(fā)明的目的在于提供一種處理分叉業(yè)務(wù)的方法,既簡化對使用分叉功能的會話的處理和實現(xiàn),還可以節(jié)省資源,同時避免了給用戶帶來不舒服的使用感受。
為達到上述目的,本發(fā)明的技術(shù)方案是這樣實現(xiàn)的一種處理分叉業(yè)務(wù)的方法,該方法包括以下步驟a、會話發(fā)起方客戶端接收到來自接收方客戶端的最終響應(yīng)后,判斷該最終響應(yīng)是否為針對會話請求INVITE收到的第一個最終響應(yīng),如果是,則啟動一個對該會話的所有對話均有效的定時器,同時構(gòu)造并發(fā)送針對該最終響應(yīng)的確認信息,建立會話,之后執(zhí)行步驟c,否則執(zhí)行步驟b;b、直接構(gòu)造并發(fā)送針對該最終響應(yīng)的確認信息,然后構(gòu)造并發(fā)送刪除消息刪除本步驟中建立的會話,之后執(zhí)行步驟c;c、會話發(fā)起方客戶端判斷定時器的定時時間是否超時,如果是,執(zhí)行步驟d,否則判斷是否收到最終響應(yīng),如果是,執(zhí)行步驟a,否則重復(fù)執(zhí)行步驟c;d、構(gòu)造并發(fā)送刪除消息刪除本會話中處于掛起狀態(tài)的對話后,按照正常流程繼續(xù)后續(xù)處理。
較佳地,步驟c所述會話發(fā)起方客戶端判斷出定時器的定時時間超時后,進一步包括,判斷當(dāng)前是否還存在未處理的已掛起的對話,如果存在,再執(zhí)行步驟d,否則按照正常流程繼續(xù)后續(xù)處理。
較佳地,所述接收方客戶端包括自動應(yīng)答設(shè)備和非自動應(yīng)答設(shè)備,或者所述接收方客戶端僅包括自動應(yīng)答設(shè)備,或者所述接收方客戶端僅包括非自動應(yīng)答設(shè)備。
較佳地,所述定時器的定時時間長度大于等于自動應(yīng)答設(shè)備所需的應(yīng)答時間,且小于等于非自動應(yīng)答設(shè)備所需的應(yīng)答時間。
較佳地,所述刪除本會話中處于掛起狀態(tài)的對話的刪除消息為BYE消息。
較佳地,所述刪除本會話中處于掛起狀態(tài)的對話的刪除消息為CANCEL消息。
較佳地,所述會話發(fā)起方客戶端發(fā)送給接收方客戶端的信息以及接收到的來自接收方客戶端的信息是經(jīng)有狀態(tài)代理服務(wù)器轉(zhuǎn)發(fā)的。
應(yīng)用本發(fā)明,當(dāng)發(fā)起方的客戶端收到第一個最終響應(yīng)時,為針對該會話的其他掛起的對話設(shè)置一個通用的定時器,在定時器超時之前,發(fā)起方客戶端將按照正常的收到最終響應(yīng)的處理來執(zhí)行對話的刪除過程,不會涉及到掛起對話的處理,當(dāng)定時器超時之后,發(fā)起方客戶端發(fā)送BYE或者CANCEL請求刪除還存在的已掛起的對話。這樣,通過合理的設(shè)置定時器的時長,對接收方處理速度較快的對話,在定時器超時之前就已經(jīng)返回了200 OK最終響應(yīng),發(fā)起方客戶端將按照正常的收到最終響應(yīng)的處理來執(zhí)行對話的刪除過程,不會涉及到掛起對話的處理,而對于需要用戶交互而導(dǎo)致響應(yīng)時間較長的接收方,發(fā)起方客戶端將使用BYE或者CANCEL消息刪除這些對話,這樣在接收方避免了先建立會話又立刻被刪除的情況。應(yīng)用本發(fā)明,不但可以簡化對使用分叉功能的會話的處理和實現(xiàn),還節(jié)省了客戶端和服務(wù)器的大量資源,同時避免了給用戶帶來不舒服的使用感受。本發(fā)明實現(xiàn)簡單,且能夠為運營商的實際運營帶來很多好處和便利。


圖1所示為現(xiàn)有技術(shù)一的處理流程示意圖;圖2所示為現(xiàn)有技術(shù)二的處理流程示意圖;圖3所示為應(yīng)用本發(fā)明會話發(fā)起方接收到最終響應(yīng)后的處理流程示意圖;圖4所示為應(yīng)用本發(fā)明會話發(fā)起方判斷定時器超時后的處理流程示意圖;圖5所示為應(yīng)用本發(fā)明的處理流程示意圖。
具體實施例方式
下面結(jié)合附圖對本發(fā)明再做進一步地詳細說明。
本發(fā)明的思路是當(dāng)發(fā)起方的客戶端收到第一個最終響應(yīng)時,為針對該會話的其他掛起的對話設(shè)置一個通用的定時器,在定時器超時之前,發(fā)起方客戶端將按照正常的收到最終響應(yīng)的處理來執(zhí)行對話的刪除過程,不會涉及到掛起對話的處理,當(dāng)定時器超時之后,發(fā)起方客戶端發(fā)送BYE或者CANCEL請求刪除還存在的已掛起的對話。
圖3所示為應(yīng)用本發(fā)明會話發(fā)起方接收到最終響應(yīng)后的處理流程示意圖。
步驟301,當(dāng)會話發(fā)起方客戶端收到一個針對INVITE請求的最終響應(yīng)200 OK消息后,首先判斷這個最終響應(yīng)是否是針對該會話請求收到的第一個最終響應(yīng),如果是,執(zhí)行步驟302~303,否則執(zhí)行步驟304~305;步驟302~303,啟動一個定時器T,該定時器對該會話的所有對話有效;同時針對該200 OK響應(yīng),構(gòu)造ACK消息作為確認,建立會話;步驟304~305,先對收到的200 OK消息作出確認,然后立刻構(gòu)造BYE消息刪除剛剛建立的會話,這是因為,如果收到的針對INVITE請求的最終響應(yīng)200 OK消息不是該客戶端收到的第一個最終響應(yīng),說明針對INVITE請求已建立起了會話,因此這個200 OK對應(yīng)的會話需要被刪除。
圖4所示為應(yīng)用本發(fā)明會話發(fā)起方判斷定時器超時后的處理流程示意圖。當(dāng)定時器T超時之后,客戶端首先檢查針對該INVITE請求建立的對話中是否還有掛起的且未處理的對話,如果有,構(gòu)造BYE或者CANCEL消息,刪除這些掛起的對話,然后照正常流程執(zhí)行后續(xù)處理;如果沒有,則客戶端繼續(xù)按照正常流程執(zhí)行后續(xù)處理。
針對圖3和圖4,需要說明幾個問題。
首先是定時器T的定時長度的選取。根據(jù)對接收方客戶端處理會話請求的分析,一個接收方客戶端存在兩種應(yīng)答方式,一種是不需要用戶干預(yù)的自動應(yīng)答方式,一般針對一些以機器或者設(shè)備作為客戶端的情況,或者用戶在終端設(shè)備上設(shè)置了由終端設(shè)備執(zhí)行自動應(yīng)答的情況,這種應(yīng)答因為是設(shè)備自動執(zhí)行的,因此處理速度很快,一般可以在幾秒之內(nèi)處理完;另一種是需要用戶進行交互之后才可以應(yīng)答的非自動應(yīng)答方式,這種方法普遍用于各種需要用戶進行決策的情況下,因為存在人機交互過程,或者人的選擇和決定過程,因此返回最終應(yīng)答所需的處理時間較長,通常至少需要十多秒。經(jīng)上述分析,定時器T的定時長度設(shè)置為十秒以內(nèi)且接近十秒的時間,即大于等于自動應(yīng)答設(shè)備所需的應(yīng)答時間,同時小于等于非自動應(yīng)答設(shè)備所需的應(yīng)答時間。當(dāng)然,這里給出的定時器時長只是一個經(jīng)過分析之后的建議值,隨著設(shè)備處理能力的提高,這個定時器時長的設(shè)置也會不斷發(fā)生變化,因此,具體實現(xiàn)時,這個值應(yīng)該是運營商通過實驗和測試確定的一個實踐值。
由于定時器的定時長度是經(jīng)分析以及通過多次實驗和測試后得到的,因此,通過定時時間可以將兩種應(yīng)答方式的處理情況區(qū)分開,且保證兩種應(yīng)答方式之間不會發(fā)生沖突,即不會發(fā)生定時器T超時之后,還有自動應(yīng)答的最終響應(yīng)沒有收到的情況,同時也不會發(fā)生定時器T超時之前,用戶已經(jīng)完成了和終端設(shè)備的交互過程,返回了最終響應(yīng)的情況。
當(dāng)然,應(yīng)用本發(fā)明的處理方法,對接收方?jīng)]有任何限制,其可以既包含自動應(yīng)答設(shè)備又包含非自動應(yīng)答設(shè)備,還可以僅由自動應(yīng)答設(shè)備組成,或者僅由非自動應(yīng)答設(shè)備組成。
其次,當(dāng)定時器超時之后,會話發(fā)起方的客戶端可以使用BYE消息刪除掛起的對話,也可以使用CANCEL消息。BYE消息可以刪除已經(jīng)建立的會話,也可以刪除掛起的對話,即兩種情況的處理都可以適用;CANCEL請求則只用來刪除掛起的對話,由于在本發(fā)明所示的處理過程中只涉及到刪除掛起的對話,因此這兩種消息都可以使用。
圖5所示為應(yīng)用本發(fā)明的處理流程示意圖。在本流程中,客戶端A是發(fā)起會話請求的客戶端,接收方簽約了分叉功能,即接收方的目的客戶端為客戶端B、C和D,代理服務(wù)器(Proxy Server)是一個有狀態(tài)的代理服務(wù)器,具體流程如下步驟501,客戶端A發(fā)送邀請(INVITE)請求給代理服務(wù)器;步驟502a、502b、502c,代理服務(wù)器根據(jù)接收方的簽約信息,執(zhí)行分叉功能,復(fù)制INVITE請求,分別轉(zhuǎn)發(fā)給客戶端B、客戶端C和客戶端D;
步驟503a、503b、503c,收到INVITE請求的客戶端B、C和D分別對INVITE請求做出臨時響應(yīng),分別返回183(Session Progress會話進行中)響應(yīng)給代理服務(wù)器;步驟504a、504b、504c,代理服務(wù)器分別轉(zhuǎn)發(fā)收到的183響應(yīng)給客戶端A;步驟505a、505b、505c,客戶端A發(fā)送PRACK給代理服務(wù)器,用于確認收到的183響應(yīng);步驟506a、506b、506c,代理服務(wù)器分別轉(zhuǎn)發(fā)收到的PRACK消息給客戶端B、客戶端C和客戶端D;步驟507a、507b、507c,客戶端B、C和D對收到PRACK作出響應(yīng),分別返回200 OK給代理服務(wù)器;步驟508a、508b、508c,代理服務(wù)器分別轉(zhuǎn)發(fā)收到的200 OK消息給客戶端A;步驟509,客戶端B完成了媒體協(xié)商和資源預(yù)留,返回一個針對INVITE的最終響應(yīng)200 OK給代理服務(wù)器;步驟510,代理服務(wù)器將這個最終響應(yīng)轉(zhuǎn)發(fā)給客戶端A;客戶端判斷出其為針對INVEITE請求收到的第一個最終響應(yīng)后,啟動定時器T,然后再執(zhí)行步驟511;步驟511,客戶端A返回ACK消息給代理服務(wù)器,確認收到最終響應(yīng)200 OK;步驟512,代理服務(wù)器轉(zhuǎn)發(fā)ACK消息給對應(yīng)的客戶端B;此時,客戶端A根據(jù)協(xié)商成功的媒體描述分配所需的資源,開始向客戶端B傳輸數(shù)據(jù);步驟513,在定時器T超時之前,客戶端C完成了媒體協(xié)商和資源預(yù)留,返回一個針對INVITE的最終響應(yīng)200 OK給代理服務(wù)器;步驟514,代理服務(wù)器將這個最終響應(yīng)轉(zhuǎn)發(fā)給客戶端A;步驟515,客戶端A返回ACK消息給代理服務(wù)器,確認收到最終響應(yīng)200 OK;步驟516,代理服務(wù)器轉(zhuǎn)發(fā)ACK消息給對應(yīng)的客戶端C;步驟517,因為客戶端A已經(jīng)和客戶端B建立了會話,因此,A立刻發(fā)起針對這些后續(xù)對話的刪除過程,發(fā)送BYE請求給代理服務(wù)器;步驟518,代理服務(wù)器轉(zhuǎn)發(fā)BYE消息給對應(yīng)的客戶端C;步驟519,客戶端C收到BYE之后執(zhí)行刪除對話,釋放資源等操作,然后返回200 OK作為刪除對話執(zhí)行成功的響應(yīng);步驟520,代理服務(wù)器轉(zhuǎn)發(fā)這個200 OK響應(yīng)給客戶端A,至此,A處完成了和C之間的對話的刪除過程;步驟521,當(dāng)客戶端A判斷出定時器T超時后,發(fā)現(xiàn)針對這個INVITE請求建立的會話中還有一個對話被掛起,則發(fā)送BYE消息給代理服務(wù)器,執(zhí)行該對話的刪除過程;步驟522,代理服務(wù)器轉(zhuǎn)發(fā)BYE消息給對應(yīng)的客戶端D;步驟523,客戶端D收到BYE之后執(zhí)行刪除對話,釋放資源等操作,然后返回200 OK作為刪除對話執(zhí)行成功的響應(yīng);步驟524,代理服務(wù)器轉(zhuǎn)發(fā)這個200 OK響應(yīng)給客戶端A,至此,客戶端A處完成了和客戶端D之間的對話的刪除過程。
在上述步驟521中,當(dāng)客戶端A判斷出定時器T超時后,發(fā)現(xiàn)針對這個INVITE請求建立的會話中還有一個對話被掛起,也可以發(fā)送CANCEL消息給代理服務(wù)器,執(zhí)行該對話的刪除過程。相應(yīng)地,代理服務(wù)器轉(zhuǎn)發(fā)CANCEL消息給客戶端A,由客戶端A繼續(xù)執(zhí)行后續(xù)操作。
以上所述僅為本發(fā)明的較佳實施例而已,并不用以限制本發(fā)明,凡在本發(fā)明的精神和原則之內(nèi),所作的任何修改、等同替換、改進等,均應(yīng)包含在本發(fā)明的保護范圍之內(nèi)。
權(quán)利要求
1.一種處理分叉業(yè)務(wù)的方法,其特征在于,該方法包括以下步驟a、會話發(fā)起方客戶端接收到來自接收方客戶端的最終響應(yīng)后,判斷該最終響應(yīng)是否為針對會話請求INVITE收到的第一個最終響應(yīng),如果是,則啟動一個對該會話的所有對話均有效的定時器,同時構(gòu)造并發(fā)送針對該最終響應(yīng)的確認信息,建立會話,之后執(zhí)行步驟c,否則執(zhí)行步驟b;b、直接構(gòu)造并發(fā)送針對該最終響應(yīng)的確認信息,然后構(gòu)造并發(fā)送刪除消息刪除本步驟中建立的會話,之后執(zhí)行步驟c;c、會話發(fā)起方客戶端判斷定時器的定時時間是否超時,如果是,執(zhí)行步驟d,否則判斷是否收到最終響應(yīng),如果是,執(zhí)行步驟a,否則重復(fù)執(zhí)行步驟c;d、構(gòu)造并發(fā)送刪除消息刪除本會話中處于掛起狀態(tài)的對話后,按照正常流程繼續(xù)后續(xù)處理。
2.根據(jù)權(quán)利要求1所述的方法,其特征在于,步驟c所述會話發(fā)起方客戶端判斷出定時器的定時時間超時后,進一步包括,判斷當(dāng)前是否還存在未處理的已掛起的對話,如果存在,再執(zhí)行步驟d,否則按照正常流程繼續(xù)后續(xù)處理。
3.根據(jù)權(quán)利要求1或2所述的方法,其特征在于,所述接收方客戶端包括自動應(yīng)答設(shè)備和非自動應(yīng)答設(shè)備,或者所述接收方客戶端僅包括自動應(yīng)答設(shè)備,或者所述接收方客戶端僅包括非自動應(yīng)答設(shè)備。
4.根據(jù)權(quán)利要求3所述的方法,其特征在于,所述定時器的定時時間長度大于等于自動應(yīng)答設(shè)備所需的應(yīng)答時間,且小于等于非自動應(yīng)答設(shè)備所需的應(yīng)答時間。
5.根據(jù)權(quán)利要求1所述的方法,其特征在于,所述刪除本會話中處于掛起狀態(tài)的對話的刪除消息為BYE消息。
6.根據(jù)權(quán)利要求1所述的方法,其特征在于,所述刪除本會話中處于掛起狀態(tài)的對話的刪除消息為CANCEL消息。
7.根據(jù)權(quán)利要求1所述的方法,其特征在于,所述會話發(fā)起方客戶端發(fā)送給接收方客戶端的信息以及接收到的來自接收方客戶端的信息是經(jīng)有狀態(tài)代理服務(wù)器轉(zhuǎn)發(fā)的。
全文摘要
本發(fā)明提供了一種處理分叉業(yè)務(wù)的方法,關(guān)鍵是,當(dāng)發(fā)起方客戶端收到第一個最終響應(yīng)時,為針對該會話的其它掛起的對話設(shè)置一個通用的定時器,在定時器超時之前,發(fā)起方客戶端將按照正常的收到最終響應(yīng)的處理來執(zhí)行對話的刪除過程,不會涉及到掛起對話的處理,當(dāng)定時器超時之后,發(fā)起方客戶端發(fā)送BYE或者CANCEL請求刪除還存在的已掛起的對話。通過合理的設(shè)置定時器的時長,避免了先建立會話又立刻被刪除的情況。應(yīng)用本發(fā)明,不但可以簡化對使用分叉功能的會話的處理和實現(xiàn),還節(jié)省了客戶端和服務(wù)器的大量資源,同時避免了給用戶帶來不舒服的使用感受。
文檔編號H04L12/54GK1756256SQ20041008107
公開日2006年4月5日 申請日期2004年9月30日 優(yōu)先權(quán)日2004年9月30日
發(fā)明者武亞娟 申請人:華為技術(shù)有限公司
網(wǎng)友詢問留言 已有0條留言
  • 還沒有人留言評論。精彩留言會獲得點贊!
1
霸州市| 东乡族自治县| 监利县| 吐鲁番市| 新巴尔虎右旗| 克东县| 荣昌县| 潼关县| 咸阳市| 象州县| 阿合奇县| 雷山县| 奉新县| 元阳县| 永年县| 奈曼旗| 都安| 汉源县| 庆云县| 名山县| 尉犁县| 曲水县| 基隆市| 赫章县| 汉源县| 宣武区| 英山县| 开鲁县| 汕头市| 永登县| 从化市| 科技| 兴义市| 鹿泉市| 阳朔县| 三亚市| 台北县| 即墨市| 扶绥县| 鄢陵县| 闽清县|