專利名稱：一種實現(xiàn)呼叫腿轉(zhuǎn)移的方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信系統(tǒng)中呼叫轉(zhuǎn)移技術(shù)，特別是指一種實現(xiàn)呼叫腿轉(zhuǎn)移的方法。
背景技術(shù)：
在電信網(wǎng)絡開放的業(yè)務體系中，應用服務器對下層復雜的電信網(wǎng)絡能力進行封裝和抽象，提供簡單、開放的業(yè)務能力接口給應用，應用使用開放的業(yè)務能力接口來開發(fā)業(yè)務。
多方呼叫是指一個呼叫中有三個或者三個以上的呼叫方，每個呼叫方稱為一個呼叫腿。在多方呼叫的開放接口中，如parlay API和OSA API，只抽象了增加和釋放呼叫腿的管理功能，而無法實現(xiàn)將一個呼叫腿從一個呼叫轉(zhuǎn)移到另一個呼叫的功能。即如果一個呼叫中的呼叫腿要加入到另外一個呼叫中，只能先斷掉與源呼叫之間的連接，再與目的呼叫建立連接才能實現(xiàn)。這種加入到另外一個呼叫的方式，對于用戶來說，需要斷掉連接重新加入，呼叫腿在源呼叫中的數(shù)據(jù)和狀態(tài)在加入到新呼叫后都發(fā)生變化，因此，這種方式不僅步驟煩瑣，而且許多必要的信息也丟失。
因此，現(xiàn)有的技術(shù)方案無法真正實現(xiàn)呼叫腿轉(zhuǎn)移業(yè)務功能。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明的目的是提供一種實現(xiàn)呼叫腿轉(zhuǎn)移的方法，使應用實現(xiàn)呼叫腿轉(zhuǎn)移的相關(guān)業(yè)務。
一種實現(xiàn)呼叫腿轉(zhuǎn)移的方法包括A.預先設置呼叫腿轉(zhuǎn)移接口，用于將源呼叫中指定呼叫腿轉(zhuǎn)移至目的呼叫，所述呼叫腿轉(zhuǎn)移接口的接口引用參數(shù)為待轉(zhuǎn)移的呼叫腿標識和目的呼叫標識；B.當應用要轉(zhuǎn)移呼叫腿時，根據(jù)待轉(zhuǎn)移的呼叫腿和目的呼叫確定接口引用參數(shù)，然后根據(jù)接口引用參數(shù)調(diào)用所述呼叫腿轉(zhuǎn)移接口，將所述呼叫腿轉(zhuǎn)移到目的呼叫。
將所述呼叫腿轉(zhuǎn)移到目的呼叫進一步包括B1、應用通知源呼叫將呼叫腿轉(zhuǎn)移到目的呼叫；B2、源呼叫斷開該呼叫腿所占用的資源，設置該呼叫腿的呼叫信息，向目的呼叫發(fā)出呼叫腿轉(zhuǎn)移請求；B3、目的呼叫收到來自源呼叫的請求后，判斷自身可用資源是否夠用，如果夠用，則為該呼叫腿分配資源，呼叫腿轉(zhuǎn)移成功，否則，呼叫腿轉(zhuǎn)移失敗。
在步驟B3之后，該方法進一步包括目的呼叫通知應用轉(zhuǎn)移結(jié)果。
所述步驟B2進一步包括通知所述呼叫腿對應的用戶終端，該呼叫腿要轉(zhuǎn)移到目的呼叫中。
步驟B2中所述呼叫信息至少包括呼叫標識、媒體類型、計費策略和終端信息，所述設置該呼叫腿的呼叫信息是僅將呼叫信息中所屬源呼叫標識更改為目的呼叫標識。
所述源呼叫和目的呼叫為多方呼叫。
所述呼叫腿轉(zhuǎn)移接口是在原有Parlay規(guī)范的多方呼叫IpMultiPartyCall接口中進一步增加呼叫腿轉(zhuǎn)移功能而設置。
本發(fā)明通過向應用提供呼叫轉(zhuǎn)移接口，當需要轉(zhuǎn)移呼叫腿時，簡單調(diào)用該接口即可實現(xiàn)呼叫腿轉(zhuǎn)移，對應用來說，開發(fā)具有呼叫腿轉(zhuǎn)移功能特性的業(yè)務方便、簡單。


