專利名稱：一種實現(xiàn)支持多媒體業(yè)務(wù)的軟交換呼叫處理系統(tǒng)及方法
技術(shù)領(lǐng)域：
本發(fā)明涉及多媒體業(yè)務(wù)的實現(xiàn)技術(shù)，特別涉及一種實現(xiàn)支持多媒體業(yè)務(wù)的軟交換呼叫處理系統(tǒng)及方法。
背景技術(shù)：
IP語音(VoIP)技術(shù)作為一種新興的語音通信技術(shù)已顯示了越來越重要的地位。盡管VoIP網(wǎng)絡(luò)的建設(shè)目前初具規(guī)模，VoIP技術(shù)也日臻成熟，但是目前的VoIP網(wǎng)絡(luò)僅限于提供基本的語音傳輸服務(wù)，還不能以統(tǒng)一的方式實現(xiàn)同時提供語音、圖像和數(shù)據(jù)的多媒體業(yè)務(wù)，這限制了VoIP技術(shù)的發(fā)展和推廣。能夠同時提供語音、圖像和數(shù)據(jù)的多媒體業(yè)務(wù)已成為未來VoIP發(fā)展的一個重要方向。
軟交換(Softswitch)作為順應(yīng)VoIP發(fā)展需要的新型交換技術(shù)，主要應(yīng)用于分組交換網(wǎng)，體現(xiàn)了呼叫處理與承載傳輸分離的思想，是實現(xiàn)新一代IP語音、多媒體和數(shù)據(jù)通信的核心技術(shù)。
軟交換作為VoIP網(wǎng)絡(luò)中的核心控制實體，它獨立于底層承載協(xié)議，主要完成呼叫控制、媒體網(wǎng)關(guān)接入控制、資源分配、協(xié)議處理、路由、認(rèn)證、計費等主要功能。此外，軟交換需要支持多種信令，至少包括ISUP、SIP、H.323和MGCP等協(xié)議，還要能夠?qū)崿F(xiàn)這些信令之間的轉(zhuǎn)換。
簡單地說，軟交換要能夠提供類似傳統(tǒng)程控交換機的“呼叫控制”功能，但傳統(tǒng)程控交換機的“呼叫控制”功能是和“業(yè)務(wù)控制”結(jié)合在一起的，軟交換提供的呼叫控制功能是與各種業(yè)務(wù)控制功能分離的，更能滿足在下一代網(wǎng)絡(luò)(NGN)中為用戶快速提供新業(yè)務(wù)的需要。
作為一項新興的技術(shù)，雖然目前支持基本語音業(yè)務(wù)的軟交換技術(shù)正逐漸成熟，但是支持多媒體解決方案的軟交換還處于研究起步階段。這是由于語音業(yè)務(wù)與多媒體業(yè)務(wù)在控制方式和業(yè)務(wù)復(fù)雜度方面有很大的不同。一般情況下，語音業(yè)務(wù)的控制方式比較簡單，在呼叫控制過程中，只涉及通話雙方、單一承載；而多媒體業(yè)務(wù)在呼叫控制過程中，同時涉及多方、多承載，在IP網(wǎng)中還具有呼叫控制與媒體承載連接相分離的特點，這使得多媒體業(yè)務(wù)的控制操作相對于語音業(yè)務(wù)要復(fù)雜的多。因此軟交換作為VoIP網(wǎng)絡(luò)中的核心控制實體，要實現(xiàn)對多媒體業(yè)務(wù)的支持，就需要提供能夠充分表達多媒體業(yè)務(wù)處理特點的多媒體呼叫處理系統(tǒng)。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明的一個主要目的在于提供一種實現(xiàn)支持多媒體業(yè)務(wù)的軟交換呼叫處理系統(tǒng)，使得VoIP網(wǎng)絡(luò)能夠以統(tǒng)一的方式同時提供語音、圖像和數(shù)據(jù)的多媒體業(yè)務(wù)。
本發(fā)明的另一個主要目的在于提供一種實現(xiàn)支持多媒體業(yè)務(wù)的軟交換呼叫處理方法，使得軟交換能夠以統(tǒng)一的控制方式同時提供包含語音、圖像和數(shù)據(jù)的多媒體業(yè)務(wù)。
為達到上述目的一個方面，本發(fā)明提供了一種實現(xiàn)支持多媒體業(yè)務(wù)的軟交換呼叫處理系統(tǒng)，設(shè)置在軟交換實體中，其特征在于，該系統(tǒng)包含呼叫控制子系統(tǒng)和承載控制子系統(tǒng)；呼叫控制子系統(tǒng)根據(jù)發(fā)端用戶的呼叫請求，向收端用戶發(fā)起呼叫請求，對呼叫的接續(xù)過程進行控制，在發(fā)端用戶與收端用戶建立呼叫連接后，啟動承載控制子系統(tǒng)；承載控制子系統(tǒng)根據(jù)呼叫請求進行媒體類型協(xié)商，選擇相應(yīng)的媒體承載通道并控制選定的媒體承載通道進行媒體數(shù)據(jù)信息傳輸。
其中，所述的呼叫控制子系統(tǒng)可以包含發(fā)端呼叫控制模塊和收端呼叫控制模塊；發(fā)端呼叫控制模塊接收發(fā)端用戶的呼叫請求，進行初步處理，并將該呼叫請求發(fā)送給收端呼叫控制模塊；收端呼叫控制模塊向收端用戶發(fā)送呼叫請求，并將收端用戶在不同階段的接續(xù)狀態(tài)指示返回給發(fā)端呼叫控制模塊。
所述的發(fā)端呼叫控制模塊可以包含發(fā)端空閑狀態(tài)處理單元，其接收發(fā)端用戶的呼叫請求，并將該呼叫信息轉(zhuǎn)發(fā)給發(fā)端試呼鑒權(quán)單元；發(fā)端試呼鑒權(quán)單元，根據(jù)發(fā)端用戶標(biāo)識和業(yè)務(wù)輪廓檢查發(fā)端用戶的權(quán)限，證實發(fā)端用戶是否有權(quán)和有能力進行此類型的呼叫，并將鑒權(quán)檢查結(jié)果發(fā)送給收集并分析信息單元；收集并分析信息單元，從呼叫請求中收集初始信息包，并根據(jù)編號計劃判定呼叫類型以及執(zhí)行地址翻譯，確定收端用戶地址，將分析結(jié)果發(fā)送給鑒權(quán)呼叫建立單元；鑒權(quán)呼叫建立單元，驗證發(fā)端用戶是否具有發(fā)起本次呼叫連接的權(quán)利，并將驗證結(jié)果發(fā)送給發(fā)送呼叫單元；發(fā)送呼叫單元，將通過鑒權(quán)呼叫建立單元驗證的發(fā)端用戶的呼叫請求發(fā)送到收端呼叫控制模塊；發(fā)端提醒單元，接收收端呼叫控制模塊發(fā)送的收端用戶振鈴的接續(xù)指示，返回給發(fā)端用戶，等待收端用戶應(yīng)答接續(xù)指示；發(fā)端呼叫建立單元，接收收端呼叫控制模塊發(fā)送的收端用戶應(yīng)答的接續(xù)指示，返回給發(fā)端用戶，在發(fā)端用戶和收端用戶之間建立穩(wěn)態(tài)的呼叫連接關(guān)系，并對后續(xù)的呼叫控制過程進行監(jiān)視。
所述的發(fā)端呼叫控制模塊可以進一步包含發(fā)端呼叫例外處理單元，其在發(fā)端試呼鑒權(quán)未通過或收集到無效信息或鑒權(quán)呼叫建立失敗或呼叫發(fā)送失敗或收端用戶拒絕接續(xù)或收端用戶無應(yīng)答或呼叫建立出故障時，終止發(fā)端后續(xù)呼叫事務(wù)，并返回到發(fā)端呼叫空閑狀態(tài)處理單元。
所述的收端呼叫控制模塊可以包含
收端空閑狀態(tài)處理單元，其接收發(fā)端呼叫控制模塊的發(fā)送呼叫單元轉(zhuǎn)發(fā)的發(fā)端用戶的呼叫請求，并將該呼叫請求轉(zhuǎn)發(fā)給收端試呼鑒權(quán)單元；收端試呼鑒權(quán)單元，檢查收端用戶是否有權(quán)和有能力進行此類型呼叫，并將檢查結(jié)果發(fā)送給顯示呼叫單元；顯示呼叫單元，將通過收端試呼鑒權(quán)單元檢查的來話呼叫通知給收端用戶；收端提醒單元，提醒收端用戶有來話呼叫，并等待收端用戶終端應(yīng)答；收端呼叫建立單元，將收端用戶應(yīng)答的接續(xù)狀態(tài)發(fā)送給呼叫處理系統(tǒng)的發(fā)端呼叫控制模塊，在發(fā)端用戶和收端用戶之間建立穩(wěn)態(tài)的呼叫連接關(guān)系，并對后續(xù)的呼叫控制過程進行監(jiān)視。
所述的收端呼叫控制模塊可以進一步包含收端呼叫例外處理單元，其在收端試呼鑒權(quán)未通過或呼叫顯示故障或收端用戶拒絕接續(xù)或收端用戶無應(yīng)答或呼叫建立出故障時，結(jié)束收端后續(xù)呼叫事務(wù)，并返回到收端呼叫空閑狀態(tài)處理單元。
所述的承載控制子系統(tǒng)可以包含發(fā)端承載控制模塊、收端承載控制模塊、一種或一種以上的媒體承載通道模塊；一種媒體承載通道模塊傳輸一種媒體類型的數(shù)據(jù)信息；呼叫處理系統(tǒng)的發(fā)端承載控制模塊和收端承載控制模塊分別接收發(fā)端用戶和收端用戶發(fā)送的承載操作請求信息，并將該承載操作信息發(fā)送給對端承載控制模塊；呼叫處理系統(tǒng)的發(fā)端承載控制模塊與收端承載控制模塊進行協(xié)議交互，協(xié)商媒體類型，并根據(jù)協(xié)商好的媒體類型，選擇同種類型的媒體承載通道模塊；呼叫處理系統(tǒng)的發(fā)端承載控制模塊與收端承載控制模塊分別根據(jù)接收的承載操作請求信息，控制相應(yīng)的媒體承載通道模塊對所選擇的媒體承載通道進行操作。
所述的承載操作請求信息可以為協(xié)商媒體類型請求信息、媒體數(shù)據(jù)信息傳輸請求信息、打開媒體承載通道請求信息、關(guān)閉媒體承載通道請求信息或修改媒體承載通道請求信息。
所述的發(fā)端承載控制模塊可以包含發(fā)端承載空閑狀態(tài)處理單元，接收發(fā)端用戶媒體協(xié)商請求或收端承載控制模塊轉(zhuǎn)發(fā)的收端用戶媒體協(xié)商請求，將該請求轉(zhuǎn)發(fā)給發(fā)端資源預(yù)視單元；發(fā)端資源預(yù)視單元，與收端承載控制模塊的收端資源預(yù)視單元交互，執(zhí)行發(fā)端用戶、收端用戶能力集和主從角色及媒體協(xié)商，選定媒體承載通道模塊；發(fā)端承載協(xié)調(diào)單元，與收端承載控制模塊配合，控制選定的承載通道模塊打開、關(guān)閉和修改發(fā)端用戶、收端用戶之間的媒體承載通道。
所述的發(fā)端承載控制模塊可以進一步包含承載例外處理單元，其在發(fā)端用戶、收端用戶能力集的交換或主從角色協(xié)商失敗時，終止發(fā)端的后續(xù)承載事務(wù)操作，并返回到發(fā)端承載空閑狀態(tài)處理單元。
所述的收端承載控制模塊可以包含收端承載空閑狀態(tài)處理單元，接收收端用戶媒體協(xié)商請求或發(fā)端承載控制模塊轉(zhuǎn)發(fā)的發(fā)端用戶媒體協(xié)商請求，將該請求轉(zhuǎn)發(fā)給收端資源預(yù)視單元；收端資源預(yù)視單元，與發(fā)端承載控制模塊的發(fā)端資源預(yù)視單元交互，執(zhí)行發(fā)端用戶、收端用戶能力集的交換和主從角色及媒體協(xié)商，選定承載通道模塊；收端承載協(xié)調(diào)單元，與發(fā)端承載協(xié)調(diào)單元配合，控制選定的承載通道模塊打開、關(guān)閉和修改發(fā)端用戶、收端用戶終端之間的媒體承載通道；并對承載控制過程進行監(jiān)視。
所述的收端承載控制模塊可以進一步包含承載例外處理單元，其在發(fā)端用戶、收端用戶能力集的交換或主從角色協(xié)商失敗時，終止收端的后續(xù)承載事務(wù)操作，并返回到收端承載空閑狀態(tài)處理單元。
該呼叫處理系統(tǒng)可以包含與發(fā)端承載控制模塊和收端承載控制模塊分別相連的一種或一種以上承載通道模塊，所述的承載通道模塊可以包含承載通道空閑狀態(tài)處理單元，接收發(fā)端承載控制模塊或收端承載控制模塊發(fā)送的打開媒體承載通道的控制信息，并根據(jù)控制信息發(fā)送給承載通道打開單元；承載通道打開單元，根據(jù)收到的打開媒體承載通道指示信息打開媒體承載通道；承載通道激活單元，媒體承載通道打開后激活媒體承載通道，控制媒體承載通道在發(fā)端用戶和收端用戶終端之間傳輸媒體數(shù)據(jù)信息流；承載通道修改單元，根據(jù)收到的修改媒體承載通道指示信息修改媒體承載通道；承載通道關(guān)閉單元，根據(jù)收到的關(guān)閉媒體承載通道指示信息關(guān)閉媒體承載通道。
所述的承載通道模塊可以進一步包含承載通道例外處理單元，其在承載通道打開或激活或承載通道修改錯誤或承載通道關(guān)閉錯誤時，終止后續(xù)媒體承載通道事務(wù)操作，返回到承載通道空閑狀態(tài)處理單元。
為達到上述目的另一個方面，本發(fā)明提供了一種實現(xiàn)支持多媒體業(yè)務(wù)的軟交換呼叫處理方法，在軟交換實體中設(shè)置所述的呼叫處理系統(tǒng)，并在其呼叫控制子系統(tǒng)中設(shè)置發(fā)端呼叫控制模塊、收端呼叫控制模塊；在其承載控制子系統(tǒng)中設(shè)置發(fā)端承載控制模塊、收端承載控制模塊，該方法包括以下步驟1)呼叫控制子系統(tǒng)的發(fā)端呼叫控制模塊接收發(fā)端用戶發(fā)起的呼叫請求，并發(fā)送給收端呼叫控制模塊；2)呼叫控制子系統(tǒng)的收端呼叫控制模塊向收端用戶轉(zhuǎn)發(fā)該呼叫請求，并將收端用戶后續(xù)接續(xù)狀態(tài)返回給發(fā)端呼叫控制模塊；3)呼叫控制子系統(tǒng)的發(fā)端呼叫控制模塊將收端用戶的接續(xù)狀態(tài)通知發(fā)端用戶；4)承載控制子系統(tǒng)的發(fā)端或收端承載控制子系統(tǒng)接收本端用戶的媒體類型協(xié)商請求，并發(fā)送給對端承載控制子系統(tǒng)；5)承載控制子系統(tǒng)的發(fā)端承載控制模塊與收端承載控制模塊進行交互，根據(jù)該請求進行媒體類型協(xié)商，選擇相同媒體類型的媒體承載通道；
6)收端用戶應(yīng)答后，承載控制子系統(tǒng)的發(fā)端承載控制模塊與收端承載控制模塊配合，共同打開選擇的媒體承載通道，控制該媒體類型數(shù)據(jù)信息傳輸。
所述步驟1)可以進一步包括發(fā)端呼叫控制模塊根據(jù)發(fā)端用戶的呼叫請求，對發(fā)端用戶是否有權(quán)和有能力進行此類型呼叫進行鑒權(quán)；對于通過鑒權(quán)的呼叫請求，收集初始信息，根據(jù)編號計劃判定呼叫類型以及執(zhí)行地址翻譯，確定收端用戶地址；并根據(jù)分析結(jié)果對發(fā)端用戶是否有進行本次呼叫的權(quán)限進行鑒權(quán)；發(fā)端呼叫控制模塊只將通過上述兩次鑒權(quán)的呼叫請求發(fā)送給收端呼叫控制模塊，將鑒權(quán)未通過的呼叫請求丟棄。
所述步驟2)可以進一步包括收端呼叫控制模塊對收端用戶是否有權(quán)和有能力進行此類型呼叫進行鑒權(quán)，只將通過鑒權(quán)的呼叫請求發(fā)送給收端用戶，將鑒權(quán)未通過的呼叫請求丟棄。
所述步驟4)可以為在發(fā)端用戶與收端用戶建立連接時，發(fā)端承載控制模塊接收發(fā)端用戶的媒體類型協(xié)商請求，并發(fā)送給收端承載控制模塊，啟動承載控制過程；或收端承載控制模塊接收收端用戶的媒體類型協(xié)商請求，并發(fā)送給發(fā)端承載控制模塊，啟動承載控制過程。
該方法可以進一步包括對呼叫處理過程進行監(jiān)視，在出現(xiàn)異常情況時結(jié)束呼叫流程。
由本發(fā)明的技術(shù)方案可見，本發(fā)明的這種支持多媒體業(yè)務(wù)的軟交換呼叫處理系統(tǒng)及方法，將呼叫處理系統(tǒng)設(shè)置為呼叫控制子系統(tǒng)和承載控制子系統(tǒng)；在呼叫處理過程中，由呼叫控制子系統(tǒng)發(fā)起和建立呼叫，在建立媒體承載連接的過程中，先進行媒體類型協(xié)商，再根據(jù)媒體類型選擇相應(yīng)的承載通道并控制其傳輸業(yè)務(wù)數(shù)據(jù)信息。本發(fā)明能夠很好地適應(yīng)分組交換網(wǎng)絡(luò)中呼叫控制與承載傳輸相互分離的特點，并能夠?qū)Σ煌襟w承載通道進行單獨控制，因此本發(fā)明的軟交換呼叫處理系統(tǒng)及方法，不僅支持現(xiàn)有的PSTN和VoIP基本語音業(yè)務(wù)，而且也支持VoIP網(wǎng)上的多媒體業(yè)務(wù)。


