專利名稱：一種媒體網(wǎng)關(guān)間的雙音多頻信號(hào)的參數(shù)協(xié)商方法及系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信技術(shù)領(lǐng)域，尤其是涉及一種媒體網(wǎng)關(guān)間的雙音多頻信 號(hào)的參數(shù)協(xié)商方法及系統(tǒng)。
背景技術(shù)：
在無線第三代通信網(wǎng)絡(luò)(WCDMA， CDMA2000, TD-SCDMA)和下一代網(wǎng)絡(luò) (NGN)的核心網(wǎng)電路域中，都采用了承載與控制分離的思想和組網(wǎng)方式， 其主要網(wǎng)元為媒體網(wǎng)關(guān)(MGW)和網(wǎng)關(guān)控制器(MGC)。媒體網(wǎng)關(guān)提供媒體流的控制功能，主要為承載的建立與維護(hù)、接續(xù)控 制、語音編碼處理和轉(zhuǎn)換等等。網(wǎng)關(guān)控制器提供呼叫控制和移動(dòng)性管理等 功能，主要包括呼叫控制流程、用戶鑒權(quán)、計(jì)費(fèi)等。H. 248/Megaco協(xié)議聯(lián)系MGC和MGW，是目前主流的媒體網(wǎng)關(guān)控制協(xié)議； MGC之間通過承載無關(guān)呼叫控制協(xié)議(BICC)對(duì)呼叫的建立、修改和釋放 等流程進(jìn)行控制；MGW之間的媒體面數(shù)據(jù)傳輸目前用的最多的是RTP/IP承 載；IP承載控制協(xié)議(IPBCP)是WCDMA和TD-SCDMA核心網(wǎng)MGW之間RTP/IP 承載的主要控制協(xié)議； 一種典型的IPBCP隧道消息機(jī)制的原理架構(gòu)如圖1 所示，MGC1和MGC2通過Nc接口 (支持BICC協(xié)議)連接，MGW1和MGW2 通過Nb接口連接，MGC和MGW之間則通過Mc接口 (支持H.248協(xié)議)連 接。IP承載控制協(xié)議是通過由H. 248和BICC協(xié)議提供的隧道機(jī)制在MGW 之間傳輸RTP/IP承載參數(shù)，以完成承載控制。DTMF (Dual Tone Multi-Frequency:雙音多頻)在傳統(tǒng)通信領(lǐng)域中被 廣泛使用，DTMF的傳輸方式有1、通過通信協(xié)議傳輸，如H.323， MGCP， SIP等;2、通過RTP (Real-time Transport Protocol:實(shí)時(shí)傳輸協(xié)議) 的數(shù)據(jù)內(nèi)容傳輸，DTMF模擬成語音；3、根據(jù)RFC2833，使用RTP的包傳輸。 第一種方法主要缺陷是因?yàn)榭刂菩帕詈兔襟w傳輸(RTP)是分開傳輸，很容 易造成DTMF信號(hào)和媒體包不同步。其他兩種方法是在RTP媒體傳輸中攜帶DTMF信號(hào)，因而沒有DTMF信號(hào)和媒體流不同步的問題。DTMF信號(hào)用專門的RTP包傳輸，在RTP包的頭域中就可得知該包是 DTMF包，并且知道是什么DTMF信號(hào)，標(biāo)準(zhǔn)組織IETF制定了 RFC2833標(biāo)準(zhǔn)， 專門對(duì)此有定義。DTMF信號(hào)用RFC2833幀在媒體流傳輸?shù)南嚓P(guān)參數(shù)通過SDP 來指示。但是由于MGC之間用于呼叫管理的BICC信令沒有SDP的協(xié)商能力，因 此一個(gè)呼叫涉及的MGW是否支持DTMF的RFC2833幀傳輸以及相關(guān)參數(shù)無法 在MGC之間得到協(xié)商。目前只能靠在相關(guān)MGW上設(shè)置DTMF的RFC2833幀傳 輸能力相關(guān)的配置來解決；這既降低了靈活度，同時(shí)也大大增加了系統(tǒng)的 維護(hù)難度；因?yàn)橐坏﹥蓚€(gè)MGW之間配置不一致，就會(huì)造成數(shù)據(jù)傳輸不正確。發(fā)明內(nèi)容有鑒于此，本發(fā)明提出了一種媒體網(wǎng)關(guān)間的雙音多頻信號(hào)的參數(shù)協(xié)商 方法及系統(tǒng)，能夠方便的在MGC之間進(jìn)行RFC2833幀傳輸以及相關(guān)參數(shù) 的協(xié)商。為了解決上述技術(shù)問題，本發(fā)明采用了如下技術(shù)方案 一種媒體網(wǎng)關(guān)間的雙音多頻信號(hào)的參數(shù)協(xié)商方法，包含如下步驟A、 在IP承載控制協(xié)議隧道消息中設(shè)置雙音多頻信號(hào)的配置參數(shù);B、 媒體網(wǎng)關(guān)間通過IP承載控制協(xié)議隧道消息進(jìn)行交互，根據(jù)其中的 雙音多頻信號(hào)的配置參數(shù)進(jìn)行協(xié)商處理。所述步驟B在IP承載建立過程中具體按如下方式進(jìn)行 Bll、第一媒體網(wǎng)關(guān)獲取本端雙音多頻信號(hào)的配置參數(shù)，通過IP承載 控制協(xié)議的承載建立請(qǐng)求隧道消息發(fā)送給第二媒體網(wǎng)關(guān)；B12、第二媒體網(wǎng)關(guān)比較本端與對(duì)端的雙音多頻信號(hào)的配置參數(shù)，并 根據(jù)比較結(jié)果選擇支持雙音多頻信號(hào)傳輸、參數(shù)修改后支持雙音多頻信 號(hào)傳輸、不支持雙音多頻信號(hào)傳輸三種應(yīng)答之一響應(yīng)給第一媒體網(wǎng)關(guān)；且 第二媒體網(wǎng)關(guān)按比較結(jié)果選擇的傳輸方式建立本端的IP承載連接；B13、第一媒體網(wǎng)關(guān)根據(jù)第二媒體網(wǎng)關(guān)的應(yīng)答結(jié)果選擇支持雙音多 頻信號(hào)傳輸、參數(shù)修改后支持雙音多頻信號(hào)傳輸、不支持雙音多頻信號(hào)傳 輸三種方式之一建立本端的IP承載連接。所述步驟B在IP承載修改過程中具體按如下方式進(jìn)行.-B21、主叫媒體網(wǎng)關(guān)獲取本端雙音多頻信號(hào)的配置參數(shù)，通過IP承載 控制協(xié)議的承載修改請(qǐng)求隧道消息發(fā)送給被叫媒體網(wǎng)關(guān)；B22、被叫媒體網(wǎng)關(guān)比較本端與對(duì)端的雙音多頻信號(hào)的配置參數(shù)，并 根據(jù)比較結(jié)果選擇支持雙音多頻信號(hào)傳輸、參數(shù)修改后支持雙音多頻信 號(hào)傳輸、不支持雙音多頻信號(hào)傳輸三種應(yīng)答之一響應(yīng)給主叫媒體網(wǎng)關(guān)；且 被叫媒體網(wǎng)關(guān)按比較結(jié)果選擇的傳輸方式進(jìn)行本端的IP承載修改；B23、主叫媒體網(wǎng)關(guān)根據(jù)被叫媒體網(wǎng)關(guān)的應(yīng)答結(jié)果選擇支持雙音多 頻信號(hào)傳輸、參數(shù)修改后支持雙音多頻信號(hào)傳輸、不支持雙音多頻信號(hào)傳 輸三種方式之一進(jìn)行本端的IP承載修改。所述雙音多頻信號(hào)的配置參數(shù)包括是否支持雙音多頻信號(hào)的 RFC2833幀傳輸及雙音多頻信號(hào)的載荷類型，所述參數(shù)修改是指對(duì)雙音多 頻信號(hào)的載荷類型進(jìn)行修改。所述步驟A設(shè)置雙音多頻信號(hào)的配置參數(shù)通過設(shè)置IP承載控制協(xié)議 隧道消息中的會(huì)話描述協(xié)議信息的媒體聲明和媒體屬性參數(shù)實(shí)現(xiàn)。本發(fā)明還公開了一種媒體網(wǎng)關(guān)間的雙音多頻信號(hào)的參數(shù)協(xié)商系統(tǒng)，包 含雙音多頻信號(hào)參數(shù)配置模塊，所述雙音多頻信號(hào)參數(shù)配置模塊用于在IP 承載控制協(xié)議隧道消息中設(shè)置雙音多頻信號(hào)的配置參數(shù)；媒體網(wǎng)關(guān)間通過 IP承載控制協(xié)議隧道消息進(jìn)行交互，根據(jù)其中的雙音多頻信號(hào)的配置參數(shù) 進(jìn)行協(xié)商處理。所述的參數(shù)協(xié)商系統(tǒng)，媒體網(wǎng)關(guān)間在IP承載建立過程中的協(xié)商處理方 式為第一媒體網(wǎng)關(guān)獲取本端雙音多頻信號(hào)的配置參數(shù)，通過IP承載控制 協(xié)議的承載建立請(qǐng)求隧道消息發(fā)送給第二媒體網(wǎng)關(guān)；第二媒體網(wǎng)關(guān)比較本 端與對(duì)端的雙音多頻信號(hào)的配置參數(shù)，并根據(jù)比較結(jié)果選擇支持雙音多 頻信號(hào)傳輸、參數(shù)修改后支持雙音多頻信號(hào)傳輸、不支持雙音多頻信號(hào)傳 輸三種應(yīng)答之一響應(yīng)給第一媒體網(wǎng)關(guān)；且第二媒體網(wǎng)關(guān)按比較結(jié)果選擇的 傳輸方式建立本端的IP承載連接；第一媒體網(wǎng)關(guān)根據(jù)第二媒體網(wǎng)關(guān)的應(yīng)答 結(jié)果選擇支持雙音多頻信號(hào)傳輸、參數(shù)修改后支持雙音多頻信號(hào)傳輸、 不支持雙音多頻信號(hào)傳輸三種方式之一建立本端的IP承載連接。所述的參數(shù)協(xié)商系統(tǒng)，媒體網(wǎng)關(guān)間在IP承載修改過程中的協(xié)商處理方式為主叫媒體網(wǎng)關(guān)獲取本端雙音多頻信號(hào)的配置參數(shù)，通過IP承載控制 協(xié)議的承載修改請(qǐng)求隧道消息發(fā)送給被叫媒體網(wǎng)關(guān)；被叫媒體網(wǎng)關(guān)比較本 端與對(duì)端的雙音多頻信號(hào)的配置參數(shù)，并根據(jù)比較結(jié)果選擇支持雙音多 頻信號(hào)傳輸、參數(shù)修改后支持雙音多頻信號(hào)傳輸、不支持雙音多頻信號(hào)傳 輸三種應(yīng)答之一響應(yīng)給主叫媒體網(wǎng)關(guān)；且被叫媒體網(wǎng)關(guān)按比較結(jié)果選擇的 傳輸方式進(jìn)行本端的IP承載修改；主叫媒體網(wǎng)關(guān)根據(jù)被叫媒體網(wǎng)關(guān)的應(yīng)答 結(jié)果選擇支持雙音多頻信號(hào)傳輸、參數(shù)修改后支持雙音多頻信號(hào)傳輸、 不支持雙音多頻信號(hào)傳輸三種方式之一進(jìn)行本端的IP承載修改。所述的參數(shù)協(xié)商系統(tǒng)，所述雙音多頻信號(hào)的配置參數(shù)包括是否支持雙 音多頻信號(hào)的RFC2833幀傳輸及雙音多頻信號(hào)的載荷類型，所述參數(shù)修改 是指對(duì)雙音多頻信號(hào)的載荷類型進(jìn)行修改。所述的參數(shù)協(xié)商系統(tǒng)，所述雙音多頻信號(hào)參數(shù)配置模塊設(shè)置雙音多頻 信號(hào)的配置參數(shù)是通過設(shè)置IP承載控制協(xié)議隧道消息中的會(huì)話描述協(xié)議 信息的媒體聲明和媒體屬性參數(shù)實(shí)現(xiàn)的。本發(fā)明通過在IP承載控制協(xié)議隧道消息中設(shè)置雙音多頻信號(hào)的配置 參數(shù)；從而使得媒體網(wǎng)關(guān)可以利用IP承載控制協(xié)議隧道消息進(jìn)行雙音多頻 信號(hào)的配置參數(shù)的協(xié)商處理。協(xié)商實(shí)現(xiàn)方法簡單，有利于系統(tǒng)維護(hù)。


