UMG8900產(chǎn)品黃埔培訓(xùn)系列教材-10 問題定位-語音類

UMG8900產(chǎn)品問題定位-語音類ISSUE1.0參考資料UMG8900業(yè)務(wù)類-固網(wǎng)監(jiān)聽業(yè)務(wù)維護(hù)指導(dǎo)手冊.docUMG8900語音類-2833特性維護(hù)指導(dǎo)手冊.docUMG8900語音類-單通問題維護(hù)指導(dǎo)手冊.docUMG8900語音類-放音收號問題維護(hù)指導(dǎo)手冊.docUMG8900語音類-回聲問題維護(hù)指導(dǎo)手冊.docUMG8900語音類-語音問題維護(hù)指導(dǎo)手冊.docUMG8900語音類-噪音問題指導(dǎo)手冊.doc學(xué)習(xí)完此課程，您將會：了解噪音、回聲等語音類問題的詳細(xì)處理方法目標(biāo)第1章噪音問題定位第2章單通問題定位第3章回聲問題定位第4章2833問題定位內(nèi)容介紹第1章噪音問題定位1.1常見噪音問題種類及簡介1.2純TDM路徑下噪音問題1.3IP-TDM路徑下的噪音問題內(nèi)容介紹1.1常見噪音問題種類及簡介從已知的情況分析，產(chǎn)生噪音的來源有以下幾個：UMG8900的TDM時鐘不穩(wěn)，導(dǎo)致噪音。打開丟包補(bǔ)償?shù)那闆r下IP網(wǎng)絡(luò)丟包超過5%，或者未打開丟包補(bǔ)償時存在丟包。使用了G.711編解碼，但打開了VAD開關(guān)。目前G.711VAD的實現(xiàn)方法五花八門，互通性很差。一般情況下，如果網(wǎng)絡(luò)中存在多種設(shè)備，比如UMG8900，TMG，IAD，Videophone等，且需要使用G.711編解碼，則VAD開關(guān)應(yīng)該關(guān)閉。其他編解碼，如G.729，G.723不存在互通性問題，可以打開VAD開關(guān)。話路中的EC產(chǎn)生噪音。PSTN側(cè)引入的噪音，即到達(dá)UMG-TG之前，噪音已經(jīng)存在。第1章噪音問題定位1.1常見噪音問題種類及簡介

1.2純TDM路徑下噪音問題1.3IP-TDM路徑下的噪音問題內(nèi)容介紹1.2純TDM路徑下噪音問題純TDM路徑下噪音問題可大致分為以下幾種常見情況：通話過程中持續(xù)出現(xiàn)噪音呼叫建立過程中放智能音或者提示音時出現(xiàn)噪聲被叫摘機(jī)瞬間出現(xiàn)噪音對問題進(jìn)行分析之前，首先應(yīng)該判斷一下噪音是否是由UMG8900設(shè)備引入的。出現(xiàn)噪音時，將呼叫保持住，在呼叫占用的TDM路徑上進(jìn)入UMG8900設(shè)備和出UMG8900設(shè)備的TDM接口板上分別做外環(huán)回和內(nèi)環(huán)回（環(huán)回具體操作請參考：《UMG8900常用定位手段-UMG8900環(huán)回操作指導(dǎo)手冊》），根據(jù)環(huán)回測試結(jié)果，可以確認(rèn)噪音是否由UMG8900設(shè)備引入。如果做端口環(huán)回，首先要確認(rèn)該端口是否配置有信令或者半永久，因為端口環(huán)回之后可能引起信令或者半永久中斷定位噪音引入點1.2純TDM路徑下噪音問題判斷噪音引入點的簡單方法：環(huán)回和錄音確定噪音是否來自UMG具體方法請參考黃埔課程《UMG8900產(chǎn)品常用定位手段》定位噪音引入點1.2純TDM路徑下噪音問題【問題描述】通話過程中持續(xù)出現(xiàn)噪音，TNU記錄的系統(tǒng)日志中有ILCfailed相關(guān)字樣，或者出現(xiàn)ILCCHECKFAULT（ALM_ID831）。【產(chǎn)生原因】UMG8900內(nèi)出現(xiàn)ILC校驗失敗【處理方法】檢測系統(tǒng)時鐘，是否處于跟蹤態(tài)，先排除時鐘不同步的問題根據(jù)系統(tǒng)日志或者告警中的提示查看TNU/TCLU和哪個單板之間出現(xiàn)ILC校驗失敗，先更換對應(yīng)的接口板，如果仍出現(xiàn)ILC檢測失敗的日志或者告警，那么再更換記錄系統(tǒng)日志或者上報告警的對應(yīng)的TNU/TCLU單板。通話過程中持續(xù)出現(xiàn)噪音處理1.2純TDM路徑下噪音問題【問題描述】呼叫建立過程中放智能音或者提示音時出現(xiàn)噪聲【產(chǎn)生原因】語音文件引入【處理方法】重新制作語音文件，更換問題語音文件呼叫建立過程中放智能音或者提示音時出現(xiàn)噪聲1.2純TDM路徑下噪音問題【問題描述】被叫摘機(jī)瞬間出現(xiàn)噪音【產(chǎn)生原因】可能由于TDM聯(lián)網(wǎng)引入【處理方法】這個需要將E10表或者其他儀器串在E1上，然后指定時隙呼叫，用儀器對這個指定的時隙進(jìn)行錄音操作，然后對錄音文件進(jìn)行分析。這一步處理比較復(fù)雜，請聯(lián)系研發(fā)解決。如果條件允許的情況下可以嘗試倒換一下中心交換框的TNU單板被叫摘機(jī)瞬間出現(xiàn)噪音第1章噪音問題定位1.1常見噪音問題種類及簡介

