專利名稱：一種檢測及釋放媒體網(wǎng)關(guān)異常實(shí)時傳輸協(xié)議資源的方法
技術(shù)領(lǐng)域：
本發(fā)明涉及下一代網(wǎng)絡(luò)(NGN，Next Generation Network)技術(shù)領(lǐng)域，具體涉及一種檢測及釋放媒體網(wǎng)關(guān)(MG，Media Gateway)異常實(shí)時傳輸協(xié)議(RTP，Real Transport Protocol)資源的方法。
背景技術(shù)：
軟交換(SoftSwitch)及媒體網(wǎng)關(guān)(MG)分別是下一代網(wǎng)絡(luò)(NGN)中的核心設(shè)備。SoftSwitch主要完成呼叫控制、媒體網(wǎng)關(guān)接入控制、資源分配、協(xié)議處理、路由、認(rèn)證、計費(fèi)等主要功能，并向用戶提供基本話音業(yè)務(wù)、多媒體業(yè)務(wù)、移動業(yè)務(wù)以及多樣化的第三方業(yè)務(wù)；MG則在SoftSwitch的控制下實(shí)現(xiàn)語音媒體流的建立、傳送及釋放。
圖1是現(xiàn)有技術(shù)軟交換和媒體網(wǎng)關(guān)系統(tǒng)組網(wǎng)示意圖，如圖1所示，軟交換通過MEGACO(Media Gateway Control)協(xié)議或MGCP(Media GatewayControl Protocol)協(xié)議來控制媒體網(wǎng)關(guān)完成呼叫過程。當(dāng)媒體網(wǎng)關(guān)MG1上的用戶A和MG2上的用戶B呼叫建立進(jìn)入通話后，在MG1上會建立一個RTP端口，用于把用戶A的語音編碼為RTP媒體流，經(jīng)分組交換網(wǎng)發(fā)送到MG2；該RTP端口資源同時會把來自于MG2上用戶B的RTP媒體流解碼還原為語音送到用戶A。MG2實(shí)現(xiàn)通話的方式和MG1一樣，這樣用戶A和用戶B就可實(shí)現(xiàn)語音的雙向互通。
圖2是現(xiàn)有技術(shù)軟交換控制媒體網(wǎng)關(guān)建立呼叫的過程示意圖；如圖2所示，MG1上的用戶A呼叫MG2上的用戶B時包括步驟201)MG1上用戶A摘機(jī)，MG1上報軟交換；202)軟交換要求MG1對用戶A放拔號音并收號；
203)MG1上的用戶拔號，把所拔的號碼上報軟交換；204)軟交換向MG1發(fā)送命令，請求為用戶A分配一個RTP資源，用于RTP媒體流的處理；205)軟交換向MG2發(fā)送命令，請求用戶B振鈴，并為用戶B分配一個RTP資源，用于RTP媒體流的處理；206)軟交換向MG1發(fā)送命令，請求對用戶A放回鈴音，并修改RTP端口的屬性；207)MG2上的用戶B摘機(jī)，進(jìn)入通話；208)軟交換停止MG1的用戶A的回鈴音，并修改RTP端口的為收發(fā)模式。
209)MG1上的用戶A掛機(jī)；210)軟交換向MG1上的用戶A下發(fā)釋放消息，MG1釋放用戶A及RTP資源，停止媒體流的處理；211)MG2上的用戶B掛機(jī)；212)軟交換向MG2上的用戶B下發(fā)釋放消息，MG2釋放用戶B及RTP資源，停止媒體流的處理。
從流程可以看出，當(dāng)執(zhí)行步驟210)或212)時，若軟交換下發(fā)的釋放消息丟失，或軟交換因?yàn)槟撤N異常沒有向媒體網(wǎng)關(guān)下發(fā)該消息，網(wǎng)關(guān)上的RTP資源就不會被釋放，即通道仍處于收發(fā)媒體流的狀態(tài)，并且該資源一直被占用著。如果過多異常RTP資源沒有釋放，媒體網(wǎng)關(guān)上的RTP資源就會耗盡，新的呼叫將無法建立；另一方面，異常RTP資源仍不停的經(jīng)分組網(wǎng)向另一側(cè)媒體網(wǎng)關(guān)發(fā)送媒體流，影響網(wǎng)絡(luò)的性能，并影響另一側(cè)媒體網(wǎng)關(guān)對應(yīng)的RTP端口上新的呼叫的正常進(jìn)行。
因此媒體網(wǎng)關(guān)和軟交換之間很有必要有一種機(jī)制來對異常情況下的RTP資源進(jìn)行及時的檢測和釋放。
對于異常的RTP資源，傳統(tǒng)的做法是通過人工干預(yù)，發(fā)現(xiàn)異常的RTP資源后人工操作釋放；另一種做法是通過軟交換對媒體網(wǎng)關(guān)的呼叫狀態(tài)定時查詢，有異常的RTP資源進(jìn)行及時釋放。這兩種方法都有不完善的地方，一方面對于媒體網(wǎng)關(guān)及軟交換上同時出現(xiàn)的異常RTP資源，無法得到及時檢測釋放，另一方面，定時查詢加大了軟交換和媒體網(wǎng)關(guān)的信令交互負(fù)荷，影響軟交換及媒體網(wǎng)關(guān)的性能。