圖1為本發(fā)明一個較佳實施例的軟交換呼叫處理系統(tǒng)結(jié)構(gòu)示意圖；圖2為圖1所示實施例中發(fā)端呼叫控制模塊101內(nèi)部結(jié)構(gòu)示意圖；圖3為圖1所示實施例中收端呼叫控制模塊102內(nèi)部結(jié)構(gòu)示意圖；圖4a為圖1所示實施例中發(fā)端承載控制模塊111內(nèi)部結(jié)構(gòu)示意圖；圖4b為圖1所示實施例中發(fā)端承載控制模塊112內(nèi)部結(jié)構(gòu)示意圖；圖5為圖1所示實施例中承載通道模塊113內(nèi)部結(jié)構(gòu)示意圖；圖6a為主、被叫用戶屬于同一個軟交換實體控制域的示意圖；圖6b為主、被叫用戶屬于不同軟交換實體控制域的示意圖；圖7為圖6a所示的情況下的呼叫處理過程示意圖。
具體實施例方式
為使本發(fā)明的目的、技術(shù)方案和優(yōu)點更加清楚明白，下面結(jié)合實施例和附圖，對本發(fā)明進一步詳細(xì)說明。
本發(fā)明的這種支持多媒體業(yè)務(wù)的軟交換呼叫處理系統(tǒng)及方法，根據(jù)呼叫控制與承載傳輸分離的思想，將呼叫處理系統(tǒng)設(shè)置為呼叫控制子系統(tǒng)和承載控制子系統(tǒng)；在處理多媒體呼叫時，由呼叫控制子系統(tǒng)控制呼叫信令通道的接續(xù)過程，由承載控制子系統(tǒng)控制媒體傳輸通道的連接過程；在建立媒體承載連接的過程中，先進行媒體類型協(xié)商，再根據(jù)媒體類型選擇相應(yīng)的媒體承載通道進行媒體流的傳輸。
參見圖1，圖1為本發(fā)明一個較佳實施例的軟交換呼叫處理系統(tǒng)結(jié)構(gòu)示意圖。該呼叫處理系統(tǒng)包含呼叫控制子系統(tǒng)100，包含發(fā)端呼叫控制模塊101和收端呼叫控制模塊102；承載控制子系統(tǒng)110，包含發(fā)端承載控制模塊111、收端承載控制模塊112以及媒體承載通道模塊113，本實施例的媒體承載通道模塊113包含了三種基本類型語音承載通道模塊114、圖像承載通道模塊115和數(shù)據(jù)承載通道模塊116；每種承載通道模塊傳輸相應(yīng)媒體類型的數(shù)據(jù)信息。本實施例的媒體承載通道模塊113可以在這三種基本承載通道模塊類型的基礎(chǔ)上進一步定義粒度更小的媒體承載通道模塊類型，如語音承載通道模塊114可以進一步根據(jù)不同的語音壓縮編碼格式劃分成G.711語音承載通道模塊、G.729語音承載通道模塊、G.723.1媒體承載通道模塊等。
其中，發(fā)端呼叫控制模塊101接收發(fā)端用戶的呼叫請求，并將該呼叫請求發(fā)送給收端呼叫控制模塊102；收端呼叫控制模塊102向收端用戶發(fā)送接續(xù)呼叫請求，并將收端用戶的接續(xù)狀態(tài)信息返回給發(fā)端呼叫控制模塊101；發(fā)端呼叫控制模塊101將收端用戶的接續(xù)狀態(tài)返回給發(fā)端用戶。
發(fā)端承載控制模塊111與收端承載控制模塊112分別接收發(fā)端用戶和收端用戶發(fā)送的媒體類型協(xié)商請求，進行協(xié)議交互確定媒體類型，并根據(jù)確定的媒體類型，選擇同種類型的媒體承載通道模塊113，例如本實施例發(fā)送的是語音數(shù)據(jù)信息，則選擇語音承載通道模塊114。
發(fā)端承載控制模塊111與收端承載控制模塊112控制選擇的媒體承載通道模塊113打開相應(yīng)的媒體承載通道，在發(fā)端用戶終端和收端用戶終端之間傳輸相應(yīng)的媒體流數(shù)據(jù)信息。
本實施例中的發(fā)端呼叫控制模塊101的結(jié)構(gòu)參見圖2，圖2為圖1所示實施例中發(fā)端呼叫控制模塊101內(nèi)部結(jié)構(gòu)示意圖。該發(fā)端呼叫控制模塊101包含發(fā)端空閑狀態(tài)處理單元201、發(fā)端試呼鑒權(quán)單元202、收集并分析信息單元203、鑒權(quán)呼叫建立單元204、發(fā)送呼叫單元205、發(fā)端提醒單元206、發(fā)端呼叫建立單元207和發(fā)端呼叫例外處理單元208。
發(fā)端空閑狀態(tài)處理單元201，接收發(fā)端用戶的呼叫發(fā)起請求，并將該呼叫請求轉(zhuǎn)發(fā)給發(fā)端試呼鑒權(quán)單元202。
發(fā)端試呼鑒權(quán)單元202根據(jù)發(fā)端用戶標(biāo)識和業(yè)務(wù)輪廓檢查發(fā)端用戶的權(quán)限，證實發(fā)端用戶是否有權(quán)和有能力進行此類型的呼叫，并將鑒權(quán)檢查結(jié)果發(fā)送給收集并分析信息單元203。
收集并分析信息單元203，從發(fā)端用戶呼叫請求中收集初始信息包，并根據(jù)編號計劃判定呼叫類型以及執(zhí)行地址翻譯，確定收端用戶地址，將分析結(jié)果發(fā)送給鑒權(quán)呼叫建立單元204。
鑒權(quán)呼叫建立單元204，驗證發(fā)端用戶是否具有發(fā)起本次呼叫連接的權(quán)利，并將驗證結(jié)果發(fā)送給發(fā)送呼叫單元205。
發(fā)送呼叫單元205，將通過鑒權(quán)呼叫建立單元驗證的發(fā)端用戶的呼叫請求發(fā)送到收端呼叫控制模塊102，等待收端呼叫控制模塊102返回的收端用戶振鈴的接續(xù)狀態(tài)指示信息，并在接收到該指示信息后發(fā)送給發(fā)端提醒單元206。
發(fā)端提醒單元206，發(fā)送收端用戶振鈴指示信息給發(fā)端用戶，等待收端呼叫控制模塊102發(fā)送的收端用戶應(yīng)答指示信息，并在接收到該指示信息后發(fā)送給發(fā)端呼叫建立單元207；發(fā)端呼叫建立單元207，發(fā)送收端用戶應(yīng)答指示信息給發(fā)端用戶，并通過收端呼叫控制模塊102的配合，在發(fā)端用戶和收端用戶之間建立問題的呼叫控制關(guān)系。
發(fā)端呼叫例外處理單元208，在發(fā)端試呼鑒權(quán)未通過或收集到無效信息或鑒權(quán)呼叫建立失敗或呼叫發(fā)送失敗或收端用戶拒絕接續(xù)或收端用戶無應(yīng)答或呼叫建立出故障時，返回到發(fā)端呼叫空閑狀態(tài)處理單元201。
在上述單元運行過程中，如果發(fā)端用戶放棄呼叫或切斷呼叫，則也返回到發(fā)端呼叫空閑狀態(tài)處理單元201。
本實施例中的收端呼叫控制模塊102的結(jié)構(gòu)參見圖3，圖3為圖1所示實施例中收端呼叫控制模塊102內(nèi)部結(jié)構(gòu)示意圖。該收端呼叫控制模塊102包含收端空閑狀態(tài)處理單元301、收端試呼鑒權(quán)單元302、顯示呼叫單元303、收端提醒單元304、收端呼叫建立單元305和收端呼叫例外處理單元306。
其中，收端空閑狀態(tài)處理單元301，接收發(fā)端空閑狀態(tài)處理單元201轉(zhuǎn)發(fā)的發(fā)端用戶的呼叫請求，并將該呼叫請求轉(zhuǎn)發(fā)給收端試呼鑒權(quán)單元302。
收端試呼鑒權(quán)單元302，檢查收端用戶是否有權(quán)和有能力進行此類型呼叫，并將檢查結(jié)果發(fā)送給顯示呼叫單元303。
顯示呼叫單元303，將通過收端試呼鑒權(quán)單元302檢查的來話呼叫根據(jù)收端用戶地址等信息通知給收端用戶。
收端提醒單元304，提醒收端用戶有來話呼叫，等待收端用戶終端應(yīng)答信息，并將收端用戶振鈴的接續(xù)狀態(tài)指示信息發(fā)送給發(fā)端呼叫控制模塊101的發(fā)送呼叫單元205。
收端呼叫建立單元305，將收端用戶應(yīng)答指示返回給發(fā)端呼叫控制模塊101的發(fā)端提醒單元206，并通過發(fā)端呼叫控制模塊102的配合，在發(fā)端用戶和收端用戶之間建立穩(wěn)態(tài)的呼叫控制關(guān)系。
收端呼叫例外處理單元306，在收端試呼鑒權(quán)未通過或呼叫顯示故障或收端用戶拒絕接續(xù)或收端用戶無應(yīng)答或呼叫建立出故障時，返回到收端呼叫空閑狀態(tài)處理單元301。
本實施例中的發(fā)端承載控制模塊111的結(jié)構(gòu)參見圖4a，圖4a為圖1所示實施例中發(fā)端承載控制模塊111內(nèi)部結(jié)構(gòu)示意圖。該發(fā)端承載控制模塊111包含發(fā)端承載空閑狀態(tài)處理單元401，發(fā)端資源預(yù)視單元402、發(fā)端承載協(xié)調(diào)單元403和承載例外處理單元404。
發(fā)端承載空閑狀態(tài)處理單元401，在發(fā)端呼叫控制模塊運行發(fā)端提醒單元206或者發(fā)端呼叫建立單元207時，接收發(fā)端用戶媒體協(xié)商請求和收端承載控制模塊112發(fā)送的收端用戶媒體協(xié)商請求，轉(zhuǎn)發(fā)給發(fā)端資源預(yù)視單元402。
發(fā)端資源預(yù)視單元402，與收端承載控制模塊112的收端資源預(yù)視單元412交互，執(zhí)行發(fā)端用戶、收端用戶能力集的交換和主從角色及媒體協(xié)商，選定特定類型的媒體承載通道模塊113；發(fā)端承載協(xié)調(diào)單元403，與收端承載協(xié)調(diào)單元413配合，控制選定的媒體承載通道模塊113打開、關(guān)閉和修改發(fā)端用戶、收端用戶之間的媒體承載通道；并監(jiān)視發(fā)端對該媒體承載通道的后續(xù)操作過程。
承載例外處理單元404，其在發(fā)端用戶、收端用戶能力集的交換或主從角色協(xié)商失敗時，返回到發(fā)端承載空閑狀態(tài)處理單元401。
本實施例中發(fā)端承載控制模塊111和收端承載控制模塊112的結(jié)構(gòu)基本相同，收端承載控制模塊112的結(jié)構(gòu)參見圖4b，圖4b為圖1所示實施例中收端承載控制模塊112內(nèi)部結(jié)構(gòu)示意圖。該收端承載控制模塊112包含收端承載空閑狀態(tài)處理單元411、收端資源預(yù)視單元412、收端承載協(xié)調(diào)單元413和承載例外處理單元414。
收端承載空閑狀態(tài)處理單元411，在收端呼叫控制模塊運行收端提醒單元304或者收端呼叫建立單元305時，接收被叫媒體協(xié)商請求和發(fā)端承載控制模塊111發(fā)送的主叫媒體協(xié)商請求，轉(zhuǎn)發(fā)給收端資源預(yù)視單元412。
收端資源預(yù)視單元412，與發(fā)端承載控制模塊111的發(fā)端資源預(yù)視單元402交互，執(zhí)行發(fā)端用戶、收端用戶能力集的交換和主從角色及媒體協(xié)商，選定與發(fā)端相同類型的承載通道模塊113。
收端承載協(xié)調(diào)單元413，與發(fā)端承載協(xié)調(diào)單元403配合，控制選定的承載通道模塊113打開、關(guān)閉和修改發(fā)端用戶、收端用戶之間的媒體承載通道；并監(jiān)視收端對該媒體承載通道的后續(xù)操作過程。
承載例外處理單元414，其在發(fā)端用戶、收端用戶能力集的交換或主從角色協(xié)商失敗時，返回到收端承載空閑狀態(tài)處理單元411。
另外本實施例的發(fā)端承載控制模塊111和收端承載控制模塊112在關(guān)閉或切斷呼叫時都返回到收端承載空閑狀態(tài)處理單元411。
本實施例中的媒體承載通道模塊113的結(jié)構(gòu)參見圖5，圖5為圖1所示實施例中媒體承載通道模塊113內(nèi)部結(jié)構(gòu)示意圖。本實施例中的語音承載通道模塊114、圖像承載通道模塊115和數(shù)據(jù)承載通道模塊116雖然所控制的媒體承載通道類型不同，但這些承載通道模塊本身的結(jié)構(gòu)是相同的，都包含承載通道空閑狀態(tài)處理單元501、承載通道打開單元502、承載通道激活單元503、承載通道修改單元504、承載通道關(guān)閉單元505和承載通道例外處理單元506。
承載通道空閑狀態(tài)處理單元501，接收發(fā)端承載控制模塊111或收端承載控制模塊112發(fā)送的打開承載通道的控制信息，轉(zhuǎn)發(fā)給承載通道打開單元502。
承載通道打開單元502，根據(jù)發(fā)端承載控制模塊111或收端承載控制模塊112發(fā)送的控制信息打開承載通道，并在承載通道打開后轉(zhuǎn)入承載通道激活單元503。
承載通道激活單元503，激活打開的媒體承載通道，控制發(fā)端用戶、收端用戶之間的媒體流傳輸過程，在收到發(fā)端承載控制模塊111或收端承載控制模塊112發(fā)送的關(guān)閉和修改承載通道的控制信息后，轉(zhuǎn)發(fā)給承載通道關(guān)閉單元505或承載通道修改單元504。
承載通道修改單元504，根據(jù)發(fā)端承載控制模塊111或收端承載控制模塊112發(fā)送的控制信息修改承載通道，并在承載通道修改完畢后再次轉(zhuǎn)入承載通道激活單元503。
承載通道關(guān)閉單元505，根據(jù)發(fā)端承載控制模塊111或收端承載控制模塊112發(fā)送的控制信息關(guān)閉承載通道，并在承載通道關(guān)閉后轉(zhuǎn)入承載通道空閑狀態(tài)處理單元501。
承載通道例外處理單元506，在承載通道打開錯誤或承載通道激活錯誤或承載通道修改錯誤或承載通道關(guān)閉錯誤時，處理后續(xù)操作，并返回到承載通道空閑狀態(tài)處理單元501。
在實際應(yīng)用時，對于同一個媒體承載通道需要設(shè)置兩個相同的承載通道模塊113，分別與發(fā)端承載控制模塊111、收端承載控制模塊112相連，它們相互配合，共同完成對媒體承載通道的控制功能。
本發(fā)明的呼叫處理系統(tǒng)設(shè)置在軟交換實體中。實際應(yīng)用中，主叫用戶和被叫用戶可能屬于同一個軟交換控制，也可能屬于不同的軟交換控制。參見圖6a，圖6a為主、被叫用戶屬于同一個軟交換控制情況的示意圖。其中主叫用戶601與軟交換602中的發(fā)端呼叫控制模塊101和發(fā)端承載控制模塊111進行信息交互；被叫用戶603與軟交換602中的收端呼叫控制模塊102和收端承載控制模塊112進行信息交互。
參見圖6b，圖6b為主、被叫用戶屬于不同軟交換控制情況的示意圖。其中主叫用戶601與軟交換610中的發(fā)端呼叫控制模塊101和發(fā)端承載控制模塊111進行信息交互；軟交換610中的收端呼叫控制模塊102與軟交換620中的發(fā)端呼叫控制模塊101進行信息交互；軟交換610中的收端承載控制模塊112與軟交換620中的發(fā)端承載控制模塊111進行信息交互；被叫用戶603與軟交換620中的收端呼叫控制模塊102和收端承載控制模塊112進行信息交互。
本申請中的“發(fā)端用戶”、“收端用戶”根據(jù)軟交換實體在呼叫處理過程中的所處的位置，“發(fā)端用戶”可以代表主叫用戶或者代表前一個軟交換實體，“收端用戶”可以代表被叫用戶或者代表下一個軟交換實體。
參見圖7，圖7為主被叫用戶使用H.323信令時，圖6a所示情況下的多媒體呼叫處理過程示意圖。圖7示意了在一次成功的多媒體呼叫建立流程中，H.323信令事件與呼叫處理系統(tǒng)各個模塊之間的處理關(guān)系。該過程包括呼叫控制過程和承載控制過程，具體包括以下步驟步驟(1)發(fā)端呼叫控制模塊(O_CCM)的發(fā)端空閑狀態(tài)處理單元(O_NULL)收到主叫用戶發(fā)起呼叫請求的“Setup”消息之后，發(fā)送到發(fā)端試呼鑒權(quán)單元(Auth Orig.Attempt)。
步驟(2)發(fā)端試呼鑒權(quán)單元，首先向發(fā)端用戶發(fā)送“Calll Proceeding”消息通知呼叫正在處理過程中，然后根據(jù)主叫用戶標(biāo)識和業(yè)務(wù)輪廓檢查發(fā)端終端的權(quán)限，證實主叫用戶是否有權(quán)/能力進行本類型呼叫，如果鑒權(quán)成功，則將鑒權(quán)結(jié)果發(fā)送到收集并分析信息單元(Collect&Analyse_Information)。
步驟(3)收集并分析信息單元從呼叫請求中收集初始信息包/撥號串，并根據(jù)撥號計劃分析和翻譯信息，確定收端用戶地址和呼叫類型，例如本地呼叫，轉(zhuǎn)接呼叫，國際呼叫等，在得到收端用戶地址和地址性質(zhì)后，將分析結(jié)果發(fā)送到鑒權(quán)呼叫建立單元(Auth Call Setup)。
步驟(4)鑒權(quán)呼叫建立單元，證實主叫用戶是否有進行本次呼叫的權(quán)限，當(dāng)發(fā)起此呼叫的權(quán)限被證實時，呼叫建立有權(quán)事件發(fā)生，并轉(zhuǎn)入發(fā)送呼叫單元(Send_Call)。
步驟(5)發(fā)送呼叫單元，向收端呼叫控制模塊(T_CCM)的收端空閑狀態(tài)處理單元(T_NULL)發(fā)送想要建立到被叫用戶呼叫的指示。
步驟(6)收端呼叫控制模塊的收端空閑狀態(tài)處理單元(T_NULL)在收到發(fā)端呼叫請求指示后，將該請求發(fā)送給收端試呼鑒權(quán)單元(AuthTerm.Attempt)。
步驟(7)收端試呼鑒權(quán)單元，根據(jù)被叫用戶標(biāo)識和業(yè)務(wù)輪廓檢查被叫終端的權(quán)限，證實呼叫是否有權(quán)接續(xù)到被叫終端，如果鑒權(quán)成功，將鑒權(quán)結(jié)果發(fā)送到顯示呼叫單元(Present_Call)。
步驟(8)顯示呼叫單元，向被叫用戶發(fā)送“Setup”消息，將來話呼叫通知給被叫終端，同時等待被叫用戶的響應(yīng)信息。當(dāng)呼叫顯示單元接收到被叫終端發(fā)送來的“Alerting”消息后，將該消息發(fā)送到收端提醒單元(T_Alerting)，并通知發(fā)端呼叫控制模塊被叫用戶正在振鈴。顯示呼叫單元可以根據(jù)收端用戶地址等信息判斷出主、被叫用戶是否屬于不同軟交換控制。本實施例是屬于同一個軟交換控制的情況。如果主、被叫用戶屬于不同軟交換控制，則收端呼叫控制模塊向被叫用戶所在的軟交換中的發(fā)端呼叫控制模塊轉(zhuǎn)發(fā)“Setup”消息，該發(fā)端呼叫控制模塊向同一軟交換中的收端呼叫控制模塊轉(zhuǎn)發(fā)“Setup”消息，該收端呼叫控制模塊將Setup”消息最終發(fā)送給被叫用戶。
本實施例中，在顯示呼叫單元運行時，收端呼叫控制模塊可能會在接收到被叫用戶發(fā)送的“Alerting”之前接收到一個“Call_Proceeding”消息，該消息不會導(dǎo)致收端呼叫控制模塊運行其他功能單元。
步驟(9)發(fā)端呼叫控制模塊在運行發(fā)送呼叫單元時，收到收端呼叫控制模塊發(fā)送的被叫振鈴指示之后，向主叫終端發(fā)送“Alerting”消息，將振鈴事件通知給主叫用戶，并運行發(fā)端提醒單元(O_Alerting)。
當(dāng)發(fā)端呼叫控制模塊和收端呼叫控制模塊運行發(fā)端提醒單元(O_Alerting)和收端提醒單元(T_Alerting)時，發(fā)端承載控制模塊(O_BCM)和收端承載控制模塊(T_BCM)開始并發(fā)運行發(fā)端和收端承載空閑狀態(tài)(Bear_null)處理單元，以接收發(fā)端和收端之間的承載操作信息。
步驟(10)發(fā)端承載控制模塊收到主叫用戶發(fā)送的媒體類型協(xié)商消息“TerminalCapabilitySet(TCS)”后，運行發(fā)端資源預(yù)視單元(Look_Ahead)，向收端承載控制模塊發(fā)送媒體類型協(xié)商指示，并等待被叫用戶終端發(fā)送的媒體類型協(xié)商響應(yīng)消息“TerminalCapabilitySetAck(TCSA)”。
步驟(11)收端承載控制模塊在收到發(fā)端承載控制模塊發(fā)送來的“TCS”指示后，運行收端資源預(yù)視單元(Look_Ahead)，同時向被叫用戶終端發(fā)送媒體協(xié)商消息“TerminalCapabilitySet(TCS)”。本實施例是屬于同一個軟交換控制的情況。如果主、被叫用戶屬于不同軟交換控制，則收端承載控制模塊向被叫用戶所在的軟交換中的發(fā)端承載控制模塊轉(zhuǎn)發(fā)媒體協(xié)商消息，該發(fā)端承載控制模塊向同一軟交換中的收端承載控制模塊轉(zhuǎn)發(fā)媒體協(xié)商消息。
步驟(12)收端承載控制模塊在運行收端資源預(yù)視單元時，接收到被叫用戶終端的媒體資源協(xié)商回應(yīng)消息“TCSA”，將之轉(zhuǎn)發(fā)給發(fā)端承載控制模塊，并繼續(xù)運行收端資源預(yù)視單元(Look_Ahead)等待角色協(xié)商過程。
步驟(13)發(fā)端承載控制模塊的資源預(yù)視單元收到收端承載控制模塊發(fā)送來的媒體類型響應(yīng)指示后，向主叫用戶終端發(fā)送媒體協(xié)商回應(yīng)消息“TerminalCapabilitySetAck(TCSA)”，并繼續(xù)運行發(fā)端資源預(yù)視單元(Look_Ahead)等待角色協(xié)商過程。
步驟(14)發(fā)端承載控制模塊在運行發(fā)端資源預(yù)視單元時，接收到主叫用戶終端發(fā)送的角色協(xié)商消息“MasterSlaveDetermination(MSD)”，將之轉(zhuǎn)發(fā)給收端承載控制模塊，并繼續(xù)運行發(fā)端資源預(yù)視單元，等待收端承載控制模塊的回應(yīng)消息。
步驟(15)收端承載控制模塊收到發(fā)端承載控制模塊發(fā)送來的角色協(xié)商指示后，向被叫用戶終端發(fā)送“MasterSlaveDetermination”消息，并繼續(xù)運行收端資源預(yù)視單元等待被叫用戶終端發(fā)送的角色協(xié)商回應(yīng)消息“MasterSlaveDetermination ACK(MSDA)”。
步驟(16)收端承載控制模塊在運行收端資源預(yù)視單元時，接收到被叫用戶終端的角色協(xié)商回應(yīng)消息“MasterSlaveDetermination ACK(MSDA)”，將之轉(zhuǎn)發(fā)給發(fā)端承載控制模塊，并轉(zhuǎn)入運行收端承載協(xié)調(diào)單元(Bear_Coordination)。
步驟(17)發(fā)端承載控制模塊在運行收端資源預(yù)視單元時，接收到收端承載控制模塊發(fā)送的角色協(xié)商回應(yīng)指示后，向主叫用戶終端發(fā)送角色協(xié)商回應(yīng)消息“MasterSlaveDeterminationACK(MSDA)”，并轉(zhuǎn)入運行發(fā)端承載協(xié)調(diào)單元(Bear_Coordination)。
步驟(18)收端呼叫控制模塊在運行收端提醒單元(T_Alerting)時，接收到被叫用戶發(fā)送來的“Connect”消息，運行收端呼叫建立單元(T_Setup)，向發(fā)端呼叫控制模塊發(fā)送被叫用戶應(yīng)答指示。
步驟(19)發(fā)端呼叫控制模塊在運行發(fā)端提醒單元(O_Alerting)時，接收到收端呼叫控制模塊發(fā)送來的被叫應(yīng)答指示后，運行發(fā)端呼叫建立單元(O_Setup)，向主叫用戶發(fā)送“Connect”消息，。
當(dāng)發(fā)端/收端呼叫控制模塊分別運行發(fā)端/收端呼叫建立單元(O/T_Setup)”時，主被叫用戶終端之間就可以進行打開承載通道的操作了，打開承載通道可以由主叫終端發(fā)起也可以由被叫終端發(fā)起。
下面假設(shè)主叫用戶首先發(fā)起打開承載通道的消息流程，繼續(xù)步驟(20)～(23)所示步驟(20)發(fā)端承載控制模塊在運行發(fā)端承載協(xié)調(diào)單元時，收到主叫用戶打開承載通道的請求消息“OpenLogicalChannel(OLC)”，運行一個承載通道模塊(O_CSM)，并驅(qū)動該承載通道模塊由承載通道空閑單元(Channel_Null)，轉(zhuǎn)入承載通道打開單元(Channel_Opening)，同時向收端承載控制模塊發(fā)送打開承載通道請求指示。
步驟(21)收端承載控制模塊在運行收端承載協(xié)調(diào)單元時，收到發(fā)端承載控制模塊發(fā)送的打開承載通道請求指示后，運行一個與發(fā)端承載通道模塊相同的收端承載通道模塊(T_CSM)，并驅(qū)動該承載通道模塊由承載通道空閑單元(Channel_Null)轉(zhuǎn)入承載通道打開單元(Channel_Opening)，同時向被叫用戶終端發(fā)送“OpenLogicalChannel(OLC)”消息。
步驟(22)收端承載控制模塊在運行收端承載協(xié)調(diào)單元時，收到被叫用戶終端發(fā)送的承載通道已打開的回應(yīng)消息“OpenLogicalChannelAck(OLCA)”后，驅(qū)動承載通道模塊運行承載通道激活單元(Channel_Active)，并向發(fā)端承載控制模塊發(fā)送該承載通道已打開的通知。
步驟(23)發(fā)端承載控制模塊在運行發(fā)端承載協(xié)調(diào)單元時，接收到收端承載控制模塊發(fā)送的承載通道已打開的回應(yīng)消息后，驅(qū)動發(fā)端承載通道模塊運行承載通道激活單元(Channel_Active)，并向主叫終端發(fā)送相應(yīng)的“OpenLogicalChannelAck(OLCA)消息。
當(dāng)主、被叫側(cè)代表同一條媒體通道的承載通道模塊都運行承載通道激活單元(Channel_Avtive)后，媒體通道被建立成功，主被叫終端之間可以開始傳輸相應(yīng)類型的媒體數(shù)據(jù)。重復(fù)步驟(20)～(23)可以打開多條媒體承載通道，從而實現(xiàn)主、被叫用戶終端之間的多種媒體(語音、視頻和數(shù)據(jù))流的傳輸。
當(dāng)主、被叫用戶之間的通話結(jié)束時，呼叫釋放可以由主叫用戶發(fā)起也可以由被叫用戶發(fā)起。下面假設(shè)主叫用戶發(fā)起釋放呼叫的請求，將首先按照(24)～(27)所描述的流程關(guān)閉所有的媒體承載通道，并在成功關(guān)閉所有的媒體通道之后，按照(28)～(29)所描述的流程結(jié)束承載控制過程。
步驟(24)發(fā)端承載控制模塊在運行發(fā)端承載協(xié)調(diào)單元時，收到主叫用戶終端發(fā)送的關(guān)閉某條媒體承載通道的請求消息“CloseLogicalChannel”，驅(qū)動發(fā)端代表本條媒體承載通道的承載通道模塊運行承載通道關(guān)閉單元(Channel_closing)，并向收端承載控制模塊發(fā)送關(guān)閉該媒體承載通道的指示。
步驟(25)收端承載控制模塊在運行收端承載協(xié)調(diào)單元時，接收到發(fā)端承載控制模塊發(fā)來的關(guān)閉承載通道指示后，驅(qū)動收端代表本條媒體承載通道的承載通道模塊運行承載通道關(guān)閉單元(Channel_closing)，并向被叫用戶終端發(fā)送“CloseLogicalChannel”請求消息。
步驟(26)收端承載控制模塊在運行收端承載協(xié)調(diào)單元時，收到被叫用戶終端發(fā)送的承載通道已關(guān)閉的回應(yīng)消息“CloseLogicalChannelAck(CLCA)”，驅(qū)動收端承載通道模塊運行承載通道空閑單元(Channel_Null)，并向發(fā)端承載控制模塊發(fā)送該媒體承載通道已關(guān)閉的通知。
步驟(27)發(fā)端承載控制模塊在運行發(fā)端承載協(xié)調(diào)單元時，接收到收端承載控制模塊發(fā)送的承載通道已關(guān)閉的通知，驅(qū)動發(fā)端承載通道模塊運行承載通道空閑單元(Channel_Null)，并向主叫用戶終端發(fā)送相應(yīng)的“CloseLogicalChannelAck(CLCA)消息。
步驟(28)發(fā)端承載控制模塊在運行發(fā)端承載協(xié)調(diào)單元時，接收到主叫端點發(fā)送來的結(jié)束承載控制會話的消息“EndSessionCommand”，運行發(fā)端承載空閑單元(Bear_NULL)，并通知收端承載控制模塊請求結(jié)束本次承載控制會話；步驟(29)收端承載控制模塊在運行收端承載協(xié)調(diào)單元時，接收到發(fā)端承載控制模塊發(fā)來的結(jié)束承載控制會話的通知，運行收端承載空閑單元(Bear_NULL)，向被叫終端發(fā)送“EndCessionCommand”消息，并關(guān)閉該承載控制會話，承載控制至此全部結(jié)束。
當(dāng)承載控制會話關(guān)閉后，主/被叫將發(fā)起呼叫拆除流程，其流程如(30)～(31)所示
步驟(30)發(fā)端呼叫控制模塊在運行發(fā)端呼叫建立單元(O_Setup)時，接收到主叫用戶結(jié)束本次呼叫的請求消息“Release Complete”，運行發(fā)端空閑狀態(tài)處理單元(O_NULL)，同時向收端呼叫控制模塊發(fā)送結(jié)束此呼叫的指示。
步驟(31)收端呼叫控制模塊在運行收端呼叫建立單元(T_Setup)時，接收到發(fā)端呼叫控制模塊發(fā)送的結(jié)束本次呼叫的指示，運行收端空閑狀態(tài)處理單元(T_NULL)，同時向被叫用戶發(fā)送結(jié)束此呼叫的“Release Complete”消息，至此一次正常的呼叫已經(jīng)全部結(jié)束。
圖7所描述的多媒體呼叫處理過程表明，本發(fā)明提出的基于分層處理原則的軟交換多媒體呼叫處理系統(tǒng)適應(yīng)了多媒體業(yè)務(wù)的呼叫控制與承載控制分離的需要，為實現(xiàn)多媒體業(yè)務(wù)控制奠定了基礎(chǔ)。
由上述的實施例可見，本發(fā)明的這種實現(xiàn)軟交換支持多媒體業(yè)務(wù)的呼叫處理系統(tǒng)及方法，能夠很好地適應(yīng)基于IP網(wǎng)絡(luò)的多媒體業(yè)務(wù)呼叫控制與承載傳輸相互分離的特點，并能夠?qū)Σ煌休d通道進行單獨控制，不僅可以支持基于IP網(wǎng)絡(luò)的多媒體業(yè)務(wù)，而且也可以支持現(xiàn)有的PSTN和VoIP基本語音業(yè)務(wù)。
權(quán)利要求
1.一種實現(xiàn)支持多媒體業(yè)務(wù)的軟交換呼叫處理系統(tǒng)，設(shè)置在軟交換實體中，其特征在于，該系統(tǒng)包含呼叫控制子系統(tǒng)和承載控制子系統(tǒng)；呼叫控制子系統(tǒng)根據(jù)發(fā)端用戶的呼叫請求，向收端用戶發(fā)起呼叫請求，對呼叫的接續(xù)過程進行控制，在發(fā)端用戶與收端用戶建立呼叫連接后，啟動承載控制子系統(tǒng)；承載控制子系統(tǒng)根據(jù)呼叫請求進行媒體類型協(xié)商，選擇相應(yīng)的媒體承載通道并控制選定的媒體承載通道進行媒體數(shù)據(jù)信息傳輸。
2.如權(quán)利要求1所述的呼叫處理系統(tǒng)，其特征在于，所述的呼叫控制子系統(tǒng)包含發(fā)端呼叫控制模塊和收端呼叫控制模塊；發(fā)端呼叫控制模塊接收發(fā)端用戶的呼叫請求，進行初步處理，并將該呼叫請求發(fā)送給收端呼叫控制模塊；收端呼叫控制模塊向收端用戶發(fā)送呼叫請求，并將收端用戶在不同階段的接續(xù)狀態(tài)指示返回給發(fā)端呼叫控制模塊。
3.如權(quán)利要求2所述的呼叫處理系統(tǒng)，其特征在于，所述的發(fā)端呼叫控制模塊包含發(fā)端空閑狀態(tài)處理單元，其接收發(fā)端用戶的呼叫請求，并將該呼叫信息轉(zhuǎn)發(fā)給發(fā)端試呼鑒權(quán)單元；發(fā)端試呼鑒權(quán)單元，根據(jù)發(fā)端用戶標(biāo)識和業(yè)務(wù)輪廓檢查發(fā)端用戶的權(quán)限，證實發(fā)端用戶是否有權(quán)和有能力進行此類型的呼叫，并將鑒權(quán)檢查結(jié)果發(fā)送給收集并分析信息單元；收集并分析信息單元，從呼叫請求中收集初始信息包，并根據(jù)編號計劃判定呼叫類型以及執(zhí)行地址翻譯，確定收端用戶地址，將分析結(jié)果發(fā)送給鑒權(quán)呼叫建立單元；鑒權(quán)呼叫建立單元，驗證發(fā)端用戶是否具有發(fā)起本次呼叫連接的權(quán)利，并將驗證結(jié)果發(fā)送給發(fā)送呼叫單元；發(fā)送呼叫單元，將通過鑒權(quán)呼叫建立單元驗證的發(fā)端用戶的呼叫請求發(fā)送到收端呼叫控制模塊；發(fā)端提醒單元，接收收端呼叫控制模塊發(fā)送的收端用戶振鈴的接續(xù)指示，返回給發(fā)端用戶，等待收端用戶應(yīng)答接續(xù)指示；發(fā)端呼叫建立單元，接收收端呼叫控制模塊發(fā)送的收端用戶應(yīng)答的接續(xù)指示，返回給發(fā)端用戶，在發(fā)端用戶和收端用戶之間建立穩(wěn)態(tài)的呼叫連接關(guān)系，并對后續(xù)的呼叫控制過程進行監(jiān)視。
4.如權(quán)利要求3所述的呼叫處理系統(tǒng)，其特征在于，所述的發(fā)端呼叫控制模塊進一步包含發(fā)端呼叫例外處理單元，其在發(fā)端試呼鑒權(quán)未通過或收集到無效信息或鑒權(quán)呼叫建立失敗或呼叫發(fā)送失敗或收端用戶拒絕接續(xù)或收端用戶無應(yīng)答或呼叫建立出故障時，終止發(fā)端后續(xù)呼叫事務(wù)，并返回到發(fā)端呼叫空閑狀態(tài)處理單元。
5.如權(quán)利要求2所述的呼叫處理系統(tǒng)，其特征在于，所述的收端呼叫控制模塊包含收端空閑狀態(tài)處理單元，其接收發(fā)端呼叫控制模塊的發(fā)送呼叫單元轉(zhuǎn)發(fā)的發(fā)端用戶的呼叫請求，并將該呼叫請求轉(zhuǎn)發(fā)給收端試呼鑒權(quán)單元；收端試呼鑒權(quán)單元，檢查收端用戶是否有權(quán)和有能力進行此類型呼叫，并將檢查結(jié)果發(fā)送給顯示呼叫單元；顯示呼叫單元，將通過收端試呼鑒權(quán)單元檢查的來話呼叫通知給收端用戶；收端提醒單元，提醒收端用戶有來話呼叫，并等待收端用戶終端應(yīng)答；收端呼叫建立單元，將收端用戶應(yīng)答的接續(xù)狀態(tài)發(fā)送給呼叫處理系統(tǒng)的發(fā)端呼叫控制模塊，在發(fā)端用戶和收端用戶之間建立穩(wěn)態(tài)的呼叫連接關(guān)系，并對后續(xù)的呼叫控制過程進行監(jiān)視。
6.如權(quán)利要求5所述的呼叫處理系統(tǒng)，其特征在于，所述的收端呼叫控制模塊進一步包含收端呼叫例外處理單元，其在收端試呼鑒權(quán)未通過或呼叫顯示故障或收端用戶拒絕接續(xù)或收端用戶無應(yīng)答或呼叫建立出故障時，結(jié)束收端后續(xù)呼叫事務(wù)，并返回到收端呼叫空閑狀態(tài)處理單元。
7.如權(quán)利要求1所述的呼叫處理系統(tǒng)，其特征在于，所述的承載控制子系統(tǒng)包含發(fā)端承載控制模塊、收端承載控制模塊、一種或一種以上的媒體承載通道模塊；一種媒體承載通道模塊傳輸一種媒體類型的數(shù)據(jù)信息；呼叫處理系統(tǒng)的發(fā)端承載控制模塊和收端承載控制模塊分別接收發(fā)端用戶和收端用戶發(fā)送的承載操作請求信息，并將該承載操作信息發(fā)送給對端承載控制模塊；呼叫處理系統(tǒng)的發(fā)端承載控制模塊與收端承載控制模塊進行協(xié)議交互，協(xié)商媒體類型，并根據(jù)協(xié)商好的媒體類型，選擇同種類型的媒體承載通道模塊；呼叫處理系統(tǒng)的發(fā)端承載控制模塊與收端承載控制模塊分別根據(jù)接收的承載操作請求信息，控制相應(yīng)的媒體承載通道模塊對所選擇的媒體承載通道進行操作。
8.如權(quán)利要求7所述的呼叫處理系統(tǒng)，其特征在于，所述的承載操作請求信息為協(xié)商媒體類型請求信息、媒體數(shù)據(jù)信息傳輸請求信息、打開媒體承載通道請求信息、關(guān)閉媒體承載通道請求信息或修改媒體承載通道請求信息。
9.如權(quán)利要求7所述的呼叫處理系統(tǒng)，其特征在于，所述的發(fā)端承載控制模塊包含發(fā)端承載空閑狀態(tài)處理單元，接收發(fā)端用戶媒體協(xié)商請求或收端承載控制模塊轉(zhuǎn)發(fā)的收端用戶媒體協(xié)商請求，將該請求轉(zhuǎn)發(fā)給發(fā)端資源預(yù)視單元；發(fā)端資源預(yù)視單元，與收端承載控制模塊的收端資源預(yù)視單元交互，執(zhí)行發(fā)端用戶、收端用戶能力集和主從角色及媒體協(xié)商，選定媒體承載通道模塊；發(fā)端承載協(xié)調(diào)單元，與收端承載控制模塊配合，控制選定的承載通道模塊打開、關(guān)閉和修改發(fā)端用戶、收端用戶之間的媒體承載通道。
10.如權(quán)利要求9所述的呼叫處理系統(tǒng)，其特征在于，所述的發(fā)端承載控制模塊進一步包含承載例外處理單元，其在發(fā)端用戶、收端用戶能力集的交換或主從角色協(xié)商失敗時，終止發(fā)端的后續(xù)承載事務(wù)操作，并返回到發(fā)端承載空閑狀態(tài)處理單元。
11.如權(quán)利要求7所述的呼叫處理系統(tǒng)，其特征在于，所述的收端承載控制模塊包含收端承載空閑狀態(tài)處理單元，接收收端用戶媒體協(xié)商請求或發(fā)端承載控制模塊轉(zhuǎn)發(fā)的發(fā)端用戶媒體協(xié)商請求，將該請求轉(zhuǎn)發(fā)給收端資源預(yù)視單元；收端資源預(yù)視單元，與發(fā)端承載控制模塊的發(fā)端資源預(yù)視單元交互，執(zhí)行發(fā)端用戶、收端用戶能力集的交換和主從角色及媒體協(xié)商，選定承載通道模塊；收端承載協(xié)調(diào)單元，與發(fā)端承載協(xié)調(diào)單元配合，控制選定的承載通道模塊打開、關(guān)閉和修改發(fā)端用戶、收端用戶終端之間的媒體承載通道；并對承載控制過程進行監(jiān)視。
12.如權(quán)利要求11所述的呼叫處理系統(tǒng)，其特征在于，所述的收端承載控制模塊進一步包含承載例外處理單元，其在發(fā)端用戶、收端用戶能力集的交換或主從角色協(xié)商失敗時，終止收端的后續(xù)承載事務(wù)操作，并返回到收端承載空閑狀態(tài)處理單元。
13.如權(quán)利要求7所述的呼叫處理系統(tǒng)，其特征在于，該呼叫處理系統(tǒng)包含與發(fā)端承載控制模塊和收端承載控制模塊分別相連的一種或一種以上承載通道模塊，所述的承載通道模塊包含承載通道空閑狀態(tài)處理單元，接收發(fā)端承載控制模塊或收端承載控制模塊發(fā)送的打開媒體承載通道的控制信息，并根據(jù)控制信息發(fā)送給承載通道打開單元；承載通道打開單元，根據(jù)收到的打開媒體承載通道指示信息打開媒體承載通道；承載通道激活單元，媒體承載通道打開后激活媒體承載通道，控制媒體承載通道在發(fā)端用戶和收端用戶終端之間傳輸媒體數(shù)據(jù)信息流；承載通道修改單元，根據(jù)收到的修改媒體承載通道指示信息修改媒體承載通道；承載通道關(guān)閉單元，根據(jù)收到的關(guān)閉媒體承載通道指示信息關(guān)閉媒體承載通道。
14.如權(quán)利要求13所述的呼叫處理系統(tǒng)，其特征在于，所述的承載通道模塊進一步包含承載通道例外處理單元，其在承載通道打開或激活或承載通道修改錯誤或承載通道關(guān)閉錯誤時，終止后續(xù)媒體承載通道事務(wù)操作，返回到承載通道空閑狀態(tài)處理單元。
15.一種實現(xiàn)支持多媒體業(yè)務(wù)的軟交換呼叫處理方法，其特征在于，在軟交換實體中設(shè)置權(quán)利要求1所述的呼叫處理系統(tǒng)，并在其呼叫控制子系統(tǒng)中設(shè)置發(fā)端呼叫控制模塊、收端呼叫控制模塊；在其承載控制子系統(tǒng)中設(shè)置發(fā)端承載控制模塊、收端承載控制模塊，該方法包括以下步驟1)呼叫控制子系統(tǒng)的發(fā)端呼叫控制模塊接收發(fā)端用戶發(fā)起的呼叫請求，并發(fā)送給收端呼叫控制模塊；2)呼叫控制子系統(tǒng)的收端呼叫控制模塊向收端用戶轉(zhuǎn)發(fā)該呼叫請求，并將收端用戶后續(xù)接續(xù)狀態(tài)返回給發(fā)端呼叫控制模塊；3)呼叫控制子系統(tǒng)的發(fā)端呼叫控制模塊將收端用戶的接續(xù)狀態(tài)通知發(fā)端用戶；4)承載控制子系統(tǒng)的發(fā)端或收端承載控制子系統(tǒng)接收本端用戶的媒體類型協(xié)商請求，并發(fā)送給對端承載控制子系統(tǒng)；5)承載控制子系統(tǒng)的發(fā)端承載控制模塊與收端承載控制模塊進行交互，根據(jù)該請求進行媒體類型協(xié)商，選擇相同媒體類型的媒體承載通道；6)收端用戶應(yīng)答后，承載控制子系統(tǒng)的發(fā)端承載控制模塊與收端承載控制模塊配合，共同打開選擇的媒體承載通道，控制該媒體類型數(shù)據(jù)信息傳輸。
16.如權(quán)利要求15所述的呼叫處理方法，其特征在于，所述步驟1)進一步包括發(fā)端呼叫控制模塊根據(jù)發(fā)端用戶的呼叫請求，對發(fā)端用戶是否有權(quán)和有能力進行此類型呼叫進行鑒權(quán)；對于通過鑒權(quán)的呼叫請求，收集初始信息，根據(jù)編號計劃判定呼叫類型以及執(zhí)行地址翻譯，確定收端用戶地址；并根據(jù)分析結(jié)果對發(fā)端用戶是否有進行本次呼叫的權(quán)限進行鑒權(quán)；發(fā)端呼叫控制模塊只將通過上述兩次鑒權(quán)的呼叫請求發(fā)送給收端呼叫控制模塊，將鑒權(quán)未通過的呼叫請求丟棄。
17.如權(quán)利要求15所述的呼叫處理方法，其特征在于，所述步驟2)進一步包括收端呼叫控制模塊對收端用戶是否有權(quán)和有能力進行此類型呼叫進行鑒權(quán)，只將通過鑒權(quán)的呼叫請求發(fā)送給收端用戶，將鑒權(quán)未通過的呼叫請求丟棄。
18.如權(quán)利要求15所述的呼叫處理方法，其特征在于，所述步驟4)為在發(fā)端用戶與收端用戶建立連接時，發(fā)端承載控制模塊接收發(fā)端用戶的媒體類型協(xié)商請求，并發(fā)送給收端承載控制模塊，啟動承載控制過程；或收端承載控制模塊接收收端用戶的媒體類型協(xié)商請求，并發(fā)送給發(fā)端承載控制模塊，啟動承載控制過程。
19.如權(quán)利要求15所述的呼叫處理方法，其特征在于，該方法進一步包括對呼叫處理過程進行監(jiān)視，在出現(xiàn)異常情況時結(jié)束呼叫流程。
全文摘要
本發(fā)明公開了一種實現(xiàn)支持多媒體業(yè)務(wù)的軟交換呼叫處理系統(tǒng)，其設(shè)置在軟交換實體中，包含呼叫控制子系統(tǒng)和承載控制子系統(tǒng)；呼叫控制子系統(tǒng)包含發(fā)端呼叫控制模塊和收端呼叫控制模塊；承載控制子系統(tǒng)包含發(fā)端承載控制模塊、收端承載控制模塊、多種媒體承載通道模塊；一種媒體承載通道模塊傳輸一種媒體類型的數(shù)據(jù)信息。本發(fā)明同時公開了一種實現(xiàn)支持多媒體業(yè)務(wù)的軟交換呼叫處理方法，在建立呼叫連接的過程中，先進行媒體類型協(xié)商，再根據(jù)媒體類型選擇相應(yīng)的承載通道進行業(yè)務(wù)數(shù)據(jù)信息傳輸。本發(fā)明適應(yīng)了分組交換網(wǎng)絡(luò)中多媒體業(yè)務(wù)呼叫控制信道與承載通道相互分離的特點，并能對不同承載通道進行單獨控制，滿足控制多媒體業(yè)務(wù)的需要。
文檔編號H04W76/00GK1556644SQ200310123890
公開日2004年12月22日 申請日期2003年12月30日 優(yōu)先權(quán)日2003年12月30日
發(fā)明者楊放春, 孫其博, 姚世民, 于曉燕 申請人:北京郵電大學(xué)