專利名稱：Voip網(wǎng)絡中dtmf流的傳輸方法及網(wǎng)關裝置的制作方法
技術領域：
本發(fā)明涉及一種VOIP網(wǎng)絡中傳輸DTMF (Dua-Tone MultiFrequency,雙音多頻) 流時校驗并可靠傳輸?shù)姆椒熬W(wǎng)關裝置，尤其涉及一種使用傳統(tǒng)語音網(wǎng)關時采用壓縮語音在因特網(wǎng)上傳輸帶來的DTMF流的大量丟失的解決方案。
背景技術：
隨著人們需求的不斷提高，各種門禁系統(tǒng)，安防告警系統(tǒng)進入千家萬戶，集成的撥號告警系統(tǒng)在各小區(qū)、辦公大樓、海關等均有大規(guī)模使用，在消息集中傳送途徑上，可以采用無線模式和網(wǎng)絡模式，但使用固定電話線路作為傳輸路徑的系統(tǒng)依然大量存在，主要原因在于電話撥號告警系統(tǒng)的線路無需架設新的資源，與辦公電話系統(tǒng)并行存在，在日常辦公時，該線路作為語音通信存在，而在下班時(即無人辦公時)，才設置為安防模式。同時電話系統(tǒng)的可靠性本來就要高過無線系統(tǒng)等其他環(huán)境。原有的電話線路是采用程控交換的電路交換的物理線路，線路質(zhì)量和可靠性可以達到電信級的標準為99. 9999%，而隨著網(wǎng)絡時代的興起，運營商推廣“光進銅退”的NGN的建設，新裝的固定電話實際上已經(jīng)是VOIP的語音IP電話，而原先的一些程控交換的線路也被改造成了 VOIP線路。眾所周知，VOIP語音時將語音分幀，加上RTP報頭，然后加上UDP報頭，變成IP報文在因特網(wǎng)上傳輸，而IP報文傳輸UDP幀最大的特性就是盡力而為，即不可靠交付，在傳送實時性的語音時，顯然沒有問題，因為人耳的掩蔽效應以及上層應用的再次詢問可以解決語義的識別問題。但對于采用DTMF流進行傳輸?shù)拈T禁安防系統(tǒng)，由于RTP包的丟失造成的 DTMF值的丟失恰恰是不可原諒的?，F(xiàn)有技術未考慮網(wǎng)絡擁塞造成的RTP包丟失，只簡單地將未丟失的包按TS順序輸出，由此在網(wǎng)絡擁塞變化時造成的RTP分組的時延和抖動，最終造成安防撥號系統(tǒng)的DTMF 值的偏差?，F(xiàn)有VOIP語音采用G729A語音編碼，在語音通信上沒有問題，在DTMF流傳輸上出現(xiàn)嚴重頻偏，最終幾乎無法恢復出原始DTMF流，出現(xiàn)“長0”的等待現(xiàn)象；如何既不影響原有語音系統(tǒng)的正常通信，又能滿足作為安防系統(tǒng)的傳輸路徑，即是當前許多電話撥號告警系統(tǒng)在升級時需要迫切解決的問題。

