IP傳真分析論文

導語：IP傳真分析論文一文來源于網友上傳，不代表本站觀點，若需要原創文章可咨詢客服老師，歡迎參考。

摘要隨著世界范圍內Internet網絡基礎設施的高速發展，基于ip技術的各種應用，比如IP傳真技術，取得迅速的發展。本文針對目前存在的IP傳真進行了研究與分析，并在此基礎上提出了一種改進方法，能大大地提高IP傳真的成功率和質量。

關鍵詞軟交換，媒體網關，IP傳真

1背景技術

在IP網絡中的傳真按照采用的協議，可以分為兩類：一類是透傳，透傳是把PSTN側的G3傳真機發送的PCM信號直接進行語音編碼，比如采用G711A，G711U編碼，所占用帶寬為64K+IP報頭約80K。另一類是T38[3]傳真，T38傳真會把PCM信號進行解調制，恢復為原來的V.21/V.27/V.17控制/數據流，然后再由主機按照T38協議對解調過的數據進行IP打包，處理后的數據帶寬大約為20K。這兩種傳真方式各有利弊：透傳方式對DSP能力要求不高，但是由于沒有冗余機制，糾錯機制，并且帶寬需求大，對網絡質量和帶寬要求較高；T38傳真對網絡的丟包率具有很好的魯棒性，并且對帶寬要求只有透傳的25%左右，只是對DSP能力需求較大，對TI芯片來說，一路T38編碼所占用的資源，是G711編碼的1.8倍。

2現有IP傳真建立方法分析

2.1現有IP傳真的組網結構

一個IP傳真的組網[6]如圖1所示，其中軟交換和媒體網關是一個VoIP分組交換系統，軟交換本身并沒有通話資源，它是管理媒體網關的設備，通過H.248協議與媒體網關進行交互，它可以控制呼叫的建立與釋放；媒體網關則負責PSTN側的各種事件，比如摘機，掛機，排叉的檢測與上報，通話所需各種資源，比如DSP通道，UDP端口號，用戶側時隙的分配和管理等。

不同于PSTN網絡，IP網絡是一個無連接的網

圖1IP傳真的組網圖

絡，存在著時延，抖動，丟包等較之PSTN網絡惡劣的環境[5]，這些不良因素，將對IP傳真的質量和成功率產生較大影響，為了克服這些不利因素，在網關上采用了設置動態jitbuffer，糾錯[7][8]等措施。

2.2現有IP傳真的建立方法

2.2.1透傳的建立方法

透傳傳真的流程[1]如圖2所示，其中傳真發送方在媒體網關MG1下，傳真接受方在媒體網關MG2下，為了重點說明傳真流程，傳真建立前的通話建立過程加以省略。

圖2透傳傳真的建立過程

(1)軟交換下發命令，要求媒體網關檢測傳真開始事件

(2)媒體網關檢測到傳真接受方用戶按下傳真鍵，上報傳真開始事件

(3)軟交換接收到傳真開始事件，給傳真收發雙方下發指示：切換到傳真模式，并且把靜音檢測關閉掉，如果現在通話用的是G729，G721等壓縮率較大的編碼，那么就把編碼切換到G711編碼(RTP/AVP8)；這幾個步驟對傳真成功起著關鍵作用，切換到傳真模式，會把jitbuffer設置為動態值，能夠根據網絡時延抖動調節jitbuffer的大小，避免造成幀亂序，幀亂序，尤其是控制幀亂序產生的沖突，將會導致傳真失敗的后果。關閉靜音檢測，可以避免網關將一些傳真信號當作噪聲而過濾掉，設置編碼模式為G711，是因為這種編碼模式是一種無損編碼，雖然占用了較大的帶寬，卻可以避免在編碼時對信號造成損傷。

2.2.2T38傳真的建立方法

T38傳真[2]如圖3所示：

圖3T38傳真的建立過程

(1)同透傳傳真

(2)同透傳傳真

(3)軟交換要求傳真雙方切換到傳真模式，設置UDP端口號為語音端口號加2，設置編解碼方式為T38，檢測傳真結束事件

(4)傳真發送方上報傳真結束事件