1.2純TDM路徑下噪音問題1.3IP-TDM路徑下的噪音問題內(nèi)容介紹TDM到IP呼叫媒體流1.3IP-TDM路徑下的噪音問題【問題描述】NGN側(cè)用戶聽到噪音【問題確認(rèn)】如果確認(rèn)不是用戶電話機(jī)的問題，請按照下面的解決步驟進(jìn)行.【問題分析】PSTN側(cè)到NGN的信號本身就有噪聲，噪聲由IP網(wǎng)絡(luò)引起。NGN側(cè)用戶聽到噪音1.3IP-TDM路徑下的噪音問題【問題解決】AG處理方法(畫一下UMG的AG組網(wǎng))步驟1

對相應(yīng)通道錄音，具體操作參見《UMG8900常用定位手段-錄音操作指導(dǎo)手冊》。步驟2 (如果是AG的情況下執(zhí)行)使用CoolEdit軟件打開該文件，聽聲音（看波形），確認(rèn)是否有噪音。如果聲音清晰，沒有噪音，則一般情況下，噪音應(yīng)該出在RSP框或者用戶線（比如RSP的小網(wǎng)未拆，或者用戶線受干擾等）。如果錄音文件中已經(jīng)聽到噪音，則繼續(xù)定位。步驟3 確認(rèn)沒有使用帶VAD的G.711編解碼。只有兩端都是UMG8900的情況下，才可以使用帶VAD的G.711編解碼。否則，應(yīng)該關(guān)閉G.711的VAD開關(guān)。UMG8900使用的編解碼可以通過LSTTCPARA得到。其他設(shè)備的編解碼需要其他手段。NGN側(cè)用戶聽到噪音1.3IP-TDM路徑下的噪音問題步驟4

在MML上使用PING命令，Ping出問題的承載地址。參數(shù)填寫如下：板類型選“HRB”，板組號選擇出問題通話承載所在的HRB板組號，PING報文個數(shù)設(shè)置為32個，節(jié)點域名或IP地址填寫對方（可能是UMG8900-TG）的承載IP地址，PING報文長度填寫盡量接近出問題會話所使用的編解碼的報文大小的，比如G.71120ms，就填寫214，G.72920ms則填寫74（可以在Ethernet的抓包中查出），超時時間取缺省值即可。如果IP網(wǎng)絡(luò)在打開丟包補(bǔ)償?shù)那闆r下丟包超過5%，或者在存在未打開丟包補(bǔ)償?shù)那闆r下丟包（即使不足1%，），則用戶會聽到噪音。查看是否打開了丟包補(bǔ)償?shù)拿顬長STTCPARA察看。NGN側(cè)用戶聽到噪音1.3IP-TDM路徑下的噪音問題步驟5

使用DSPCLK命令，確認(rèn)TG的時鐘處于“跟蹤”狀態(tài)。如果處于“自由振蕩”，則可能產(chǎn)生噪音、單通。步驟6