發(fā)明內(nèi)容
本發(fā)明所要解決的技術問題在于針對背景技術的缺陷和不足，提出一種VOIP環(huán)境下的針對DTMF流的可靠傳輸方法，將在因特網(wǎng)中傳輸DTMF流進行分類提取，并開辟只針對DTMF分類的TCP通道，使接收端可以根據(jù)DTMF序列與RTP序列進行比對，最終恢復成最佳的DTMF流輸出。本發(fā)明為解決上述技術問題，采用以下技術方案
一種VOIP網(wǎng)絡中DTMF流的傳輸方法，采用固定電話線路作為傳輸路徑，傳輸過程包括發(fā)送端處理步驟、接收端處理步驟，其中 發(fā)送端處理步驟如下
步驟Al、在發(fā)送端開辟發(fā)送緩沖區(qū)，對輸入的DTMF信號進行采樣并進行編碼，編碼形式選擇常規(guī)語音編碼格式；
步驟A2、對編碼后的碼流進行分幀處理，幀間隔為30ms ；并進行短時功率檢測和過零點處理，并將結(jié)果存入發(fā)送緩沖區(qū)；
步驟A3、根據(jù)步驟A2進行的短時功率檢測和過零點處理結(jié)果，對所有生成的幀進行定性分類，分類的類別為間隔幀、信號幀；
對于間隔幀，按照一個間隔標記對其RTP幀的時間戳進行記錄； 對于信號幀，進行DTMF檢測，對檢測結(jié)果屬于DTMF值的信號幀，按照(TF值的類型對其RTP幀的時間戳進行記錄；
步驟A4、開辟TCP端口，建立TCP通道，如鏈路中斷，則重新握手連接； 步驟A5、將步驟A3中產(chǎn)生的DTMF值按4個比特組成新的緩沖隊列，加上首個DTMF值對應的RTP幀的時間戳生成新的TCP包，發(fā)送到接收端； 接收端處理步驟如下
步驟A6、在接收端開辟兩個接收緩沖區(qū)，其中一個是用于接收TCP流的TCP緩沖區(qū)；另一個是用于接收RTP流的RTP緩沖區(qū)；首先執(zhí)行RTP包的檢測工作，將在一定時間內(nèi)接收的 RTP包按各個報文的時間戳進行緩沖排序，通過校驗RTP幀的時間戳判斷是否發(fā)生RTP丟包；
a,當未發(fā)生丟包現(xiàn)象，TCP緩沖區(qū)接收各RTP包的數(shù)據(jù)進行保存，進入步驟A8 ； b，當發(fā)生丟包現(xiàn)象，則進一步判斷該RTP幀的時間戳在TCP報文內(nèi)是否存在，并獲取 TCP報文中該RTP幀對應時間戳的類值
b-Ι，如果存在，則正常解碼，獲取TCP報文中該丟失的RTP幀對應時間戳的類值，進入步驟A7 ；
b-2，如果不存在，則選擇鄰居報文進行解碼，獲取鄰居報文對應時間戳的類值，根據(jù)該鄰居報文的時間戳在TCP流中查找相應的位置，估計出TCP報文中該丟失的RTP幀對應時間戳的類值，進入步驟A7;
b-3，如果無法獲取鄰居報文對應時間戳的類值，則擴大搜索范圍，在16個RTP報文之內(nèi)，重復b-2進行類值判定；如果16次均失敗，無法進行類值檢測，按照TCP流中的壓縮流的定義，由發(fā)送端網(wǎng)關再造新的DTMF流，返回步驟A6 ；
步驟A7，根據(jù)上一步驟得到的發(fā)生丟包現(xiàn)象的各RTP幀時間戳的類值生成新的RTP報文插入RTP包隊列中去；TCP緩沖區(qū)接收RTP流的數(shù)據(jù)進行保存；
步驟A8，對所有RTP報文中的凈荷進行釋放，恢復輸出原始DTMF流，判斷TCP緩沖區(qū)內(nèi)是否存在DTMF信息
A8-1，當TCP緩沖區(qū)內(nèi)無DTMF信息，則認為信道無DTMF模式，將所有的RTP包進行語音凈荷聚合并進行解壓縮，恢復成原始語音輸出；
A8-2，當TCP緩沖區(qū)內(nèi)有DTMF信息，則根據(jù)對應時間戳檢測TCP緩沖區(qū)內(nèi)的DTMF流與 RTP包里面的對應關系，將兩個序列進行比對 當比對結(jié)果一致，輸出解碼后的DTMF流；當比對結(jié)果不一致，對根據(jù)TCP流中的類值進行DTMF流重構(gòu)，生成新的音頻段后輸出。進一步的，本發(fā)明的VOIP網(wǎng)絡中DTMF流的傳輸方法的步驟A8中在將所述兩個序列進行比對時，還包括檢測是否有RTP包丟失的步驟，按照以下步驟進行處理
如果有一個RTP包丟失，則對相鄰RTP包進行解碼，得出該丟失的RTP包中對應時間戳，進而得到與其對應TCP流中DTMF序列；根據(jù)對應TCP流中DTMF序列判斷該RTP包所對應的音頻信息的類型，然后根據(jù)TCP流中的分類號進行恢復生成一個新的RTP包寫入RTP 接收緩沖區(qū)，并重復A8步驟；
如果有η個連續(xù)RTP包丟失，其中l(wèi)<n<16，同樣對相鄰RTP包進行解碼后進行DTMF序列檢測，并根據(jù)第一 RTP包的和最后一個RTP包的TS區(qū)間，查找TCP緩沖區(qū)內(nèi)DTMF流的記錄，選擇不同概率匹配模型，恢復出原始DTMF流的凈荷。進一步的，本發(fā)明的VOIP網(wǎng)絡中DTMF流的傳輸方法的步驟A8中，如果收發(fā)雙方?jīng)]有發(fā)送DTMF流，則該TCP通道僅發(fā)送填充消息以保證鏈路的有效存在。進一步的，本發(fā)明的VOIP網(wǎng)絡中DTMF流的傳輸方法的步驟A5中，當發(fā)送端檢測到有DTMF值時，需記錄當前時間戳，并生成TCP報文發(fā)送；而直到檢測出現(xiàn)間隔幀，才啟動生成下一個TCP報文。進一步的，本發(fā)明的VOIP網(wǎng)絡中DTMF流的傳輸方法的步驟A6中，如果接收端解碼RTP包時發(fā)現(xiàn)發(fā)送端采用的編碼形式是G729A編碼形式、而TCP接收表明是DTMF流時， 需要根據(jù)DTMF流重新生成音頻信號發(fā)送。本發(fā)明還提出一種VOIP網(wǎng)絡中進行DTMF流傳輸?shù)木W(wǎng)關裝置，包括電源電路、全相整流橋電路、模數(shù)轉(zhuǎn)換單元、中央處理器、串行通信口、網(wǎng)絡通信模塊、存儲器單元；其中所述電源電路用于供電，所述全相整流橋電路的輸入端接入DTMF信號，所述全相整流橋電路的輸出端連接模數(shù)轉(zhuǎn)換電路，所述模數(shù)轉(zhuǎn)換電路與中央處理器連接，所述中央處理器分別與串行通信口、網(wǎng)絡通信模塊、存儲器單元連接。作為本發(fā)明的網(wǎng)關裝置的進一步優(yōu)化方案，還包括與中央處理器連接的狀態(tài)顯示模塊。作為本發(fā)明的網(wǎng)關裝置的進一步優(yōu)化方案，還包括與中央處理器連接的心跳模塊。作為本發(fā)明的網(wǎng)關裝置的進一步優(yōu)化方案，所述存儲器單元包括靜態(tài)隨機存儲器 SRAM、閃存Flash，其中所述靜態(tài)隨機存儲器SRAM、閃存Flash分別與中央處理器連接。本發(fā)明采用以上技術方案與現(xiàn)有技術相比，具有以下技術效果
通過TCP流中的DTMF序列與RTP流的音頻序列的對比，既包含校驗的過程，也包括了誤碼恢復的過程，極大提高了數(shù)據(jù)傳輸?shù)目煽啃?。TCP流由于只記錄兩個間斷之間的DTMF值，而并非30ms就生成一個DTMF值， 因此每產(chǎn)生一個RTP包(最小240個樣值，及240字節(jié))，最多產(chǎn)生一個TCP包(5個字節(jié))， 因此新增網(wǎng)絡流量最大只增加了原先網(wǎng)絡流量2%，由于安防系統(tǒng)的標準是至少50m時長的 DTMF,因此新開的TCP最多只增加了網(wǎng)絡流量的1. 25%。實驗表明在G711的A率和U率的編碼下，網(wǎng)絡擁塞達到70%時，依然可以正確恢復出DTMF流；在G723. 1編碼下，70%的網(wǎng)絡擁塞率，DTMF流恢復正確率為100%，但新的 DTMF流與原始DTMF流有較小差別；在G729A編碼下，70%的網(wǎng)絡擁塞率，DTMF流恢復正確率為100%，但生成的DTMF流與接收端的音頻流則完全不同。本裝置在安防系統(tǒng)的測試下， 與原先程控交換系統(tǒng)的線路相比，輸出碼流達到以下技術指標
(1)電平范圍-4 -23dbm；
(2)高低頻電平差<4db;
(3)頻偏士1. 5% ；
(4)二次諧波比基頻能量至少低20db。