(5)軟交換要求傳真雙方把UDP端口號設置為語音端口號，恢復DSP的編解碼方式為G711A

其中需要說明的是，設置傳真端口號為語音端口號加2，是因為有的DSP芯片不能支持傳真通道和語音通道共用相同的UDP端口號。

2.3現有IP傳真的劣勢

從圖2和圖3可以看到，對于現有編碼方案來說，必須要軟交換的支持才能把DSP的工作模式切換到傳真模式，設置編碼方式等，如果電信運營商使用的軟交換因為產商或者采購時間較早的原因，只能支持通話的建立，而不能支持傳真的建立，那么在透傳模式下，如果一開始采用的編碼為G729等壓縮率較大，對信號有損傷的編碼，網關不能切換到無損編碼G711，也不會把靜音抑制關閉，把DSP的工作模式設置為傳真模式，這樣由于信號損傷，網絡時延等因素，傳真成功率將會大大下降。采用GenoaTechnology公司的Faxlab，當傳真模型選擇為模擬CanonL777傳真機，傳真發送方Orig:TX3PgECMBestEncV.1714400BestRes，傳真發接收方Ans:RX3PgBestECMBestEncV.3314400BestRes在丟包率為1%，通話語音編碼為G729，并且設置軟交換不檢測傳真信號音以模擬支持傳真的軟交換，這樣模擬20次傳真，其中只有11次成功；如果設置軟交換檢測傳真信號音，那么20次完全可以成功。在T38編碼時，如果設置軟交換不檢測傳真信號音，那么傳真根本就不會切換到T38的編碼方式，還是以開始的語音編碼方式進行傳真，因此效果和透傳是一樣的。所以，很有必要采取一種改進手段，讓媒體網關可以在沒有軟交換支持傳真的情況下，自己把編碼，靜音檢測等參數調整為最佳。

3改進方案的提出

3.1改進思路

媒體網關從功能上可以分為幾大模塊[9]，跟傳真相關的模塊如圖4所示，其中協議處理模塊負責信令的編碼解碼，處理軟交換下發的信令，創建給控制器的信令，并調用業務處理模塊處理相應的業務；業務處理模塊，主要負責呼叫的接續和業務的處理，資源管理模塊主要是對網片資源和DSP資源進行有效的管理，支撐業務的運行；端控模塊主要負責用戶端口消息的處理，并完成協議的轉換，以標準統一的內部原語與業務模塊進行交互，從而屏蔽用戶物理端口的信息；PM模塊還負責用戶物理端口狀態的維護以及用戶端口資源的申請和記錄；驅動模塊則負責對DSP進行操作；對傳真的處理如圖4所示：

圖4媒體網關對傳真的處理

對于T38傳真，處理流程為：

(1)啟動檢測到傳真接收方發送的傳真開始信號，上報給業務模塊

(2)業務通過協議模塊上報傳真開始事件給軟交換

(3)媒體網關下發編碼方式，端口號給業務

(4)業務通過資源管理模塊分配T38所用的全速率資源，下發傳真所用的UDP端口號給驅動，要求驅動打開DSP通道

從處理流程可以看到，媒體網關需要從軟交換獲取編碼方式，傳真端口號，靜音檢測等的設置，控制器發出的信令中的這些設置都是網關上報了傳真開始或者傳真結束事件才下發的，所以，如果傳真發送接收方都能夠監測到傳真開始，結束。我們就可以把這一部分“智能”下移到網關中來。通過這樣的改進，就產生了兩種新的傳真方式，一種是不需要軟交換參與的透傳，叫做自交換透傳，一種是不需要軟交換參與的T38傳真，稱之為自切換T38。

3.2具體方法

3.2.1透傳自切換