圖1為本發(fā)明開放呼叫轉(zhuǎn)移接口的示意圖；圖2實現(xiàn)本發(fā)明方法的流程示意圖；
圖3為呼叫腿轉(zhuǎn)移接口提供方法的具體流程示意圖；圖4為以基于web的多方聊天業(yè)務為例進行呼叫腿轉(zhuǎn)移示意圖；圖5為應用本發(fā)明方法的具體流程示意圖。
具體實施例方式
為使本發(fā)明的目的、技術(shù)方案、及優(yōu)點更加清楚明白，以下參照附圖并舉實施例，對本發(fā)明進一步詳細說明。
本發(fā)明的方法是將呼叫腿轉(zhuǎn)移功能抽象的開放接口提供給應用，應用通過調(diào)用該接口可以實現(xiàn)呼叫腿轉(zhuǎn)移等一些具有相關(guān)功能特性的業(yè)務，如呼叫保持，呼叫轉(zhuǎn)接等。
參見圖1所示，本發(fā)明提供接口的網(wǎng)絡結(jié)構(gòu)可以分為三層上層、中間層和下層。其中，上層為業(yè)務應用層，中間層為能力抽象層，下層為電信網(wǎng)絡層。能力抽象層將下層電信網(wǎng)絡能力進行抽象，封裝成多個獨立的功能，如呼叫控制、消息、移動管理等，這些功能提供相應的接口給應用，應用調(diào)用不同的接口使用下層的網(wǎng)絡能力得到電信業(yè)務。每個獨立功能由一些小功能組成，本發(fā)明提供的呼叫腿轉(zhuǎn)移的功能屬于呼叫控制功能中的一個小功能。
參見圖2所示，實現(xiàn)本發(fā)明的方法包括以下步驟步驟201、預先設置呼叫腿轉(zhuǎn)移接口，用于將源呼叫中指定的呼叫腿轉(zhuǎn)移至目的呼叫，所述呼叫腿轉(zhuǎn)移接口的接口引用參數(shù)為待轉(zhuǎn)移的呼叫腿標識和目的呼叫標識，輸出參數(shù)為轉(zhuǎn)移結(jié)果；步驟202、當應用要轉(zhuǎn)移呼叫腿時，根據(jù)待轉(zhuǎn)移的呼叫腿和目的呼叫確定接口引用參數(shù)，然后根據(jù)接口引用參數(shù)調(diào)用所述呼叫腿轉(zhuǎn)移接口，使呼叫腿斷開占用源呼叫中的資源，為呼叫腿分配目的呼叫中的資源，將呼叫腿轉(zhuǎn)移到目的呼叫，并且向應用返回轉(zhuǎn)移結(jié)果。
參見圖3所述，呼叫腿轉(zhuǎn)移接口提供的方法包括以下步驟步驟301、應用通知源呼叫要將某呼叫腿轉(zhuǎn)移到目的呼叫；
步驟302、源呼叫斷開該呼叫腿所占用的資源，設置該呼叫腿的呼叫信息，然后向目的呼叫發(fā)出將所述呼叫腿轉(zhuǎn)移的請求。這里，呼叫信息至少包括呼叫標識、媒體類型、計費策略和終端信息，該呼叫腿的呼叫信息主要是通過更改呼叫信息中所屬呼叫標識來設置，呼叫信息中的媒體類型、計費策略和用戶終端信息可以保持不變。
步驟303、目的呼叫收到來自源呼叫方的請求后，判斷自身可用資源是否夠用，如果夠用，則為該呼叫腿分配資源，呼叫腿轉(zhuǎn)移成功，否則，呼叫腿轉(zhuǎn)移失敗。
步驟304、目的呼叫將轉(zhuǎn)移結(jié)果通知源呼叫，源呼叫再將該轉(zhuǎn)移結(jié)果通知應用。
從上述過程可以看出，呼叫腿轉(zhuǎn)移的方法是斷開呼叫腿所占用源呼叫中的資源，并且將該呼叫腿的呼叫信息中涉及源呼叫的信息更改為目的呼叫信息，原有狀態(tài)和數(shù)據(jù)保持不變。然后為該呼叫腿分配目的呼叫中的資源，從而使該呼叫腿在源呼叫中懸置，轉(zhuǎn)移到目的呼叫中，與目的呼叫中每個呼叫方可以進行通信。當然，在所述步驟302中，可以通知所述呼叫腿對應的用戶終端，該呼叫腿轉(zhuǎn)移到目的呼叫中，使用戶終端及時了解自身所處的呼叫環(huán)境。而且，上面所述資源可以為信道資源。當然，呼叫腿轉(zhuǎn)移接口可以通過新定義來實現(xiàn)，也可以在原有接口中增加呼叫腿轉(zhuǎn)移功能來實現(xiàn)。
本發(fā)明可以直接定義一個開放接口IrpMultiPartyCall，包括destCallinIpMultiPartyCall和legIDTpCallLegIdentifier參數(shù)，通過該接口提供呼叫腿轉(zhuǎn)移的方法。其中，destCallin IpMultiPartyCall，為呼叫腿要轉(zhuǎn)移到的目的呼叫的接口引用；legIDTpCallLegIdentifier，為要轉(zhuǎn)移的呼叫腿標識，包括呼叫腿的ID和呼叫腿的接口引用。并且，調(diào)用該接口后返回一個布爾型的數(shù)值，表示呼叫腿轉(zhuǎn)移成功與否，返回值為true，表示成功；返回值為false，表示失敗。
本發(fā)明還可以在Parlay API多方呼叫的IpMultipartyCall接口中增加呼叫腿轉(zhuǎn)移的方法來實現(xiàn)呼叫腿從一個呼叫轉(zhuǎn)移到另一個呼叫?？梢园╠estCallin IpMultiPartyCall和legIDTpCallLegIdentifier參數(shù)。其中，destCallin IpMultiPartyCall，為呼叫腿要轉(zhuǎn)移到的目的呼叫的接口引用；legIDTpCallLegIdentifier，要轉(zhuǎn)移的呼叫腿標識，包括呼叫腿的ID和呼叫腿的接口引用。并且，該方法返回一個布爾型的數(shù)值，表示呼叫腿轉(zhuǎn)移成功與否，返回值為true，表示成功；返回值為false，表示失敗。
需要強調(diào)的是，要實現(xiàn)呼叫腿移動功能，必須具備兩個前提條件一是需要移動到新的呼叫的呼叫腿預先要斷開源呼叫分配的資源連接；二是在呼叫腿移動前新的目的呼叫已經(jīng)建立。
下面結(jié)合圖4，以基于web的多方聊天業(yè)務來詳細說明本發(fā)明方法的應用。
基于web的多方聊天業(yè)務主要是提供一個web頁面，通過該頁面可以創(chuàng)建多方呼叫，也可以看到當前存在的所有呼叫以及該呼叫中存在的呼叫者。
參見圖4所示，28800001和2880002為呼叫標識，分別對應兩個呼叫。在圖4中可以看出，呼叫28800001進行了10分20秒，該呼叫中有張三、李四、王五和秦七共四個人，他們中每個人都被稱作呼叫中的一方，在呼叫模型中呼叫中的每一方稱作一個呼叫腿。在呼叫2880002中共有三方，分別為陳八、趙九和韓十，該呼叫進行了5分鐘。
參見圖4左邊部分所示，在呼叫腿移動前，在呼叫28800001中，張三的號碼為2870001，已進行的通話時長共9分鐘，目前處于連接狀態(tài)；李四的號碼為2870002，已進行的通話時長共2分鐘，目前處于連接狀態(tài)；王五的號碼為2870003，已進行的通話時長共3分鐘，目前處于連接狀態(tài)；秦七的號碼為2870004，已進行的通話時長為5分鐘，目前處于連接狀態(tài)。在呼叫28800002中，陳八的號碼為2870004，已進行的通話時長共5分鐘，目前處于連接狀態(tài)；趙九的號碼2870002，已進行的通話時長共2分鐘，目前處于連接狀態(tài)；韓十的號碼為2870002，已進行的通話時長共5分鐘，目前處于連接狀態(tài)。
在呼叫過程中，李四在web頁面上，或者是有權(quán)限的其他人拖動李四的呼叫腿，從呼叫28800001移動到呼叫28800002中。這相當于李四或其它有權(quán)限的人發(fā)出呼叫轉(zhuǎn)移請求，應用將調(diào)用呼叫轉(zhuǎn)移接口，完成呼叫腿轉(zhuǎn)移。
參見圖4右邊部分所示，在呼叫腿移動后，呼叫28800001中李四處于保持(Hold)狀態(tài)，其呼叫腿被懸置，不能再和該呼叫中的其他三人進行通話。李四加入到呼叫28800002中，可以和陳八、趙九和韓十進行通話。
當然，當李四結(jié)束在28800002中的通話后，也可以將呼叫腿重新移回呼叫28800001，由于在李四離開期間，其呼叫數(shù)據(jù)保持不變，比如媒體類型、計費信息等，因此李四可以繼續(xù)和張三、王五、秦七進行通話。
另外，當28800001中的呼叫方李四代表的呼叫腿處于保持(Hold)狀態(tài)后，李四可以隨時釋放該呼叫腿，也就是說李四可以離開該呼叫。而后，如果李四還想要加入28800001呼叫，那么李四就要重新建立新的連接。
參見圖5所示，基于圖3所述的呼叫腿轉(zhuǎn)移業(yè)務，進行呼叫的具體過程如下步驟501～504、首先用戶A通過web觸發(fā)業(yè)務應用(Application)發(fā)起一個多方呼叫請求；應用創(chuàng)建一個多方呼叫，并且將MPCC Call1作為該呼叫的標識；然后MPCC Call1根據(jù)用戶A設定的呼叫方號碼創(chuàng)建呼叫腿，并且將callLeg1作為該呼叫腿的標識。
步驟505～508、用戶B通過web觸發(fā)業(yè)務應用Application發(fā)起另一個多方呼叫；應用創(chuàng)建一個多方呼叫，并且利用MPCC Call2來標識該呼叫；MPCC Call2根據(jù)用戶B設定的呼叫方號碼來創(chuàng)建呼叫腿；并且使用callLeg2來標識該呼叫腿。
步驟509～510、在呼叫進行過程中，用戶A通過web拖動呼叫腿callLeg1，將其從呼叫MPCC call1拖到MPCC call2；然后應用Application通知MPCCCall1將呼叫腿callLeg1移到呼叫MPCC call2。
步驟511～512、MPCC call1收到該通知后，根據(jù)應用傳送的moveLeg中的legIDTpCallLegIdentifier找到要移動的呼叫腿，通知callLeg1對應的呼叫方用戶，該呼叫腿將由呼叫MPCC call1轉(zhuǎn)移到MPCC call2；然后MPCCcall1斷開呼叫MPCC call1為callLeg1分配的資源。此后，callLeg1已經(jīng)被懸置，無法和MPCC call1中的其他呼叫方進行通訊。
步驟513、然后，MPCC call1通知callLeg1將其所屬的呼叫信息進行更改，即將呼叫腿callLeg1中關(guān)于MPCC call1的一些信息更改為MPCC call2的信息，如呼叫的標識和接口引用等。當然，呼叫腿callLeg1中的其他信息保持不變，如呼叫的媒體類型，計費策略，終端信息等。
步驟514、MPCC call1根據(jù)應用傳送的moveLeg中destCallinIpMultiPartyCall找到呼叫腿移動的目的呼叫MPCC call2，然后給MPCC call2發(fā)送通知，請求將呼叫腿callLeg1加入到MPCC call2呼叫中，并將呼叫腿的標識的引用傳給MPCC call2。
步驟515～516、在MPCC call2收到來自MPCC call1的請求后，為callLeg1分配資源，MPCC call2將執(zhí)行結(jié)果，如True或False，通知MPCCcall。在資源分配成功后，呼叫腿callLeg1可以和MPCC call2呼叫中的其他呼叫腿進行通訊。當然，資源分配的成功與否與MPCC call2中的可用資源是否夠用以及MPCC call2是否愿意接受該呼叫腿有關(guān)。
步驟517、MPCC call1收到來自MPCC call2的執(zhí)行結(jié)果后，判斷該呼叫腿是否轉(zhuǎn)移成功，若轉(zhuǎn)移成功，向應用返回true，如果轉(zhuǎn)移失敗，向應用返回false。
以上所述僅為本發(fā)明的較佳實施例而已，并不用以限制本發(fā)明，凡在本發(fā)明的精神和原則之內(nèi)，所作的任何修改、等同替換、改進等，均應包含在本發(fā)明的保護范圍之內(nèi)。
權(quán)利要求
1.一種實現(xiàn)呼叫腿轉(zhuǎn)移的方法，其特征在于，該方法包括以下步驟A.預先設置呼叫腿轉(zhuǎn)移接口，用于將源呼叫中指定呼叫腿轉(zhuǎn)移至目的呼叫，所述呼叫腿轉(zhuǎn)移接口的接口引用參數(shù)為待轉(zhuǎn)移的呼叫腿標識和目的呼叫標識；B.當應用要轉(zhuǎn)移呼叫腿時，根據(jù)待轉(zhuǎn)移的呼叫腿和目的呼叫確定接口引用參數(shù)，然后根據(jù)接口引用參數(shù)調(diào)用所述呼叫腿轉(zhuǎn)移接口，將所述呼叫腿轉(zhuǎn)移到目的呼叫。
2.根據(jù)權(quán)利要求1所述的方法，其特征在于，將所述呼叫腿轉(zhuǎn)移到目的呼叫進一步包括B1、應用通知源呼叫將呼叫腿轉(zhuǎn)移到目的呼叫；B2、源呼叫斷開該呼叫腿所占用的資源，設置該呼叫腿的呼叫信息，向目的呼叫發(fā)出呼叫腿轉(zhuǎn)移請求；B3、目的呼叫收到來自源呼叫的請求后，判斷自身可用資源是否夠用，如果夠用，則為該呼叫腿分配資源，呼叫腿轉(zhuǎn)移成功，否則，呼叫腿轉(zhuǎn)移失敗。
3.根據(jù)權(quán)利要求2所述的方法，其特征在于，在步驟B3之后，該方法進一步包括目的呼叫通知應用轉(zhuǎn)移結(jié)果。
4.根據(jù)權(quán)利要求2所述的方法，其特征在于，所述步驟B2進一步包括通知所述呼叫腿對應的用戶終端，該呼叫腿要轉(zhuǎn)移到目的呼叫中。
5.根據(jù)權(quán)利要求2所述的方法，其特征在于，步驟B2中所述呼叫信息至少包括呼叫標識、媒體類型、計費策略和終端信息，所述設置該呼叫腿的呼叫信息是僅將呼叫信息中所屬源呼叫標識更改為目的呼叫標識。
6.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述源呼叫和目的呼叫為多方呼叫。
7.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述呼叫腿轉(zhuǎn)移接口是在原有Parlay規(guī)范的多方呼叫IpMultiPartyCall接口中進一步增加呼叫腿轉(zhuǎn)移功能而設置。
全文摘要
本發(fā)明公開了一種實現(xiàn)呼叫腿轉(zhuǎn)移的方法，該方法包括A.預先設置呼叫腿轉(zhuǎn)移接口，用于將源呼叫中指定呼叫腿轉(zhuǎn)移至目的呼叫，所述呼叫腿轉(zhuǎn)移接口的接口引用參數(shù)為待轉(zhuǎn)移的呼叫腿標識和目的呼叫標識；B.當應用要轉(zhuǎn)移呼叫腿時，根據(jù)待轉(zhuǎn)移的呼叫腿和目的呼叫確定接口引用參數(shù)，然后根據(jù)接口引用參數(shù)調(diào)用所述呼叫腿轉(zhuǎn)移接口，將所述呼叫腿轉(zhuǎn)移到目的呼叫。本發(fā)明向應用提供呼叫轉(zhuǎn)移接口，不需要過多處理，通過簡單的調(diào)用即可實現(xiàn)呼叫腿轉(zhuǎn)移，對應用來說，開發(fā)具有呼叫腿轉(zhuǎn)移功能特性的業(yè)務方便、簡單。
文檔編號H04Q3/00GK1567941SQ0313749
公開日2005年1月19日 申請日期2003年6月25日 優(yōu)先權(quán)日2003年6月25日
發(fā)明者苗彩霞, 劉昊, 梅少杰, 李彥, 祝勇 申請人:華為技術(shù)有限公司