發(fā)明內(nèi)容
本發(fā)明要解決的技術(shù)問題是提供一種媒體網(wǎng)關(guān)主動檢測RTP資源是否出現(xiàn)異常并及時釋放在媒體網(wǎng)關(guān)上的異常RTP資源的方法，克服現(xiàn)有技術(shù)當(dāng)媒體網(wǎng)關(guān)和軟交換之間由于網(wǎng)絡(luò)及信令處理異常，引起RTP資源不能正確釋放時必須人工干預(yù)，及媒體網(wǎng)關(guān)及軟交換上同時出現(xiàn)異常RTP資源時無法進(jìn)行檢測和釋放的缺點(diǎn)。
本發(fā)明采用如下的技術(shù)方案一種檢測及釋放媒體網(wǎng)關(guān)異常實(shí)時傳輸協(xié)議資源的方法，其特征在于，包括步驟A、媒體網(wǎng)關(guān)監(jiān)視每一個實(shí)時傳輸協(xié)議端口接收媒體包的時間，若在設(shè)定的時間內(nèi)某個實(shí)時傳輸協(xié)議端口沒有接收到媒體包，媒體網(wǎng)關(guān)向軟交換發(fā)送該實(shí)時傳輸協(xié)議端口出現(xiàn)異常的通知消息；B、如果軟交換上對應(yīng)所述實(shí)時傳輸協(xié)議端口的呼叫不存在，則軟交換回應(yīng)標(biāo)識呼叫不存在的應(yīng)答消息，媒體網(wǎng)關(guān)收到該應(yīng)答消息后，關(guān)閉該實(shí)時傳輸協(xié)議端口，釋放相關(guān)的呼叫資源；如果軟交換上對應(yīng)所述實(shí)時傳輸協(xié)議端口的呼叫存在，則軟交換回應(yīng)正常應(yīng)答消息，媒體網(wǎng)關(guān)收到該應(yīng)答消息后，繼續(xù)執(zhí)行步驟A；C、如果步驟A和B重復(fù)了一定次數(shù)，某個實(shí)時傳輸協(xié)議端口仍沒有收到媒體包，媒體網(wǎng)關(guān)關(guān)閉該實(shí)時傳輸協(xié)議端口，釋放相關(guān)的呼叫資源，向軟交換發(fā)送標(biāo)識呼叫退出的請求消息，軟交換收到該請求消息后，釋放相應(yīng)的呼叫資源。
所述步驟A中的通知消息包括以下字段該實(shí)時傳輸協(xié)議端口的終結(jié)點(diǎn)標(biāo)識、呼叫標(biāo)識及呼叫檢測消息的標(biāo)識。
媒體網(wǎng)關(guān)采用事件觸發(fā)的方式向軟交換報告實(shí)時傳輸協(xié)議端口異常，事件描述符由軟交換在呼叫建立后發(fā)送給媒體網(wǎng)關(guān)。
采用本發(fā)明技術(shù)方案，能夠有效地對異常的RTP資源及時進(jìn)行檢測及釋放；防止異常RTP端口向網(wǎng)絡(luò)上的其它媒體網(wǎng)關(guān)持續(xù)發(fā)送媒體流，從而影響網(wǎng)絡(luò)性能及其它媒體網(wǎng)關(guān)對應(yīng)端口上的正常呼叫的問題，克服了現(xiàn)有技術(shù)當(dāng)RTP資源不能正確釋放時必須人工干預(yù)，及媒體網(wǎng)關(guān)及軟交換上同時出現(xiàn)異常RTP資源時無法進(jìn)行檢測和釋放的缺點(diǎn)。