圖1是典型的IPBCP隧道消息機(jī)制的原理架構(gòu)示意圖；圖2是本發(fā)明具體實(shí)施方式
的IP承載建立過程中的DTMF的RFC2833幀傳輸參數(shù)協(xié)商的示意圖；圖3是本發(fā)明具體實(shí)施方式
的IP承載修改過程中的DTMF的RFC2833幀傳輸參數(shù)協(xié)商的示意圖。
具體實(shí)施方式
下面對(duì)照附圖并結(jié)合具體實(shí)施方式
對(duì)本發(fā)明做詳細(xì)說明。本發(fā)明所要解決的是電路域媒體網(wǎng)關(guān)之間DTMF的RFC2833幀傳輸機(jī)制 的相關(guān)參數(shù)在媒體網(wǎng)關(guān)之間無法協(xié)商的問題。由于IPBCP協(xié)議通過在H. 248和BICC協(xié)議中提供的隧道機(jī)制，使得局間兩個(gè)MGW之間可以相互發(fā)送IPBCP的隧道消息以達(dá)到傳遞承載相關(guān)信息 的目的。這也為DTMF的RFC2833幀在MGW之間傳遞的參數(shù)協(xié)商提供了可能。為此，本發(fā)明主要采用了以下幾個(gè)方面的處理1. 在IPBCP的隧道消息設(shè)置支持RFC2833對(duì)SDP格式的要求。2. 在IPBCP的IP承載建立(IP Bearer establishment)過程的隧道消息 中攜帶RFC2833參數(shù)進(jìn)行協(xié)商。3. 在IPBCP的IP承載修改(IP Bearer modification)過程的隧道消息 中攜帶RFC2833參數(shù)進(jìn)行協(xié)商。4. MGW上的IPBCP協(xié)議處理部分將協(xié)商后的RFC2833相關(guān)參數(shù)下發(fā)給 RTP/IP協(xié)議棧處理以支持相應(yīng)的DTMF的RFC2833幀傳輸功能。下面分別對(duì)上述幾個(gè)方面進(jìn)行描述1. IPBCP隧道消息格式定義為實(shí)現(xiàn)RFC2833的參數(shù)協(xié)商，首先需要清晰的定義IPBCP隧道消息中 的SDP信息格式。RFC2833相關(guān)信息只影響IPBCP隧道消息中SDP的以下 部分攀媒體聲明(Media Announcement) m二〈media〉 <port〉 <transport> <fmt list> 其中，<fmt list〉可以為多個(gè)載荷類型(Payload Type)的聲明列表。
媒體屬性(Media attributes)每個(gè)〈fmt list〉中的動(dòng)態(tài)載荷類型需要有一個(gè)媒體屬性說明，格式如下a=rtpmap:<payload〉〈encoding name〉/〈clock rate〉[/<encoding parameters"另外還需支持RFC2833的DTMF列表聲明 a=fmtp:<format〉 <list of values〉其中，〈format〉為DTMF的動(dòng)態(tài)載荷類型值，必須是在媒體聲明的〈fmt list〉已經(jīng)聲明過。〈list of values〉為需要檢測的事件，0 15事件都必 須支持檢測，可以省略。2. 如圖2所示，IP承載建立過程中的RFC2833協(xié)商包括① .根據(jù)呼叫業(yè)務(wù)的需求，MGW1上的IPBCP開始發(fā)起MGW局間RTP/IP 承載的建立，預(yù)留所需資源，獲取本MGW是否支持DTMF的RFC2833幀傳輸能力配置信息。② .如果IPBCP發(fā)現(xiàn)本MGW支持DTMF的RFC2833幀傳輸，則在承載建 立請(qǐng)求的隧道消息中攜帶RFC2833信息。 一個(gè)WCDMA CN中的隧道消息舉例 如下v二0o二- 0 1 IN IP4 1. 2. 3. 4s二0c二IN IP4 1. 2. 3. 4 t二0 0a二ipbcp:l Request m二audio 5304 RTP/AVP 96 100 a二rtpmap:96 VND. 3GPP. IUFP/16000 a二fmtp:100 0-15(D.MGW2上的IPBCP收到發(fā)過來的隧道消息后，解析消息發(fā)現(xiàn)對(duì)端要 求此次呼叫支持DTMF的RFC2833幀。這種情況下，IPBCP首先獲取本MGW 的能力配置，看是否支持DTMF的RFC2833幀傳輸功能。根據(jù)支持情況，有 以下三種處理i. MGW2支持DTMF的RFC2833功能并且載荷類型與MGW1隧道消息 中的一致IPBCP向RTP/IP協(xié)議處理發(fā)送請(qǐng)求，攜帶IP地址等參數(shù)以 及MGW1隧道消息中的RFC2833信息，建立承載連接。ii. MGW2支持DTMF的RFC2833功能并且載荷類型與MGW1隧道消 息中的不一致ipbcp向rtp/ip協(xié)議處理發(fā)送請(qǐng)求，攜帶ip地址等參 數(shù)以及MGW2中的RFC2833信息，建立承載連接。iii. MGW2不支持DTMF的RFC2833傳輸功能IPBCP向RTP/IP協(xié) 議處理發(fā)送請(qǐng)求，攜帶IP地址等參數(shù)，建立承載連接。不傳遞RFC2833 信息c . IPBCP成功的要求RTP/IP協(xié)議處理建立了承載連接后，向MGW1發(fā) 送應(yīng)答隧道消息。根據(jù)本MGW2是否支持DTMF的RFC22833幀傳輸功能及MGW2支持DTMF載荷類型與MGW1隧道消息中的是否一致，有以下三種處理情況i. MGW2支持DTMF的RFC2833幀傳輸功能并且DTMF載荷類型與 MGW1隧道消息中的一致IPBCP在應(yīng)答隧道消息中將收到的隧道消息中 媒體聲明和媒體屬性信息原樣發(fā)回到MGW1。舉例對(duì)于②中請(qǐng)求消息 示例，應(yīng)答隧道消息為 v=0o=- 0 1 IN IP4 1. 2. 3. 5s=0c二IN IP4 1. 2. 3. 5 t=0 0a=ipbcp:l Accept m二audio 5004 RTP/AVP 96 100 a=rtpmap:96 VND, 3GPP.IUFP/16000 a=fmtp:100 0_15i i. MGW2支持DTMF的RFC2833傳輸功能并且DTMF載荷類型與MGWl 隧道消息中的不一致IPBCP對(duì)MGWl發(fā)來的隧道消息中的媒體聲明和 媒體屬性加以修改，將MGW2支持的DTMF載荷類型作為媒體屬性信息， 其他媒體聲明和媒體屬性信息保持不變，發(fā)回隧道應(yīng)答到MGW1。舉例: 對(duì)于②中請(qǐng)求消息示例，應(yīng)答隧道消息為 v二Oo=- 0 1 IN IP4 1. 2. 3. 5s=0c二IN IP4 1. 2. 3. 5 t=0 0a=ipbcp:l Accept m=audio 5004 RTP/AVP 96 127 a=rtpmap:96 VND. 3GPP. IUFP/16000 a=fmtp:127 0—15iii. MGW2不支持DTMF的RFC2833傳輸功能IPBCP對(duì)MGW1發(fā)來 的隧道消息中的媒體聲明和媒體屬性加以修改，去除RFC2833信息，僅 將其他編解碼信息隨應(yīng)答隧道消息傳回MGW1。舉例對(duì)于②中請(qǐng)求消 息示例，應(yīng)答隧道消息為 v=0o=- 0 1 IN IP4 1.2. 3. 5s=0c=IN IP4 1. 2. 3. 5 t二0 0a二ipbcp:l Accept m二audio 5004 RTP/AVP 96 a二rtpmap:96 VND. 3GPP. IUFP/16000可以看出，MGW1通過"m=audio 5004 RTP/AVP 96 100"指示自身的 載荷類型為100，而MGW2針對(duì)不同的支持情況產(chǎn)生不同的應(yīng)答，在第一種 處理中是原樣發(fā)回，在第二種處理中MGW2則通過"m=audio 5004 RTP/AVP 96 127"回應(yīng)自身的載荷類型為127，在第三種處理中，MGW2的應(yīng)答消息 則去除該反映載荷類型的參數(shù)及"a=fmtp:100 0-15"。 . MGW1的IPBCP收到MGW2發(fā)來的應(yīng)答隧道消息。根據(jù)其中是否攜帶 回了 RFC2833信息及DTMF的載荷類型是否變化，分以下三種處理i. 隧道消息中攜帶回了 RFC2833信息并且DTMF載荷類型沒有變 化說明MGW2支持DTMF的RFC2833幀傳輸。IPBCP向RTP/IP協(xié)議處 理發(fā)送請(qǐng)求，攜帶IP地址等參數(shù)以及MGW2隧道消息中的RFC2833信息，建立承載連接。ii. 隧道消息中攜帶回了 RFC2833信息并且DTMF載荷類型變化 說明MGW2支持DTMF的RFC2833幀傳輸功能，但是載荷類型與MGW1不 同。IPBCP向RTP/IP協(xié)議處理發(fā)送請(qǐng)求，攜帶IP地址等參數(shù)以及MGW2 隧道消息中的RFC2833信息，建立承載連接。iii. 隧道消息中沒有攜帶RFC2833信息說明MGW2不支持DTMF 的RFC2833幀傳輸功能。IPBCP向RTP/IP協(xié)議處理發(fā)送請(qǐng)求，攜帶IP 地址等參數(shù)，建立承載連接。不支持DTMF的RFC2833幀傳輸功能。3.如圖3所示，IP承載修改過程中的RFC2833協(xié)商包括① .根據(jù)呼叫業(yè)務(wù)的需求，MGW1上的IPBCP判斷需要改變此呼叫DTMF 的RFC2833傳輸功能的開關(guān)狀態(tài)，則開始發(fā)起MGW局間RTP/IP承載的修改， 預(yù)留所需資源，獲取本MGW是否支持DTMF的RFC2833傳輸能力配置信息。 為防止兩個(gè)MGW同時(shí)發(fā)起修改請(qǐng)求，本發(fā)明由承載建立時(shí)的發(fā)起端(本例 中為MGW1)發(fā)起此種承載修改。② .根據(jù)不同的情況發(fā)送承載修改請(qǐng)求消息i.呼叫當(dāng)前沒有開啟DTMF的RFC2833傳輸功能，IPBCP根據(jù)判斷 需要支持DTMF的RFC2833幀傳輸，且本MGW支持RFC2833幀傳輸功能， 發(fā)送承載修改請(qǐng)求消息到MGW2，攜帶RFC2833信息。ii.呼叫當(dāng)前已開啟DTMF的RFC2833幀傳輸功能，IPBCP根據(jù)判斷 不再需要支持DTMF的RFC2833幀傳輸，則發(fā)送承載修改請(qǐng)求消息到 MGW2，不攜帶RFC2833信息，只攜帶實(shí)際媒體編解碼信息。③ .MGW2上的IPBCP收到發(fā)過來的隧道消息后，根據(jù)其中是否攜帶了 RFC2833信息，有以下不同處理i.隧道消息中沒有RFC2833信息IPBCP向RTP/IP協(xié)議處理發(fā)送 請(qǐng)求，關(guān)閉DTMF的RFC2833幀傳輸功能。ii.隧道消息中攜帶有RFC2833信息IPBCP檢査本MGW配置1. 如果本MGW支持DTMF的RFC2833幀傳輸功能并且DTMF的載 荷類型與收到的隧道請(qǐng)求消息中的DTMF載荷類型一致，則向RTP/IP 協(xié)議處理發(fā)送請(qǐng)求，開啟DTMF的RFC2833幀傳輸功能。2. 如果本MGW支持DTMF的RFC2833幀傳輸功能并且DTMF的載 荷類型與收到的隧道請(qǐng)求消息中的DTMF載荷類型不一致，則向 RTP/IP協(xié)議處理發(fā)送請(qǐng)求，開啟DTMF的RFC2833幀傳輸功能(其 中DTMF載荷類型為MGW2端載荷類型)。3. 如果不支持，則不做任何動(dòng)作。④ .MGW2上的IPBCP向MGW1發(fā)送應(yīng)答隧道消息，有以下幾種情況i. MGW1在隧道消息中攜帶了 RFC2833信息，但是MGW2的配置不 支持，或者配置支持發(fā)起修改但未成功，則MGW2的IPBCP向MGW1應(yīng)答 一個(gè)拒絕(Reject)隧道消息。ii. MGW1在隧道消息中攜帶了 RFC2833信息，MGW2配置為支持且 修改成功，則MGW2的IPBCP向MGW1應(yīng)答一個(gè)接受(Acc印t)隧道消息， 其中RFC2833幀中DTMF載荷類型為MGW2側(cè)DTMF的載荷類型。iii. MGW1在隧道消息中沒有攜帶RFC2833信息，且MGW2關(guān)閉DTMF 的RFC2833傳輸功能成功，貝U MGW2的IPBCP向MGW1應(yīng)答一個(gè)接受(Acc印t)隧道消息，其中不攜帶RFC2833信息。iv. MGW1在隧道消息中沒有攜帶RFC2833信息，但MGW2關(guān)閉DTMF 的RFC2833傳輸功能失敗，則MGW2的IPBCP向MGW1應(yīng)答一個(gè)拒絕(Reject)隧道消息。MGW1的IPBCP收到MGW2發(fā)來的應(yīng)答隧道消息。根據(jù)此消息是接受 還是拒絕做如下不同的處理i. 隧道消息為"接受"如果本次修改為開啟RFC2833功能，則向 RTP/IP協(xié)議處理要求開啟DTMF的RFC2833幀傳輸功能，其中DTMF載 荷類型為MGW2的隧道消息中DTMF載荷類型。如果本次修改為關(guān)閉DTMF 的RFC2833傳輸功能，則向RTP/IP協(xié)議處理發(fā)送關(guān)閉此功能的請(qǐng)求。 修改流程結(jié)束。ii. 隧道消息為"拒絕"如果本次修改為開啟RFC2833功能，或 者本次修改為關(guān)閉RFC2833功能，則不做任何動(dòng)作，修改流程結(jié)束?？偨Y(jié)本發(fā)明具體實(shí)施方式
的媒體網(wǎng)關(guān)間的雙音多頻信號(hào)的參數(shù)協(xié)商方 法，其主要是首先在IP承載控制協(xié)議隧道消息中設(shè)置雙音多頻信號(hào)的配置 參數(shù)；然后媒體網(wǎng)關(guān)間通過IP承載控制協(xié)議隧道消息進(jìn)行交互，根據(jù)其中 的雙音多頻信號(hào)的配置參數(shù)進(jìn)行協(xié)商處理。從而實(shí)現(xiàn)了對(duì)一個(gè)呼叫涉及的 MGW是否支持DTMF的RFC2833幀傳輸以及相關(guān)參數(shù)的協(xié)商。實(shí)現(xiàn)方法簡單， 易于對(duì)系統(tǒng)的維護(hù)。本發(fā)明具體實(shí)施方式
的一種媒體網(wǎng)關(guān)間的雙音多頻信號(hào)的參數(shù)協(xié)商系 統(tǒng)，包含雙音多頻信號(hào)參數(shù)配置模塊，雙音多頻信號(hào)參數(shù)配置模塊用于在 IP承載控制協(xié)議隧道消息中設(shè)置雙音多頻信號(hào)的配置參數(shù)；媒體網(wǎng)關(guān)間通 過IP承載控制協(xié)議隧道消息進(jìn)行交互，根據(jù)其中的雙音多頻信號(hào)的配置參 數(shù)進(jìn)行協(xié)商處理。所述的參數(shù)協(xié)商系統(tǒng)，媒體網(wǎng)關(guān)間在IP承載建立過程中的協(xié)商處理方式為第一媒體網(wǎng)關(guān)獲取本端雙音多頻信號(hào)的配置參數(shù)，通過IP承載控制 協(xié)議的承載建立請(qǐng)求隧道消息發(fā)送給第二媒體網(wǎng)關(guān)；第二媒體網(wǎng)關(guān)比較本 端與對(duì)端的雙音多頻信號(hào)的配置參數(shù)，并根據(jù)比較結(jié)果選擇支持雙音多頻 信號(hào)傳輸、參數(shù)修改后支持雙音多頻信號(hào)傳輸中支持雙音多頻信號(hào)傳輸三 種應(yīng)答之一響應(yīng)給第一媒體網(wǎng)關(guān)；第一媒體網(wǎng)關(guān)根據(jù)第二媒體網(wǎng)關(guān)的應(yīng)答 結(jié)果選擇雙音多頻信號(hào)傳輸、參數(shù)修改后支持雙音多頻信號(hào)傳輸中支持雙 音多頻信號(hào)傳輸三種方式之一建立IP承載連接。所述的參數(shù)協(xié)商系統(tǒng)，媒體網(wǎng)關(guān)間在IP承載修改過程中的協(xié)商處理方 式為主叫媒體網(wǎng)關(guān)獲取本端雙音多頻信號(hào)的配置參數(shù)，通過IP承載控制 協(xié)議的承載建立請(qǐng)求隧道消息發(fā)送給被叫媒體網(wǎng)關(guān)；被叫媒體網(wǎng)關(guān)比較本 端與對(duì)端的雙音多頻信號(hào)的配置參數(shù)，并根據(jù)比較結(jié)果選擇支持雙音多頻 信號(hào)傳輸、參數(shù)修改后支持雙音多頻信號(hào)傳輸中支持雙音多頻信號(hào)傳輸三 種應(yīng)答之一響應(yīng)給主叫媒體網(wǎng)關(guān)；主叫媒體網(wǎng)關(guān)根據(jù)被叫媒體網(wǎng)關(guān)的應(yīng)答 結(jié)果選擇雙音多頻信號(hào)傳輸、參數(shù)修改后支持雙音多頻信號(hào)傳輸中支持雙 音多頻信號(hào)傳輸三種方式之一進(jìn)行IP承載修改。上述的雙音多頻信號(hào)的配置參數(shù)包括是否支持雙音多頻信號(hào)的 RFC2833幀傳輸及雙音多頻信號(hào)的載荷類型，參數(shù)修改是指對(duì)雙音多頻信 號(hào)的載荷類型進(jìn)行修改。雙音多頻信號(hào)參數(shù)配置模塊設(shè)置雙音多頻信號(hào)的 配置參數(shù)是通過設(shè)置IP承載控制協(xié)議隧道消息中的會(huì)話描述協(xié)議信息的 媒體聲明和媒體屬性參數(shù)實(shí)現(xiàn)的。需要了解，上文中的第一媒體網(wǎng)關(guān)和主叫媒體網(wǎng)關(guān)都是指代MGW1， 第二媒體網(wǎng)關(guān)和被叫媒體網(wǎng)關(guān)都是指代MGW2，之所以出現(xiàn)兩種名稱，主 要是為了強(qiáng)調(diào)在IP承載修改過程中的協(xié)商處理中，協(xié)商首先是由發(fā)起端發(fā) 起的，以防止兩個(gè)MGW同時(shí)發(fā)起修改請(qǐng)求。以上內(nèi)容是結(jié)合具體的優(yōu)選實(shí)施方式對(duì)本發(fā)明所作的進(jìn)一步詳細(xì)說 明，不能認(rèn)定本發(fā)明的具體實(shí)施只局限于這些說明。對(duì)于本發(fā)明所屬技術(shù) 領(lǐng)域的普通技術(shù)人員來說，在不脫離本發(fā)明構(gòu)思的前提下，還可以做出若 干簡單推演或替換，都應(yīng)當(dāng)視為屬于本發(fā)明的保護(hù)范圍。
權(quán)利要求
1.一種媒體網(wǎng)關(guān)間的雙音多頻信號(hào)的參數(shù)協(xié)商方法，其特征在于，包含如下步驟A、在IP承載控制協(xié)議隧道消息中設(shè)置雙音多頻信號(hào)的配置參數(shù)；B、媒體網(wǎng)關(guān)間通過IP承載控制協(xié)議隧道消息進(jìn)行交互，根據(jù)其中的雙音多頻信號(hào)的配置參數(shù)進(jìn)行協(xié)商處理。
2. 如權(quán)利要求1所述的參數(shù)協(xié)商方法，其特征在于，所述步驟B在 IP承載建立過程中具體按如下方式進(jìn)行Bll、第一媒體網(wǎng)關(guān)獲取本端雙音多頻信號(hào)的配置參數(shù)，通過IP承載 控制協(xié)議的承載建立請(qǐng)求隧道消息發(fā)送給第二媒體網(wǎng)關(guān)；B12、第二媒體網(wǎng)關(guān)比較本端與對(duì)端的雙音多頻信號(hào)的配置參數(shù)，并 根據(jù)比較結(jié)果選擇支持雙音多頻信號(hào)傳輸、參數(shù)修改后支持雙音多頻信 號(hào)傳輸、不支持雙音多頻信號(hào)傳輸三種應(yīng)答之一響應(yīng)給第一媒體網(wǎng)關(guān)；且 第二媒體網(wǎng)關(guān)按比較結(jié)果選擇的傳輸方式建立本端的IP承載連接；B13、第一媒體網(wǎng)關(guān)根據(jù)第二媒體網(wǎng)關(guān)的應(yīng)答結(jié)果選擇支持雙音多 頻信號(hào)傳輸、參數(shù)修改后支持雙音多頻信號(hào)傳輸、不支持雙音多頻信號(hào)傳 輸三種方式之一建立本端的IP承載連接。
3. 如權(quán)利要求1所述的參數(shù)協(xié)商方法，其特征在于，所述步驟B在 IP承載修改過程中具體按如下方式進(jìn)行B21、主叫媒體網(wǎng)關(guān)獲取本端雙音多頻信號(hào)的配置參數(shù)，通過IP承載 控制協(xié)議的承載修改請(qǐng)求隧道消息發(fā)送給被叫媒體網(wǎng)關(guān)；B22、被叫媒體網(wǎng)關(guān)比較本端與對(duì)端的雙音多頻信號(hào)的配置參數(shù)，并 根據(jù)比較結(jié)果選擇支持雙音多頻信號(hào)傳輸、參數(shù)修改后支持雙音多頻信 號(hào)傳輸、不支持雙音多頻信號(hào)傳輸三種應(yīng)答之一響應(yīng)給主叫媒體網(wǎng)關(guān)；且 被叫媒體網(wǎng)關(guān)按比較結(jié)果選擇的傳輸方式進(jìn)行本端的IP承載修改；B23、主叫媒體網(wǎng)關(guān)根據(jù)被叫媒體網(wǎng)關(guān)的應(yīng)答結(jié)果選擇支持雙音多 頻信號(hào)傳輸、參數(shù)修改后支持雙音多頻信號(hào)傳輸、不支持雙音多頻信號(hào)傳 輸三種方式之一進(jìn)行本端的IP承載修改。
4. 如權(quán)利要求2或3所述的參數(shù)協(xié)商方法，其特征在于，所述雙音多頻信號(hào)的配置參數(shù)包括是否支持雙音多頻信號(hào)的RFC2833幀傳輸及雙音 多頻信號(hào)的載荷類型，所述參數(shù)修改是指對(duì)雙音多頻信號(hào)的載荷類型進(jìn)行 修改。
5. 如權(quán)利要求1至3任一所述的參數(shù)協(xié)商方法，其特征在于，所述步 驟A設(shè)置雙音多頻信號(hào)的配置參數(shù)通過設(shè)置IP承載控制協(xié)議隧道消息中 的會(huì)話描述協(xié)<議信息的媒體聲明和媒體屬性參數(shù)實(shí)現(xiàn)。
6. —種媒體網(wǎng)關(guān)間的雙音多頻信號(hào)的參數(shù)協(xié)商系統(tǒng)，其特征在于，包 含雙音多頻信號(hào)參數(shù)配置模塊，所述雙音多頻信號(hào)參數(shù)配置模塊用于在IP 承載控制協(xié)議隧道消息中設(shè)置雙音多頻信號(hào)的配置參數(shù)；媒體網(wǎng)關(guān)間通過 IP承載控制協(xié)議隧道消息進(jìn)行交互，根據(jù)其中的雙音多頻信號(hào)的配置參數(shù) 進(jìn)行協(xié)商處理。
7. 如權(quán)利要求6所述的參數(shù)協(xié)商系統(tǒng)，其特征在于，媒體網(wǎng)關(guān)間在 IP承載建立過程中的協(xié)商處理方式為第一媒體網(wǎng)關(guān)獲取本端雙音多頻信 號(hào)的配置參數(shù)，通過IP承載控制協(xié)議的承載建立請(qǐng)求隧道消息發(fā)送給第二 媒體網(wǎng)關(guān)；第二媒體網(wǎng)關(guān)比較本端與對(duì)端的雙音多頻信號(hào)的配置參數(shù)，并 根據(jù)比較結(jié)果選擇支持雙音多頻信號(hào)傳輸、參數(shù)修改后支持雙音多頻信 號(hào)傳輸、不支持雙音多頻信號(hào)傳輸三種應(yīng)答之一響應(yīng)給第一媒體網(wǎng)關(guān);且 第二媒體網(wǎng)關(guān)按比較結(jié)果選擇的傳輸方式建立本端的IP承載連接；第一媒 體網(wǎng)關(guān)根據(jù)第二媒體網(wǎng)關(guān)的應(yīng)答結(jié)果選擇支持雙音多頻信號(hào)傳輸、參數(shù) 修改后支持雙音多頻信號(hào)傳輸、不支持雙音多頻信號(hào)傳輸三種方式之一建 立本端的IP承載連接。
8. 如權(quán)利要求6所述的參數(shù)協(xié)商系統(tǒng)，其特征在于，媒體網(wǎng)關(guān)間在 IP承載修改過程中的協(xié)商處理方式為主叫媒體網(wǎng)關(guān)獲取本端雙音多頻信 號(hào)的配置參數(shù)，通過IP承載控制協(xié)議的承載修改請(qǐng)求隧道消息發(fā)送給被叫 媒體網(wǎng)關(guān)；被叫媒體網(wǎng)關(guān)比較本端與對(duì)端的雙音多頻信號(hào)的配置參數(shù)，并 根據(jù)比較結(jié)果選擇支持雙音多頻信號(hào)傳輸、參數(shù)修改后支持雙音多頻信 號(hào)傳輸、不支持雙音多頻信號(hào)傳輸三種應(yīng)答之一響應(yīng)給主叫媒體網(wǎng)關(guān)；且 被叫媒體網(wǎng)關(guān)按比較結(jié)果選擇的傳輸方式進(jìn)行本端的IP承載修改；主叫媒 體網(wǎng)關(guān)根據(jù)被叫媒體網(wǎng)關(guān)的應(yīng)答結(jié)果選擇支持雙音多頻信號(hào)傳輸、參數(shù) 修改后支持雙音多頻信號(hào)傳輸、不支持雙音多頻信號(hào)傳輸三種方式之一進(jìn) 行本端的IP承載修改。
9. 如權(quán)利要求7或8所述的參數(shù)協(xié)商系統(tǒng)，其特征在于，所述雙音多 頻信號(hào)的配置參數(shù)包括是否支持雙音多頻信號(hào)的RFC2833幀傳輸及雙音 多頻信號(hào)的載荷類型，所述參數(shù)修改是指對(duì)雙音多頻信號(hào)的載荷類型進(jìn)行 修改。
10. 如權(quán)利要求6至8任一所述的參數(shù)協(xié)商系統(tǒng)，其特征在于，所述 雙音多頻信號(hào)參數(shù)配置模塊設(shè)置雙音多頻信號(hào)的配置參數(shù)是通過設(shè)置IP 承載控制協(xié)議隧道消息中的會(huì)話描述協(xié)議信息的媒體聲明和媒體屬性參數(shù) 實(shí)現(xiàn)的。
全文摘要
本發(fā)明公開了一種媒體網(wǎng)關(guān)間的雙音多頻信號(hào)的參數(shù)協(xié)商方法及系統(tǒng)，所述方法包含如下步驟A.在IP承載控制協(xié)議隧道消息中設(shè)置雙音多頻信號(hào)的配置參數(shù)；B.媒體網(wǎng)關(guān)間通過IP承載控制協(xié)議隧道消息進(jìn)行交互，根據(jù)其中的雙音多頻信號(hào)的配置參數(shù)進(jìn)行協(xié)商處理。所述系統(tǒng)包含雙音多頻信號(hào)參數(shù)配置模塊，所述雙音多頻信號(hào)參數(shù)配置模塊用于在IP承載控制協(xié)議隧道消息中設(shè)置雙音多頻信號(hào)的配置參數(shù)；媒體網(wǎng)關(guān)間通過IP承載控制協(xié)議隧道消息進(jìn)行交互，根據(jù)其中的雙音多頻信號(hào)的配置參數(shù)進(jìn)行協(xié)商處理。本發(fā)明的雙音多頻信號(hào)的配置參數(shù)的協(xié)商實(shí)現(xiàn)方法簡單，有利于系統(tǒng)維護(hù)。
文檔編號(hào)H04Q7/38GK101336002SQ20081014267
公開日2008年12月31日 申請(qǐng)日期2008年7月29日 優(yōu)先權(quán)日2008年7月29日
發(fā)明者娜 唐 申請(qǐng)人:中興通訊股份有限公司