圖1是采用PSTN進行遠程告警信息傳輸?shù)氖疽鈭D。
圖2是本發(fā)明的網(wǎng)關裝置的模塊框圖。
圖3是RTU側(cè)的系統(tǒng)對呼叫的音頻流進行檢測的流程圖。
圖4是起點檢測與標記過程的流程圖。
圖5是起點檢測結(jié)果示例圖。
圖6是RTP包封裝流程圖。
圖7是TCP包生成流程圖。
圖8是TCP連接通信方法示意圖。
圖9是系統(tǒng)接收部分處理流程圖。
圖10是語音IP用戶下發(fā)注冊的DTMF流業(yè)務示意圖。
具體實施例方式下面結(jié)合附圖對本發(fā)明的技術方案做進一步的詳細說明。如說明書附圖1 所示，為采用 PSTN (Public Switched Telephone Network,公用開關電話網(wǎng)絡)進行遠程告警信息傳輸?shù)氖疽鈭D。其中RTU (Remote Terminal Unit，遠端終端單元)負責接入所有的傳感器單元，CTU (Central Terminal Unit，中央終端單元)負責對多個RTU的信息進行采集和下發(fā)指令。出于系統(tǒng)的兼容性，本發(fā)明的網(wǎng)關裝置兼容原先語音網(wǎng)關的VOIP功能，即本裝置與其他非同類型語音網(wǎng)關通信時，如果連續(xù)TCP握手不成功，則認為非同類型設備，則恢復為普通網(wǎng)關狀態(tài)。圖1所示，本發(fā)明的網(wǎng)關裝置在應用于安防系統(tǒng)線路時，根據(jù)使用場景，將分為兩大類場合
場合1，線路改造時采用了企業(yè)自己架設的VOIP語音網(wǎng)關，即向因特網(wǎng)的提供VOIP業(yè)務的SP商申請了 VOIP線路，并設置了自己的告警中心的接入號；此種情況也可以自行搭建 SIP服務器，分配SIP用戶及各自號碼，完成企業(yè)內(nèi)容的VOIP線路。場合1的VOIP線路較差，通常VOIP語音采用的G7^A，在實際通信時DTMF丟失最嚴重。場合2，線路原先申請的是運營商比如電信或網(wǎng)通的線路，此時由于運營商將開展語音IP的軟交換業(yè)務，將帶有寬帶口和語音口的集成本發(fā)明的實現(xiàn)裝置功能的ONU布置到用戶接入。此時ONU的語音口出來的線路表面上與原先一致，在語音傳輸時難以識別，但在安防系統(tǒng)進行撥號系統(tǒng)的DTMF流傳輸時，會出現(xiàn)一定的誤碼率。
在場合1時，本發(fā)明的網(wǎng)關裝置作為單獨的DTMF增強裝置出現(xiàn)，在場合2時，本發(fā)明的網(wǎng)關裝置可以將軟件功能集成到ONU的模塊功能上。本發(fā)明的網(wǎng)關裝置首先完成兼容的SIP語音網(wǎng)關的功能，即具有SIP客戶端注冊， 登記，SIP呼叫等功能，其注冊號碼標識為數(shù)字，以方便其他SIP用戶呼叫。運行在hternet的SIP服務器可以由本發(fā)明的網(wǎng)關裝置的使用者架設開源的SIP 服務器，比如Osip協(xié)議(輕量級)或者OpenSIPS協(xié)議棧(電信級)，也可以使用hternet的 VOIP的SP商提供的VOIP線路，優(yōu)先推薦自己架設的開源SIP協(xié)議棧，原因是SP商提供的 VOIP語音通常都為G7^A，在本系統(tǒng)方案設計中屬于環(huán)境最惡劣情況。而自己獨立架設的 SIP服務器，可以將RTP的語音格式設置成G. 711的A率，甚至是最佳的線性PCM編碼。本發(fā)明的網(wǎng)關裝置作為SIP客戶端登錄至SIP服務器后成為一個在線SIP客戶。 當RTU端發(fā)出撥號請求時，SIP服務器發(fā)出SIP消息邀請，同時向?qū)Χ税l(fā)出TCP連接請求。 呼叫成功后記錄TCP連接狀態(tài)(成功對端是CTU設備；失敗對端是普通SIP客戶端)。線路接通后，當RTU發(fā)出音頻流時，CPU對數(shù)據(jù)幀進行起點檢測是否包含DTMF值， 如是，則打上時間戳(TS)，加上DTMF值，通過TCP通道發(fā)送出去；同時該數(shù)據(jù)幀也經(jīng)過語音編碼后，加上RTP報頭，UDP報頭，打上相同的TS值，作為UDP報文發(fā)送出去。Internet或者IP城域網(wǎng)正常情況下，即網(wǎng)絡未出現(xiàn)擁塞狀況下，TCP報文和RTP 報文都會到達接收端，接收端緩沖區(qū)內(nèi)對所有RTP報文進行排序，將會發(fā)現(xiàn)未出現(xiàn)丟包，則不進行DTMF比對，直接將RTP報文的語音凈荷進行解壓縮恢復。在網(wǎng)絡出現(xiàn)擁塞，不同級別的擁塞狀態(tài)對于不同格式的語音編碼所造成的結(jié)果是不同的。本發(fā)明僅就常規(guī)的G711，G723. 1，G729A三種編碼進行處理。如果發(fā)現(xiàn)有1個RTP包丟失，則對相鄰RTP進行解碼，并進行DTMF檢測，得出檢測結(jié)果；然后對該RTP包中對應TS標識查找TCP接收緩沖區(qū)DTMF流的位置，經(jīng)過相應算法的比對，可以判斷出該RTP包的音頻信息的類型，由此生成一個替代RTP包寫入RTP接收緩沖區(qū)，最終進行解壓縮恢復；
如果發(fā)現(xiàn)有2個以上RTP包丟失，同樣對相鄰RTP進行解碼后進行DTMF檢測，并根據(jù)第一 RTP包的和最后一個RTP包的TS區(qū)間，查找TCP接收緩沖區(qū)內(nèi)DTMF流的記錄，經(jīng)過一系列算法的判斷，最終生成替代的RTP包并插入。在語音編碼為G711，G723. 1時可以執(zhí)行以上操作，在語音編碼為時，由于 G729A是發(fā)生諧振腔參數(shù)模型編碼，對DTMF值的頻偏值非常大，因此在比對TCP緩沖區(qū)的 DTMF流和UDP緩沖區(qū)內(nèi)的RTP流時，可以直接采用將DTMF流的數(shù)據(jù)直接按照50ms的周期間隔重新制造出音頻流發(fā)送出去，前提是比對時發(fā)現(xiàn)RTP流中實在提取不出正確的DTMF信肩、ο本網(wǎng)關裝置因為是雙向通信，因此發(fā)送和接收處理分別由兩個線程完成，加上TCP 過程，一共有三個主要線程處理。本發(fā)明的網(wǎng)關裝置就是解決在VOIP的網(wǎng)絡上傳輸語音的途徑上，可靠保證DTMF 流傳輸?shù)难b置，以及在語音商使用EPON網(wǎng)絡開設的語音IP線路上可靠傳輸DTMF流的裝置。本裝置在網(wǎng)絡中的位置如圖1所示，即由實施此功能的裝置開設TCP流，此TCP流與原先的RTP流通道可以互為比對，從而在概率分布上最大可能實現(xiàn)可靠傳輸。RTP數(shù)據(jù)在丟包情況下由TCP流進行修正，在無法解碼情況下由TCP流完全覆蓋，在TCP流無數(shù)據(jù)情況下與原先系統(tǒng)完全兼容。系統(tǒng)硬件組成如圖2所示，包括電源電路、全相整流橋電路、模數(shù)轉(zhuǎn)換單元、中央處理器、串行通信口、網(wǎng)絡通信模塊、存儲器單元；其中所述電源電路用于供電，所述全相整流橋電路的輸入端接入DTMF信號，所述全相整流橋電路的輸出端連接模數(shù)轉(zhuǎn)換電路，所述模數(shù)轉(zhuǎn)換電路與中央處理器連接，所述中央處理器分別與串行通信口、網(wǎng)絡通信模塊、存儲器單元連接。其中，中央處理器CPU采用TI公司的C5409芯片作為主控芯片，由片外Flash進行代碼段擴充，由外置SDRAM擴大收發(fā)緩沖區(qū)大小。與RTU或CTU相連的電路等同于傳統(tǒng)模擬電話的結(jié)構(gòu)(只不具備語音通話電路)，所述模數(shù)轉(zhuǎn)換單元采用AD50F芯片，負責將模擬信號轉(zhuǎn)換為數(shù)字信號送入DSP總線。網(wǎng)絡通信模塊采用商業(yè)化的集成了 TCP/IP協(xié)議棧的 RTL8019，負責將C5409生成的各種IP包發(fā)送和接收，串行通信口采用MAX232 口作為通信口，可以直接對裝置進行配置和訪問(單機調(diào)試時用)。心跳模塊由PLC16CM負責做外部看門狗電路，定時接收主CPU的心跳信號，在超時的時候進行CPU自動復位，保護主CPU不進入死鎖狀態(tài)。狀態(tài)顯示模塊顯示裝置當前的狀態(tài)，分為連接狀態(tài)，工作狀態(tài)，網(wǎng)絡忙閑狀態(tài)， 對端是否告警狀態(tài)，TCP鏈路連通狀態(tài)。本發(fā)明的網(wǎng)關裝置共分為三大功能塊，分別是A，預處理部分；B，發(fā)送處理部分； C，接收處理部分。A，預處理部分
Al，對獨立裝置無預處理部分，對運營商提供語音IP業(yè)務的ONU來說，可以將本裝置功能軟件集成，但工作前必須由運維人員在運營和維護管理系統(tǒng)(BSS)上進行注冊登記此 DTMF流功能，并由BSS下發(fā)功能到指定的ONU的語音端口(中間經(jīng)過MSCG，0LT以及物理的分光器)，此功能示意如圖10所示。A2，RTU側(cè)的裝置的TCP通道握手的過程，系統(tǒng)開啟TCP端口，根據(jù)下發(fā)信息或者配置信息，向CTU側(cè)的裝置發(fā)出TCP的連接請求，TCP連接后，還需要進行獨立系統(tǒng)的身份認證，身份認證確認后，在系統(tǒng)空閑時會發(fā)送有定時的“心跳”的空信息以保證TCP通道的暢通，由于TCP所占帶寬很小，對網(wǎng)絡帶寬不會影響。此步驟如圖8的上半部分所示，因此此時沒有有用數(shù)據(jù)傳輸。B，發(fā)送處理部分
Bi，主叫RTU側(cè)的系統(tǒng)首先完成VOIP的呼叫，即SIP呼叫或者H. 248呼叫，此處兼容普通語音網(wǎng)關功能，Bl步驟是標準的VOIP的呼叫過程。B2，被叫CTU側(cè)的裝置進行應答，并接通，從而建立起VOIP的RTP通道。B3，RTU側(cè)的系統(tǒng)對呼叫的音頻流進行檢測，工作過程如圖3所示，進行分幀檢測， 以30ms為一幀，通常50%的重疊模式，首先進行短時功率預測和短時過零率檢測，計算后得出該幀是信號幀還是間隔幀，同時對第一個信號幀記錄起點時間戳(4個字節(jié)標識)，具體步驟如圖4所示，起點檢測后的結(jié)果示意舉例如圖5所示。B4,對信號幀進行DTMF檢測，本處采用成熟的Goertzel算法，由于RTU發(fā)送端的信號尚未經(jīng)過網(wǎng)絡等干擾信號，均能檢測出標準的DTMF鍵值，保存為類型碼。B5，并行地，將B3步驟中的幀進行按照裝置的配置要求，如G711，G723. 1，G729A 進行壓縮編碼，并加上12字節(jié)RTP報頭，8字節(jié)UDP報頭，20字節(jié)IP報頭，通過RTL8019發(fā)送出去，如圖6所示。B6,對于已經(jīng)生成的起點檢測序列，以及各端音頻所檢測出來的類型碼，如圖7 所示，將用戶生成TCP報文序列，TCP報文的長度為TCP頭部20字節(jié)加上4個字節(jié)的時間戳和1個字節(jié)的類型碼，其中需要進行判斷，即只有在前一幀是間隔幀而后一幀是信號幀時才進行TCP報文的產(chǎn)生。B7,雖然TCP通道質(zhì)量有保證，但考慮到RTP通道和TCP通道的同時發(fā)送數(shù)據(jù)，有可能出現(xiàn)TCP流滯后的現(xiàn)象，因此在發(fā)送RTP流時會人為滯后250ms，所以同時在TCP流采用了一種新的機制即如果發(fā)送時TCP緩沖區(qū)內(nèi)已經(jīng)產(chǎn)生多個待發(fā)TCP報文，則采用報文重新組裝的形式，將多個TCP報文合并發(fā)送，如果發(fā)送完序號為n+3報文，正準備發(fā)送n+4報文時，收到了 n+1報文的否認，則將n+1報文，n+2，n+3, n+4這四個報文共20個字節(jié)一并生成新的n+1報文發(fā)送，節(jié)約了往返確認的時間。具體過程如圖8下半部分的TCP通信新機制所示。C，接收處理部分
Cl，接收部分與發(fā)送部分是并行雙向處理的部分，接收端開設兩個接收緩沖區(qū)，一個接收的TCP流，格式為時間戳+類值+時間戳+類值；另一個是接收到RTP流緩沖區(qū)，如圖9 上半部分示意。C2，接收部分首先執(zhí)行RTP包的檢測工作，將在一定時間內(nèi)接收的RTP包按各個報文的時間戳進行排序，同時進行RTP包序號的校驗，查看是否發(fā)生了 RTP丟包，無論該包是由于網(wǎng)絡延遲造成還是網(wǎng)絡堵塞造成。C3，如果沒有發(fā)生丟包現(xiàn)象，則完全兼容原有語音網(wǎng)關功能，執(zhí)行步驟C6。C4，如果發(fā)生丟包，則結(jié)合丟包個數(shù)以及根據(jù)初設條件轉(zhuǎn)C5廣C53進行預測處理。C5-1，如果沒有執(zhí)行50%的幀的重疊獲取該TCP報文里的類型值，根據(jù)其值生成一個新的RTP報文，插入到接收RTP包隊列中去，轉(zhuǎn)C6。C5-2，如果執(zhí)行了 50%的幀的重疊，則將前一個RTP幀的后50%疊加后有一個RTP 幀的前50%，轉(zhuǎn)C6步驟。C5-3，如果丟棄多個包，則需要對丟失的RTP的時間戳段進行分析處理，轉(zhuǎn)C8步
馬聚οC6，對所有RTP報文中的凈荷進行釋放，恢復輸出原始DTMF流。C7，與TCP流里面的類值序列進行對比，如果TCP流中無數(shù)據(jù)，則直接輸出；如果有數(shù)據(jù)，則同樣按幀進行起點檢測，如發(fā)現(xiàn)對應起點位置有誤，則用TCP流中的類值生成新的音頻段輸出，結(jié)束。C8，此步驟解決丟失RTP包時間戳不在TCP流中對應，但存在一個區(qū)間內(nèi)的情況。 選擇該邊界RTP包的凈荷，進行壓縮解碼，進行DTMF檢測，并得出其類值，如果能獲得其類值，則根據(jù)其時間戳和類值在TCP報文序列中進行匹配，估算出丟失的RTP包的類值，并生成新的RTP代替包插入RTP流緩沖區(qū)，即再次進入C6 ；如果無法獲取其類值，則擴大搜索范圍，在16個RTP報文之內(nèi)，進行類值判定，重復C8過程；如果16次均失敗，則默認RTP流中的數(shù)據(jù)已經(jīng)發(fā)生嚴重差錯(突發(fā)差錯造成的連續(xù)誤碼)，無法進行類值檢測，則立刻轉(zhuǎn)入C9。C9，按照TCP流中的壓縮流的定義，由C5409再造新的DTMF流，其中兩個類值之間的間隔長度為30ms，即選擇30ms為一幀，其余有用信號的長度均為兩個起點時間戳之差減去30ms的時長。綜上所述，本發(fā)明提供了一個在動態(tài)因特網(wǎng)環(huán)境下的可靠DTMF流傳輸?shù)木W(wǎng)關裝置及具體實現(xiàn)方法，并在軟交換網(wǎng)絡中興通信ZXSSlO軟交換機搭建的網(wǎng)絡中進行測試，測試結(jié)果表明，在G711編碼環(huán)境下，網(wǎng)絡吞吐量達到70%左右，DTMF流依然可以通過TCP流中類值序列進行可靠恢復；在G729A環(huán)境下，網(wǎng)絡吞吐量達到30%左右，DTMF流可以通過TCP 流中類值序列進行可靠恢復，但超過30%，在309Γ70%的范圍內(nèi)，DTMF流需要通過TCP流中類值序列進行全部再造，雖然輸出的DTMF流與發(fā)送的DTMF流在時序和時長上完全不一致， 但DTMF數(shù)據(jù)的解碼正確性是100%。測試結(jié)果表明，采用G723. 1的特性與采用G729A時基本相同。表一是國標規(guī)定的DTMF鍵值分布，且國標規(guī)定了一定的容差范圍。
表1
系統(tǒng)測試表明，此發(fā)明裝置在做完全VOIP通信時與原系統(tǒng)兼容，與未開啟DTMF流增強功能的軟終端X. Iite和multiphone通信時語音通信正常，由此表明本發(fā)明所述的方法具有實踐與轉(zhuǎn)化的意義。
權利要求
1. 一種VOIP網(wǎng)絡中DTMF流的傳輸方法，其特征在于，采用固定電話線路作為傳輸路徑，傳輸過程包括發(fā)送端處理步驟、接收端處理步驟，其中 發(fā)送端處理步驟如下步驟Al、在發(fā)送端開辟發(fā)送緩沖區(qū)，對輸入的DTMF信號進行采樣并進行編碼，編碼形式選擇常規(guī)語音編碼格式；步驟A2、對編碼后的碼流進行分幀處理，幀間隔為30ms ；并進行短時功率檢測和過零點處理，并將結(jié)果存入發(fā)送緩沖區(qū)；步驟A3、根據(jù)步驟A2進行的短時功率檢測和過零點處理結(jié)果，對所有生成的幀進行定性分類，分類的類別為間隔幀、信號幀；對于間隔幀，按照一個間隔標記對其RTP幀的時間戳進行記錄； 對于信號幀，進行DTMF檢測，對檢測結(jié)果屬于DTMF值的信號幀，按照(TF值的類型對其RTP幀的時間戳進行記錄；步驟A4、開辟TCP端口，建立TCP通道，如鏈路中斷，則重新握手連接； 步驟A5、將步驟A3中產(chǎn)生的DTMF值按4個比特組成新的緩沖隊列，加上首個DTMF值對應的RTP幀的時間戳生成新的TCP包，發(fā)送到接收端； 接收端處理步驟如下步驟A6、在接收端開辟兩個接收緩沖區(qū)，其中一個是用于接收TCP流的TCP緩沖區(qū)；另一個是用于接收RTP流的RTP緩沖區(qū)；首先執(zhí)行RTP包的檢測工作，將在一定時間內(nèi)接收的 RTP包按各個報文的時間戳進行緩沖排序，通過校驗RTP幀的時間戳判斷是否發(fā)生RTP丟包；a,當未發(fā)生丟包現(xiàn)象，TCP緩沖區(qū)接收各RTP包的數(shù)據(jù)進行保存，進入步驟A8 ； b，當發(fā)生丟包現(xiàn)象，則進一步判斷該RTP幀的時間戳在TCP報文內(nèi)是否存在，并獲取 TCP報文中該RTP幀對應時間戳的類值b-Ι，如果存在，則正常解碼，獲取TCP報文中該丟失的RTP幀對應時間戳的類值，進入步驟A7 ；b-2，如果不存在，則選擇鄰居報文進行解碼，獲取鄰居報文對應時間戳的類值，根據(jù)該鄰居報文的時間戳在TCP流中查找相應的位置，估計出TCP報文中該丟失的RTP幀對應時間戳的類值，進入步驟A7;b-3，如果無法獲取鄰居報文對應時間戳的類值，則擴大搜索范圍，在16個RTP報文之內(nèi)，重復b-2進行類值判定；如果16次均失敗，無法進行類值檢測，按照TCP流中的壓縮流的定義，由發(fā)送端網(wǎng)關再造新的DTMF流，返回步驟A6 ；步驟A7，根據(jù)上一步驟得到的發(fā)生丟包現(xiàn)象的各RTP幀時間戳的類值生成新的RTP報文插入RTP包隊列中去；TCP緩沖區(qū)接收RTP流的數(shù)據(jù)進行保存；步驟A8，對所有RTP報文中的凈荷進行釋放，恢復輸出原始DTMF流，判斷TCP緩沖區(qū)內(nèi)是否存在DTMF信息A8-1，當TCP緩沖區(qū)內(nèi)無DTMF信息，則認為信道無DTMF模式，將所有的RTP包進行語音凈荷聚合并進行解壓縮，恢復成原始語音輸出；A8-2，當TCP緩沖區(qū)內(nèi)有DTMF信息，則根據(jù)對應時間戳檢測TCP緩沖區(qū)內(nèi)的DTMF流與 RTP包里面的對應關系，將兩個序列進行比對當比對結(jié)果一致，輸出解碼后的DTMF流；當比對結(jié)果不一致，對根據(jù)TCP流中的類值進行DTMF流重構(gòu)，生成新的音頻段后輸出。
2.根據(jù)權利要求1中所述的VOIP網(wǎng)絡中DTMF流的傳輸方法，其特征在于，所述步驟 A8中在將所述兩個序列進行比對時，還包括檢測是否有RTP包丟失的步驟，按照以下步驟進行處理如果有一個RTP包丟失，則對相鄰RTP包進行解碼，得出該丟失的RTP包中對應時間戳，進而得到與其對應TCP流中DTMF序列；根據(jù)對應TCP流中DTMF序列判斷該RTP包所對應的音頻信息的類型，然后根據(jù)TCP流中的分類號進行恢復生成一個新的RTP包寫入RTP 接收緩沖區(qū)，并重復A8步驟；如果有η個連續(xù)RTP包丟失，其中l(wèi)<n<16，同樣對相鄰RTP包進行解碼后進行DTMF序列檢測，并根據(jù)第一 RTP包的和最后一個RTP包的TS區(qū)間，查找TCP緩沖區(qū)內(nèi)DTMF流的記錄，選擇不同概率匹配模型，恢復出原始DTMF流的凈荷。
3.根據(jù)權利要求1中所述的VOIP網(wǎng)絡中DTMF流的傳輸方法，其特征在于，所述步驟 A8中，如果收發(fā)雙方?jīng)]有發(fā)送DTMF流，則該TCP通道僅發(fā)送填充消息以保證鏈路的有效存在。
4.根據(jù)權利要求1中所述的VOIP網(wǎng)絡中DTMF流的傳輸方法，其特征在于，所述步驟 A5中，當發(fā)送端檢測到有DTMF值時，需記錄當前時間戳，并生成TCP報文發(fā)送；而直到檢測出現(xiàn)間隔幀，才啟動生成下一個TCP報文。
5.根據(jù)權利要求1中所述的VOIP網(wǎng)絡中DTMF流的傳輸方法，其特征在于，所述步驟 A6中，如果接收端解碼RTP包時發(fā)現(xiàn)發(fā)送端采用的編碼形式是G729A編碼形式、而TCP接收表明是DTMF流時，需要根據(jù)DTMF流重新生成音頻信號發(fā)送。
6.一種基于權利要求1所述的VOIP網(wǎng)絡中DTMF流的傳輸方法的網(wǎng)關裝置，其特征在于，包括電源電路、全相整流橋電路、模數(shù)轉(zhuǎn)換單元、中央處理器、串行通信口、網(wǎng)絡通信模塊、存儲器單元；其中所述電源電路用于供電，所述全相整流橋電路的輸入端接入DTMF信號，所述全相整流橋電路的輸出端連接模數(shù)轉(zhuǎn)換電路，所述模數(shù)轉(zhuǎn)換電路與中央處理器連接，所述中央處理器分別與串行通信口、網(wǎng)絡通信模塊、存儲器單元連接。
7.根據(jù)權利要求6所述的VOIP網(wǎng)絡中DTMF流的傳輸方法的網(wǎng)關裝置，其特征在于，還包括與中央處理器連接的狀態(tài)顯示模塊。
8.根據(jù)權利要求6所述的VOIP網(wǎng)絡中DTMF流的傳輸方法的網(wǎng)關裝置，其特征在于，還包括與中央處理器連接的心跳模塊。
9.根據(jù)權利要求6所述的VOIP網(wǎng)絡中DTMF流的傳輸方法的網(wǎng)關裝置，其特征在于，所述存儲器單元包括靜態(tài)隨機存儲器(SRAM)、閃存(Flash)，其中所述靜態(tài)隨機存儲器 (SRAM)、閃存(Flash)分別與中央處理器連接。
全文摘要
本發(fā)明公開了一種VOIP網(wǎng)絡中DTMF流的傳輸方法，尤其涉及一種使用傳統(tǒng)語音網(wǎng)關時采用壓縮語音在因特網(wǎng)上傳輸帶來的DTMF流的大量丟失的解決方案。該方法采用固定電話線路作為傳輸路徑，傳輸過程包括發(fā)送端處理步驟、接收端處理步驟，將在因特網(wǎng)中傳輸DTMF流進行分類提取，并開辟只針對DTMF分類的TCP通道，使接收端可以根據(jù)DTMF序列與RTP序列進行比對，最終恢復成最佳的DTMF流輸出。本發(fā)明還公開了一種基于該DTMF流傳輸方法的網(wǎng)關裝置。本發(fā)明通過TCP流中的DTMF序列與RTP流的音頻序列的對比，既包含校驗的過程，也包括了誤碼恢復的過程，極大提高了數(shù)據(jù)傳輸?shù)目煽啃浴?br> 文檔編號H04M7/00GK102420920SQ20111042931
公開日2012年4月18日 申請日期2011年12月20日 優(yōu)先權日2011年12月20日
發(fā)明者林曉勇, 林澤, 王先宇, 肖潔, 邵曦 申請人:南京郵電大學