圖1是現(xiàn)有技術(shù)軟交換和媒體網(wǎng)關(guān)系統(tǒng)組網(wǎng)示意圖；圖2是現(xiàn)有技術(shù)軟交換控制媒體網(wǎng)關(guān)建立呼叫的過程示意圖；圖3是本發(fā)明檢測叫釋放異常RTP資源的流程圖；圖4是本發(fā)明使用MEGACO協(xié)議實(shí)現(xiàn)的信令過程示意圖。
具體實(shí)施例方式
下面結(jié)合附圖和實(shí)施例對本發(fā)明作進(jìn)一步詳細(xì)說明MEGACO協(xié)議是IETF的3525協(xié)議，其采用了分離網(wǎng)關(guān)思想，將原來信令和媒體集中處理的網(wǎng)關(guān)分解為兩部分媒體網(wǎng)關(guān)和軟交換，軟交換通過MEGACO協(xié)議控制MG的動作，軟交換向MG發(fā)出要執(zhí)行的命令，MG執(zhí)行并將結(jié)果返回，軟交換也要處理MG主動上報所發(fā)生的事件請求。MEGACO協(xié)議中的邏輯關(guān)系通過連接模型來表示，連接模型中兩個最基本的構(gòu)件就是關(guān)聯(lián)和終結(jié)點(diǎn)，關(guān)聯(lián)表示了終結(jié)點(diǎn)之間的連接和拓?fù)潢P(guān)系。MEGACO協(xié)議通過包(Package)來描述不同的業(yè)務(wù)屬性，包是可以根據(jù)業(yè)務(wù)的需要進(jìn)行擴(kuò)展的。
軟交換和MG之間的主要命令包括SERVICECHANGE(注冊)，ADD(增加)，MODIFY(修改)，SUBTRACT(刪除)，NOTIFY(通知)等等。
圖3是本發(fā)明檢測叫釋放異常RTP資源的流程圖，圖4是本發(fā)明使用MEGACO協(xié)議實(shí)現(xiàn)的信令過程示意圖，首先定義一個MEGACO協(xié)議的擴(kuò)展包RTPHang，該包中描述檢測RTP端口被掛死的的事件hang，并為hang事件定義一個參數(shù)hangtime，該參數(shù)用于規(guī)定多長時間沒有收到媒體包即認(rèn)為該RTP端口被掛死。
401)呼叫建立后，軟交換即向MG上進(jìn)入呼叫的RTP終結(jié)點(diǎn)發(fā)送一個MODIFY命令，MODIFY命令中包含一個事件描述符，該事件描述符中包含了RTP終結(jié)點(diǎn)在通話過程中長時間沒有收到媒體包的事件，以及多長時間內(nèi)沒有收到任何媒體包即觸發(fā)MG向軟交換上報該事件的時長。信令的形式可以如下MEGACO/1[123.123.123.4]:2944Transaction=9999{Context=789{Modify=RTP0001{Events=2222{RTPHang/hang(hangtime=60)}} } }其中RTP0001為終結(jié)點(diǎn)的名稱；RTPHang/hang檢測長時間沒有收到媒體流的事件；hangtime表示60秒的時長內(nèi)沒有收到任何媒體流，MG需向軟交換上報該事件。
402)MG收到該MODIFY命令后，即開始持續(xù)檢測RTP終結(jié)點(diǎn)長時間沒有收到媒體包的事件。當(dāng)在通話的過程中任何一段時間內(nèi)，在軟交換設(shè)定的時長內(nèi)沒有收到任何媒體包，MG即認(rèn)為該RTP端口可能被掛死，準(zhǔn)備向軟交換用NOITFY命令上報軟交換該事件。在NOTIFY命令，包含有RTP終結(jié)點(diǎn)的標(biāo)識ID、關(guān)聯(lián)ID以及長時間沒有收到媒體包的事件名稱。信令的形式可以如下MEGACO/1[124.124.124.222]:2944 Transaction=10000{Context=789{Notify=RTP0001{ObservedEvents=2222{20050605T22000000:RTPHang/hang}}} }其中RTP0001為終結(jié)點(diǎn)的標(biāo)識ID，Context＝789中的789為關(guān)聯(lián)ID，RTPHang/hang為長時間沒有收到媒體包的事件名稱。
403)軟交換收到該事件，判斷該關(guān)聯(lián)ID以及終結(jié)點(diǎn)ID所在的呼叫是否存在，如果存在，則給MG的應(yīng)答消息中，回應(yīng)一個正常的成功應(yīng)答即可；如果軟交換發(fā)現(xiàn)該關(guān)聯(lián)ID及終結(jié)點(diǎn)ID所在的呼叫在軟交換上已不存在，則回應(yīng)給MG的應(yīng)答消息中包含一個該呼叫不存在的錯誤。信令的形式可以如下MEGACO/1[123.123.123.4]:2944 Reply=10000{Context=789{Notify=RTP0001{Error=600{}}}}其中Error＝600表示關(guān)聯(lián)789以及終結(jié)點(diǎn)RTP0001在軟交換上已不存在它們的呼叫了。
MG收到軟交換的應(yīng)答信令后，如果應(yīng)答是一個成功應(yīng)答，則繼續(xù)檢測長時間沒有收到任何媒體流的事件；如果軟交換返回的應(yīng)答是一個呼叫不存在的應(yīng)答，則關(guān)閉該RTP端口，釋放包括RTP端口在內(nèi)的該呼叫的所有資源，流程到此結(jié)束。
404)MG連續(xù)檢測到長時間沒有收到任何媒體流的事件，重復(fù)402)～～403)十次左右，每次上報軟交換該事件，軟交換總返回MG成功的應(yīng)答，則軟交換上該RTP端口對應(yīng)的呼叫同時也被掛死。MG即直接關(guān)閉該RTP端口，釋放包括RTP端口在內(nèi)的該呼叫的所有資源，并向軟交換發(fā)送SERVICECHANGE命令，命令中包含關(guān)聯(lián)ID，終結(jié)點(diǎn)ID，以及退出呼叫的標(biāo)識方法(Method)為FORCED。信令的形式可以如下MEGACO/1[124.124.124.222]:2944 Transaction=19998{Context=789{ServiceChange=RTP0001{Services{Method=FORCE}} } }軟交換收到該命令也立刻釋放自己呼叫資源。
盡管參照實(shí)施例對使用MEGACO協(xié)議實(shí)現(xiàn)的本發(fā)明，進(jìn)行了圖示和描述，本領(lǐng)域技術(shù)人員將能理解，在不偏離本發(fā)明的范圍和精神的情況下，可以對它進(jìn)行形式和細(xì)節(jié)的種種顯而易見的修改。例如，由于MEGACO協(xié)議和MGCP協(xié)議的相似性，本方法的技術(shù)方案的實(shí)質(zhì)內(nèi)容對于使用MGCP協(xié)議同樣適用。在不脫離本發(fā)明的精神和范圍的情況下，所有的變化和修改都在所附權(quán)利要求書所限定的范圍之內(nèi)。
權(quán)利要求
1.一種檢測及釋放媒體網(wǎng)關(guān)異常實(shí)時傳輸協(xié)議資源的方法，其特征在于，包括步驟A、媒體網(wǎng)關(guān)監(jiān)視每一個實(shí)時傳輸協(xié)議端口接收媒體包的時間，若在設(shè)定的時間內(nèi)某個實(shí)時傳輸協(xié)議端口沒有接收到媒體包，媒體網(wǎng)關(guān)向軟交換發(fā)送該實(shí)時傳輸協(xié)議端口出現(xiàn)異常的通知消息；B、如果軟交換上對應(yīng)所述實(shí)時傳輸協(xié)議端口的呼叫不存在，則軟交換回應(yīng)標(biāo)識呼叫不存在的應(yīng)答消息，媒體網(wǎng)關(guān)收到該應(yīng)答消息后，關(guān)閉該實(shí)時傳輸協(xié)議端口，釋放相關(guān)的呼叫資源；如果軟交換上對應(yīng)所述實(shí)時傳輸協(xié)議端口的呼叫存在，則軟交換回應(yīng)正常應(yīng)答消息，媒體網(wǎng)關(guān)收到該應(yīng)答消息后，繼續(xù)執(zhí)行步驟A；C、如果步驟A和B重復(fù)了一定次數(shù)，某個實(shí)時傳輸協(xié)議端口仍沒有收到媒體包，媒體網(wǎng)關(guān)關(guān)閉該實(shí)時傳輸協(xié)議端口，釋放相關(guān)的呼叫資源，向軟交換發(fā)送標(biāo)識呼叫退出的請求消息，軟交換收到該請求消息后，釋放相應(yīng)的呼叫資源。
2.根據(jù)權(quán)利要求1所述的檢測及釋放媒體網(wǎng)關(guān)異常實(shí)時傳輸協(xié)議資源的方法，其特征在于所述步驟A中的通知消息包括以下字段該實(shí)時傳輸協(xié)議端口的終結(jié)點(diǎn)標(biāo)識、呼叫標(biāo)識及呼叫檢測消息的標(biāo)識。
3.根據(jù)權(quán)利要求2所述的檢測及釋放媒體網(wǎng)關(guān)異常實(shí)時傳輸協(xié)議資源的方法，其特征在于媒體網(wǎng)關(guān)采用事件觸發(fā)的方式向軟交換報告實(shí)時傳輸協(xié)議端口異常，事件描述符由軟交換在呼叫建立后發(fā)送給媒體網(wǎng)關(guān)。
全文摘要
一種檢測及釋放媒體網(wǎng)關(guān)異常實(shí)時傳輸協(xié)議資源的方法，包括步驟A.媒體網(wǎng)關(guān)監(jiān)視每一個RTP端口接收媒體包的時間，若在設(shè)定的時間內(nèi)某個RTP端口沒有接收到媒體包，媒體網(wǎng)關(guān)向軟交換發(fā)送通知消息；B.如果軟交換上對應(yīng)RTP端口的呼叫不存在，則軟交換回應(yīng)標(biāo)識呼叫不存在的應(yīng)答消息，媒體網(wǎng)關(guān)收到該應(yīng)答消息后，關(guān)閉RTP端口，釋放呼叫資源；如果軟交換上對應(yīng)RTP端口的呼叫存在，則軟交換回應(yīng)正常應(yīng)答消息，媒體網(wǎng)關(guān)收到該應(yīng)答消息后，繼續(xù)執(zhí)行步驟A；C.如果步驟A和B重復(fù)了一定次數(shù)，某個RTP端口仍沒有收到媒體包，媒體網(wǎng)關(guān)關(guān)閉該RTP端口，釋放呼叫資源，向軟交換發(fā)送標(biāo)識呼叫退出的請求消息，軟交換收到該請求消息后，釋放相應(yīng)的呼叫資源。
文檔編號H04L29/06GK1897622SQ200510035758
公開日2007年1月17日 申請日期2005年7月14日 優(yōu)先權(quán)日2005年7月14日
發(fā)明者喬克智, 程寧, 費(fèi)秀峰 申請人:中興通訊股份有限公司