使用DSPNETCLKSIG，察看NET板時鐘鎖相環(huán)是不是處于"鎖定"狀態(tài)。如果處于非鎖定（LOSS）狀態(tài)，則同樣會產(chǎn)生噪音、單通。NGN側(cè)用戶聽到噪音1.3IP-TDM路徑下的噪音問題步驟7

執(zhí)行DSPSLIP命令，察看該會話是否存在大量滑碼。如果是，則滑碼可能是造成問題的原因。此時，執(zhí)行DSPCLK命令確認(rèn)UMG8900的時鐘是否處于跟蹤狀態(tài)。如果處于跟蹤狀態(tài)則應(yīng)該是對端的問題，否則需要配置UMG8900鎖定線路時鐘。此時需要參考如下命令：//配置時鐘，線路時鐘作為時鐘參考源。MODCLK:BRDTYPE=CLK,MODE=AUTO,GRADE=TWO,CTRL=NO,CLKMODE=SOURCE;//配置時鐘，從0號和1號E32板端口0提取線路時鐘。SETLINECLK:LINE=LINE1,BT=E32,BN=0,PN=0;確認(rèn)時鐘的參考源是否正確。如果正確，但是仍然有滑碼，則應(yīng)該是對端的問題，需要對端確認(rèn)問題原因。如果時鐘參考源不正確，修改為正確的參考源即可。NGN側(cè)用戶聽到噪音滑碼介紹滑動（slip）：在同步傳輸或準(zhǔn)同步傳輸?shù)谋忍亓髦杏捎诰彌_存儲器的讀寫速率不一致造成一組比特丟失或重復(fù)插入的現(xiàn)象，稱為滑動?；瑒臃譃槭芸鼗瑒雍头鞘芸鼗瑒印Ｏ旅嫖覀円訣1芯片為例，看看滑動產(chǎn)生的原因。E1接收芯片從輸入信號中提取時鐘，做為緩沖存儲器的寫時鐘，而系統(tǒng)時鐘做為緩沖存儲器的讀時鐘。緩沖存儲器的容量至少為一幀。當(dāng)寫入和讀出的速率一致時，緩沖存儲器不會發(fā)生溢出，任何小于緩沖存儲器長度的讀/寫時鐘相位差的變化都會被吸收，不影響通信。.過大的相位變化，或者讀、寫時鐘頻率不一致，則會導(dǎo)致緩沖存儲器的上溢或者下溢。當(dāng)讀出速率小于寫入速率時，會發(fā)生漏讀，丟失一幀信息，當(dāng)讀出速率大于寫入速率時，會發(fā)生重讀?；瑒影l(fā)生的兩個基本原因：第一、鏈路中時鐘間的頻率同步不好，導(dǎo)致時鐘頻率的差別；第二、鏈路中的相位移動（抖動和漂移）或主鐘和從鐘間的相位移動。1.3IP-TDM路徑下的噪音問題【問題描述】打通電話后PSTN側(cè)用戶聽到噪音【問題分析】可能是下面問題造成：話機(jī)本身質(zhì)量問題外線問題對端網(wǎng)關(guān)問題AG增益太大環(huán)境干擾主叫號碼FSK信號干擾PSTN側(cè)用戶聽到噪音1.3IP-TDM路徑下的噪音問題【問題描述】"背景噪聲不連續(xù)的現(xiàn)象"，是指在對端有背景噪聲的情況下，本端說話/停止說話的切換過程中會感到有不舒適的剪切感。【問題解決】步驟1

請先將使用settcpara命令將編解碼的VAD關(guān)閉步驟2

在MML上用LSTECPARA查看CNG是否打開，確保CNG被使能。步驟3

將EC繞開。然后本端說話時，可以聽到明顯的回聲（表明EC已經(jīng)被繞開），并且注意對端背景噪聲是否連續(xù)。步驟4

如果繞開EC之后，發(fā)現(xiàn)背景噪聲連續(xù),問題現(xiàn)象消失，那么可以確定是EC引入的背景噪聲不連續(xù)。步驟5