如圖1所示，盡管在網關之間的信號是G711編碼信號或者是T38編碼信號，但是在網關之下，IP傳真中傳真發送出去，接收到的信號還是和PSTN網絡中一樣的PCM信號，傳真機信號所遵循的協議也是在PSTN網絡上的傳真協議T.30，根據協議，傳真接收方在發送完被叫用戶標識CED之后，會發送能力標識信號DIS，向發送端標識自己是第三類傳真終端，同時DIS中攜帶了傳真接收終端性能的字段，告知發送終端自己所具有的全部能力，在DIS信號前會有一個長達1秒的前導信號(Preamble)[4]，傳真發送方接受到DIS信號后，會發送DCS信號，根據本終端設置的能力并考慮接收終端所具有的能力，給出本次通信所采用的性能，在DCS前也會有前導信號。在原來的傳真流程里是把DIS前的前導信號作為傳真開始事件的，因此，可以做一個改進，把DIS前和DCS前的前導信號都作為傳真開始信號。驅動上報這個信號后，由業務自己來設置編碼和靜音檢測等，業務模塊的偽碼如下：

if(驅動上報的消息)

{

If(傳真開始消息)

{

設置DSP工作模式為FAX；

設置DSP工作模式為G711；

關閉靜音檢測；

/*透傳模式下傳真端口就是語音端口*/

設置傳真端口號為語音端口號；

調用驅動函數，以設置的參數打開DSP；

}

else

{

……

}

}

else

{

……

}

驅動模塊的偽碼如下：

if(前導信號)

{

if(DIS的前導信號)

{

上報傳真開始信號；

}

elseif(DCS的前導信號)

{

上報傳真開始信號；

}

}

else

{

……

}

3.2.2T38自切換

和透傳自切換相比，T38自切換要復雜，這主要是因為以下三點原因：

(1)傳真接收方上報前導信號后，把自己的編解碼方式切換到T38，而傳真發送方的DSP這是還是普通的語音編解碼方式，如G711，所以無法解碼出T38格式的DIS，因此不會回應DCS，這樣也就沒有DCS的前導信號，傳真發送方就無法上報傳真事件；

(2)T38是專為傳真而設置的一種編碼方式，傳真結束后，一定要切換到語音編碼，否則用戶無法通話。

(3)T38傳真時，端口號可能和語音端口號不同(可能加2)，沒有軟交換的支持，無法告知對方網關自己采用的端口號；

現在Minspeed公司提供的Miro芯片可以檢測到T38報文，因此，傳真發送方可以通過檢測對方發送的DIS的報文為T38格式，來上報傳真開始事件。而對于第三點，我們只能要求兩個網關設置的傳真端口號一致，要么全是語音通道，要么全是語音端口號加2；自切換T38的業務模塊偽碼如下：

if(是驅動上報的傳真開始信號)

{

設置DSP工作模式為FAX；

設置編碼方式為T38；

/*是語音端口加2，還是語音端口*/

根據系統參數設置傳真端口號；

以設置的新參數打開DSP；

}

elseif(是驅動上報的傳真結束信號)

{

恢復傳真前的工作模式，編碼，端口；

}

else

{

……

}

驅動模塊偽碼如下：

if(前導信號)

{

if(DIS的前導信號)

{

上報傳真開始消息；

}

else

{

……

}

}

elseif(T38報文信號)

{

上報傳真開始消息；

}

else

{

……

}

3.3效果驗證

在沒有軟交換支持傳真的情況下，采用GenoaTechnology公司的Faxlab，當傳真模型選擇位模擬CanonL777傳真機，傳真發送方Orig:TX3PgECMBestEncV.1714400BestRes,Ans:RX3PgBestECMBestEncV.3314400BestRes，自切換透傳在丟包率為1%的情況下全部成功；自切換T38在丟包率為10%的情況下可以成功，并且傳真結束后能夠切換到語音通話態。

參考文獻：

ITU-TRFC3015MegacoProtocolVersion1.0.[S]2000.11

ITU-TRFC3525GatewayControlProtocolVersion1.[S]2003.06

TU-TRec.T.38(04/2002)-Prpublishedversion[S]

ITU-TRecommendationT.30:Proceduresfordocumentfacsimiletransmissioninthegeneralswitchedtelephonenetwork[S].1999.04

舒華英,賴平章等.IP電話技術及其應用[M].人民郵電出版社,1999.11

桂海源.IP電話技術與軟交換[M].北京:北京郵電大學出版社,2004.6

中國VOIP論壇相關資料[Z]

黃永峰.因特網語音通信技術及其應用[M].北京:人民郵電出版社.2003.5

張登銀,孫精科.Voip技術分析與系統設計.人民郵電出版社[M].2003.6