如果確定是EC引入的背景噪聲不連續(xù)，逐個隔離EC單板，進(jìn)行撥測排查。定位后有問題的單板，進(jìn)行更換。背景噪聲不連續(xù)第1章噪音問題定位第2章單通問題定位第3章回聲問題定位第4章2833問題定位內(nèi)容介紹2.1純TDM路徑下單通問題定位純TDM路徑下的單通問題，一般有下面幾種可能的原因：由對接設(shè)備引入的；TDM連線連接錯誤產(chǎn)生鴛鴦線或者TDM接口相關(guān)配置與對端設(shè)備不一致導(dǎo)致；UMG8900內(nèi)部級聯(lián)光纖連接錯誤；UMG8900設(shè)備的TDM交換網(wǎng)板、TDM資源板的硬件問題。問題分析2.1純TDM路徑下單通問題定位出現(xiàn)單通問題后，詳細(xì)了解該問題出現(xiàn)局點的組網(wǎng)情況，確定從主叫到被叫的整個承載路徑（通過跟蹤軟交換上的信令交互過程確認(rèn)），首先要做的就是保持呼叫，不要掛機(jī)，這是排查問題的一個重要條件。在此基礎(chǔ)上按以下步驟進(jìn)行排查如果A用戶不能聽到B用戶的聲音，首先檢查是否是靠近單通側(cè)用戶A設(shè)備引入的單通問題。以通過讓此設(shè)備在與UMG8900連接的接口上做內(nèi)環(huán)回的操作來確認(rèn)，見圖2-1（在保證設(shè)備A不使用EC的情況下）。如果內(nèi)環(huán)回后A用戶不能聽到自己的回音，則說明問題出在UMG8900對接的A設(shè)備上，可能有以下原因造成。TDM連線錯誤，請檢查連接兩個設(shè)備的連線。兩端TDM接口配置不一致，請對比相關(guān)配置，具體描述請參見《HUAWEIUMG8900通用媒體網(wǎng)關(guān)配置指南》。如果A用戶可以聽到自己的回音，則執(zhí)行下一步，在UMG8900相應(yīng)接口上做外環(huán)回問題解決2.1純TDM路徑下單通問題定位如果A用戶可以聽到自己的回音，則在UMG8900連接A設(shè)備的接口上做外環(huán)回，見左圖。如果A用戶聽不到自己的回音，則A設(shè)備有問題。具體原因同上一步。如果此時A用戶仍然可以聽到自己的回音，則在UMG8900另一側(cè)進(jìn)行內(nèi)環(huán)回，見右圖。如果用戶A不能聽到自己的回音并且UMG8900沒有使用EC的話，則說明是UMG8900內(nèi)部出現(xiàn)問題，后面作為專題進(jìn)行介紹。如果用戶A仍然能夠聽到自己的聲音則證明UMG8900到A設(shè)備到用戶A都是正常的，需要確認(rèn)UMG8900與B設(shè)備直接的連線和B設(shè)備內(nèi)部是否存在問題。問題解決2.1純TDM路徑下單通問題定位對于UMG8900內(nèi)部產(chǎn)生單通的原因有以下三個原因。UMG8900內(nèi)部級聯(lián)光纖連接錯誤；UMG8900設(shè)備的TDM交換網(wǎng)板、TDM資源板的硬件問題；時鐘不同步造成。對于原因1可以通過排查告警來確認(rèn)，一般需要注意告警“級聯(lián)鏈路連接與配置不符”（告警ID818），核對TDM級聯(lián)光纖的收發(fā)是否與對端TDM級聯(lián)光口的收發(fā)相匹配并且與MML命令配置的TDM級聯(lián)吻合。對于原因2同樣要通過收集活動告警來確認(rèn)。需要搜集連接A設(shè)備和B設(shè)備的兩塊TDM接口板及其所在框主備TNU單板的活動告警以及中心框TNU和各個BLU單板的活動告警來確認(rèn)是否有硬件的FMEA告警。對于原因3需要確認(rèn)時鐘板和各框NET板（或者TNC板）時鐘是否同步，需要收集一下所有單板的活動告警來分析解決。問題解決第1章噪音問題定位第2章單通問題定位第3章回聲問題定位第4章2833問題定位內(nèi)容介紹3.1回聲簡介在通話過程中，如果說話人聽到了自己的延遲后的聲音，這個延遲后的聲音就稱作回波。回波分為以下兩種：電學(xué)回波信號在接收端（由于Hybrid的線圈匹配性不好造成的信號的泄漏）有一部分被反射回發(fā)送端，轉(zhuǎn)換器（Hybrid）將2－Wires本地環(huán)分接成兩對獨立的線，一對用于發(fā)送路徑，另一對用于接收路徑。理想情況下，轉(zhuǎn)換器（Hybrid）將來自4－Wires環(huán)路的信號全部耦合到2－Wires環(huán)路上，但是由于2－Wires環(huán)路與4－Wires環(huán)路設(shè)備之間的阻抗不匹配，導(dǎo)致轉(zhuǎn)換器只傳遞了大部分的信號到2－Wires環(huán)路上，而還有一小部分被“泄漏”到了轉(zhuǎn)換器的發(fā)送路徑上，這些被“泄漏”到發(fā)送路徑上的信號就是回波。3.1回聲簡介聲學(xué)回波聲學(xué)回波也稱作“多徑回波”，它是由電話機(jī)揚(yáng)聲器與話筒之間的聲學(xué)耦合問題導(dǎo)致的。在無線電話和有線電話，或者在揚(yáng)聲器的免提設(shè)備中都會出現(xiàn)這種回波。這些問題是由低質(zhì)量的電話聽筒、周圍環(huán)境中的回波（例如在汽車、旅館或工廠中）或者電話聽筒串話造成的。統(tǒng)一維護(hù)手冊3.2回聲問題定位方法1. 固網(wǎng)應(yīng)用環(huán)境，PSTN電話互通聽到回聲固網(wǎng)應(yīng)用環(huán)境的EC處理位置如圖1-5這時的回聲絕大多數(shù)都是電學(xué)回聲，屬于UMG8900的處理范圍，根據(jù)對端受益的原則，先分析清楚是哪個UMG8900的EC沒有處理好導(dǎo)致的回聲。2. 2G純TDM組網(wǎng)，UMG8900作為端局，手機(jī)打手機(jī)這種情況如果出現(xiàn)回聲，屬于聲學(xué)回聲，UMG8900作為純TDM組網(wǎng)，不會引入時延，可以排除不是UMG8900的問題，并且UMG8900無法處理這種回聲。3. 2G純TDM組網(wǎng)，UMG8900作為關(guān)口局，手機(jī)打固話這種情況的的EC處理位置如圖1-6所示，2G純TDM組網(wǎng)，UMG8900作為關(guān)口局，手機(jī)打固話產(chǎn)生回聲。這時如果固話側(cè)聽到回聲，屬于聲學(xué)回聲，與UMG8900無關(guān)，可以排除不是UMG8900的問題。如果是手機(jī)側(cè)聽到回聲，則和UMG8900相關(guān)。4. 2G出IP組網(wǎng)，跨IP網(wǎng)段手機(jī)打手機(jī)2G出IP組網(wǎng)，跨IP網(wǎng)段手機(jī)打手機(jī)出現(xiàn)回聲，這種情況的的EC處理位置如圖1-8所示。這屬于聲學(xué)回聲，UMG8900無法處理這種回聲。初步判斷3.2回聲問題定位方法5. 2G出IP組網(wǎng)，跨IP網(wǎng)段手機(jī)打固話這種情況的的EC處理位置如圖1-8所示，2G出IP組網(wǎng)，跨IP網(wǎng)段手機(jī)打固話出現(xiàn)回聲。這時如果固話側(cè)聽到回聲，這屬于聲學(xué)回聲，UMG8900無法處理這種回聲。如果是手機(jī)側(cè)聽到回聲，屬于電學(xué)回聲，則和UMG8900相關(guān)。6. 2G和NGN互通，跨IP網(wǎng)段手機(jī)打固話這種情況的的EC處理位置如圖1-7所示，2G和NGN互通，跨IP網(wǎng)段手機(jī)打固話出現(xiàn)回聲。這時如果固話側(cè)聽到回聲，這屬于聲學(xué)回聲，UMG8900無法處理這種回聲，但是該組網(wǎng)環(huán)境下仍然會加電學(xué)EC，可能導(dǎo)致UMG8900的電學(xué)EC無法處理聲學(xué)回聲而出現(xiàn)固話側(cè)聽到回聲。如果是手機(jī)側(cè)聽到回聲，屬于電學(xué)回聲，則和UMG8900相關(guān)。7. 2G撥打3G手機(jī)，跨IP網(wǎng)段2G撥打3G手機(jī)，跨IP網(wǎng)段出現(xiàn)回聲，組網(wǎng)類似圖1-8，這屬于聲學(xué)回聲，UMG8900無法處理這種回聲。8. 3G撥打3G手機(jī)，跨IP網(wǎng)段3G撥打3G手機(jī)，跨IP網(wǎng)段出現(xiàn)回聲，組網(wǎng)類似圖1-8，這屬于聲學(xué)回聲，UMG8900無法處理這種回聲。9. 3G撥打固話，跨IP網(wǎng)段這種情況的的EC處理位置類似圖1-6所示，手機(jī)打固話產(chǎn)生回聲。這時如果固話側(cè)聽到回聲，屬于聲學(xué)回聲，與UMG8900無關(guān)，可以排除不是UMG8900的問題。如果是手機(jī)側(cè)聽到回聲，則和UMG8900相關(guān)。初步判斷第1章噪音問題定位第2章單通問題定位第3章回聲問題定位第4章2833問題定位內(nèi)容介紹2833特性介紹在VoIP的應(yīng)用中通常采用低速率編解碼來獲得較高的帶寬利用率，但是目前采用的低速率語音編碼（例如G.729，AMR等）都是針對語音信號來設(shè)計的，而對于單音信號（例如DTMF信號和傳真音等信號），經(jīng)過低速率語音編解碼后會造成質(zhì)量的損傷，對端無法正確地接收到單音信號，導(dǎo)致依賴于這些單音信號的業(yè)務(wù)不能正常地運行。簡而言之，就是語音壓縮編碼格式的IP包不適合傳輸單音信號。解決這個問題的方法就是采用2833傳送單音信號。RFC2833協(xié)議命名包結(jié)構(gòu)ThepayloadformatisshowninFig.1.012301234567890123456789012345678901+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|event|E|R|volume|duration|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure1:PayloadFormatforNamedEventsevents:TheeventsareencodedasshowninSections3.10through3.14.volume:ForDTMFdigitsandothereventsrepresentableastones,thisfielddescribesthepowerlevelofthetone,expressedindBm0afterdroppingthesign.Powerlevelsrangefrom0to-63dBm0.TherangeofvalidDTMFisfrom0to-36dBm0(mustaccept);lowerthan-55dBm0mustberejected(TR-TSY-000181,ITU-TQ.24A).Thus,largervaluesdenotelowervolume.ThisvalueisdefinedonlyforDTMFdigits.Forotherevents,itissettozerobythesenderandisignoredbythereceiver.RFC2833協(xié)議Schulzrinne&PetrackStandardsTrack[Page6]RFC2833TonesMay2000duration:Durationofthisdigit,intimestampunits.Thus,theeventbeganattheinstantidentifiedbytheRTPtimestampandhassofarlastedaslongasindicatedbythisparameter.Theeventmayormaynothaveended.Forasamplingrateof8000Hz,thisfieldissufficienttoexpresseventdurationsofuptoapproximately8seconds.RFC2833協(xié)議音頻包結(jié)構(gòu)012301234567890123456789012345678901+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|modulation|T|volume|duration|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|RRRR|frequency|RRRR|frequency|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|RRRR|frequency|RRRR|frequency|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|RRRR|frequency|RRRR|frequency|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure3:Payloadformatfortonesfrequency:Thefrequenciesofthetonestobeadded,measuredinHzandrepresentedasa12-bitunsignedinteger.Thefieldsizeissufficienttorepresentfrequenciesupto4095Hz,whichexceedstherangeoftelephonesystems.Avalueofzeroindicatessilence.Asingletonecancontainanynumberoffrequencies.統(tǒng)一維護(hù)手冊4.1常見問題處理方法【問題描述】用戶反饋二次撥號業(yè)務(wù)概率失敗?！締栴}確認(rèn)】經(jīng)確認(rèn)UMG8900打開2833發(fā)送開關(guān)后導(dǎo)致二次撥號業(yè)務(wù)概率失敗。了解組網(wǎng)，UMG8900處于發(fā)送2833的位置，然后通過跟蹤或者查詢對端的收號設(shè)備（SCP），發(fā)現(xiàn)有多檢和漏檢的情況。【問題分析】分析二次撥號問題首先需要分析組網(wǎng)，和典型組網(wǎng)1類似，都是UMG8900發(fā)送2833，對端設(shè)備再還原檢測到的2833信號，SCP設(shè)備在TDM進(jìn)行檢號。組網(wǎng)如下：PSTN（TDM）UMG8900（IP）MGW(TDM)SCP2833漏號是因為DTMF的檢測需要一定的時間，根據(jù)協(xié)議，檢測到有效DTMF信號至少20ms才認(rèn)為該DTMF信號有效，并且在檢測到DTMF信號以后才可以發(fā)送2833包，因此會造成DTMF漏傳（即以語音編解碼的形式傳輸DTMF，也稱漏號）。UMG8900是將檢測到PSTN發(fā)送的DTMF號碼以2833的形式發(fā)送到MGW，MGW檢測到2833后還原為DTMF信號，最終由SCP完成號碼的檢測。漏號是由于UMG8900的檢測引入，而MGW在還原DTMF后會導(dǎo)致漏過去的DTMF信號和還原后的DTMF信號電平和相位出現(xiàn)不連續(xù)，導(dǎo)致SCP設(shè)備出現(xiàn)漏檢或者多檢。2833的漏號問題4.1常見問題處理方法【問題解決】目前R005和R006及后續(xù)的版本支持緩存進(jìn)行扣號，即在檢測到DTMF前引入一定的時延，減少漏號的長度。這個R005和R006的版本是通過軟參控制，R005的軟參是：P6bit11（缺省1表示打開，設(shè)置0表示關(guān)閉）；R006的是P96bit1（缺省1表示打開，設(shè)置0表示關(guān)閉）。注：這種組網(wǎng)并非都會有問題，這種組網(wǎng)下是存在UMG8900的漏號問題，如果對端檢號設(shè)備符合DTMF檢測標(biāo)準(zhǔn)，是不會出現(xiàn)問題的。2833的漏號問題4.1常見問題處理方法【問題描述】用戶反饋正常通話中可以聽到撥號（DTMF）聲音?！締栴}確認(rèn)】經(jīng)確認(rèn)打開2833發(fā)送開關(guān)后正常通話中才可以聽到撥號（DTMF）聲音。了解組網(wǎng)，明確是哪個方向聽到了DTMF聲音，UMG8900是處于發(fā)送2833還是接收2833的問題。經(jīng)了解組網(wǎng)如下，是B用戶聽到了DTMF聲音，判斷是UMG8900誤檢DTMF。A用戶（TDM）UMG8900（IP）MGW（TDM）B用戶【問題分析】DTMF的檢測是根據(jù)信號中的頻率來判斷，DTMF的頻率和語音信號的頻率在同一頻段，如果人說話的頻率接近DTMF信號的頻率，則會導(dǎo)致出現(xiàn)誤檢。打開2833發(fā)送開關(guān)后，UMG8900出現(xiàn)誤檢后采用2833包的形式發(fā)送給MGW，MGW在檢測到2833后還原成標(biāo)準(zhǔn)的DTMF信號，這時B用戶就會聽到標(biāo)準(zhǔn)的DTMF信號。即打開2833后，UMG8900出現(xiàn)DTMF誤檢，然后導(dǎo)致被誤檢的語音被MGW恢復(fù)成標(biāo)準(zhǔn)的DTMF信號。正常通話中聽到DTMF聲音4.1常見問題處理方法【問題解決】根據(jù)前方的抓承載包（RTP包），分析被誤檢的DTMF信號的頻率特點，修改UMG8900的DTMF檢測門限進(jìn)行規(guī)避。不建議隨意調(diào)整DTMF的檢測門限，如果無法抓包，并且也無法確認(rèn)誤檢的DTMF號碼，聯(lián)系研發(fā)人員提供臨時的DTMF門限進(jìn)行測試。注：在抓包的時候需要打開UMG8900的一個開關(guān)：SETRFC2833:TPKT=ENABLE;即發(fā)送2833的時候同時發(fā)送語音包。該開關(guān)默認(rèn)是關(guān)閉的。正常通話中聽到DTMF聲音4.1常見問題處理方法【問題描述】用戶反饋二次撥號業(yè)務(wù)不成功?！締栴}確認(rèn)】目前現(xiàn)網(wǎng)采用二次撥號的方式有兩種，2833和G.711透傳，因此首先需要了解是采用2833還是G.71