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

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

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

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

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

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

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

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

執(zhí)行DSPSLIP命令，察看該會話是否存在大量滑碼。如果是，則滑碼可能是造成問題的原因。此時，執(zhí)行DSPCLK命令確認UMG8900的時鐘是否處于跟蹤狀態(tài)。如果處于跟蹤狀態(tài)則應該是對端的問題，否則需要配置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;確認時鐘的參考源是否正確。如果正確，但是仍然有滑碼，則應該是對端的問題，需要對端確認問題原因。如果時鐘參考源不正確，修改為正確的參考源即可。NGN側用戶聽到噪音滑碼介紹滑動（slip）：在同步傳輸或準同步傳輸?shù)谋忍亓髦杏捎诰彌_存儲器的讀寫速率不一致造成一組比特丟失或重復插入的現(xiàn)象，稱為滑動。滑動分為受控滑動和非受控滑動。下面我們以E1芯片為例，看看滑動產(chǎn)生的原因。E1接收芯片從輸入信號中提取時鐘，做為緩沖存儲器的寫時鐘，而系統(tǒng)時鐘做為緩沖存儲器的讀時鐘。緩沖存儲器的容量至少為一幀。當寫入和讀出的速率一致時，緩沖存儲器不會發(fā)生溢出，任何小于緩沖存儲器長度的讀/寫時鐘相位差的變化都會被吸收，不影響通信。.過大的相位變化，或者讀、寫時鐘頻率不一致，則會導致緩沖存儲器的上溢或者下溢。當讀出速率小于寫入速率時，會發(fā)生漏讀，丟失一幀信息，當讀出速率大于寫入速率時，會發(fā)生重讀?；瑒影l(fā)生的兩個基本原因：第一、鏈路中時鐘間的頻率同步不好，導致時鐘頻率的差別；第二、鏈路中的相位移動（抖動和漂移）或主鐘和從鐘間的相位移動。1.3IP-TDM路徑下的噪音問題【問題描述】打通電話后PSTN側用戶聽到噪音【問題分析】可能是下面問題造成：話機本身質量問題外線問題對端網(wǎng)關問題AG增益太大環(huán)境干擾主叫號碼FSK信號干擾PSTN側用戶聽到噪音1.3IP-TDM路徑下的噪音問題【問題描述】"背景噪聲不連續(xù)的現(xiàn)象"，是指在對端有背景噪聲的情況下，本端說話/停止說話的切換過程中會感到有不舒適的剪切感?！締栴}解決】步驟1

請先將使用settcpara命令將編解碼的VAD關閉步驟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單板，進行撥測排查。定位后有問題的單板，進行更換。背景噪聲不連續(xù)第1章噪音問題定位第2章單通問題定位第3章回聲問題定位第4章2833問題定位內容介紹2.1純TDM路徑下單通問題定位純TDM路徑下的單通問題，一般有下面幾種可能的原因：由對接設備引入的；TDM連線連接錯誤產(chǎn)生鴛鴦線或者TDM接口相關配置與對端設備不一致導致；UMG8900內部級聯(lián)光纖連接錯誤；UMG8900設備的TDM交換網(wǎng)板、TDM資源板的硬件問題。問題分析2.1純TDM路徑下單通問題定位出現(xiàn)單通問題后，詳細了解該問題出現(xiàn)局點的組網(wǎng)情況，確定從主叫到被叫的整個承載路徑（通過跟蹤軟交換上的信令交互過程確認），首先要做的就是保持呼叫，不要掛機，這是排查問題的一個重要條件。在此基礎上按以下步驟進行排查如果A用戶不能聽到B用戶的聲音，首先檢查是否是靠近單通側用戶A設備引入的單通問題。以通過讓此設備在與UMG8900連接的接口上做內環(huán)回的操作來確認，見圖2-1（在保證設備A不使用EC的情況下）。如果內環(huán)回后A用戶不能聽到自己的回音，則說明問題出在UMG8900對接的A設備上，可能有以下原因造成。TDM連線錯誤，請檢查連接兩個設備的連線。兩端TDM接口配置不一致，請對比相關配置，具體描述請參見《HUAWEIUMG8900通用媒體網(wǎng)關配置指南》。如果A用戶可以聽到自己的回音，則執(zhí)行下一步，在UMG8900相應接口上做外環(huán)回問題解決2.1純TDM路徑下單通問題定位如果A用戶可以聽到自己的回音，則在UMG8900連接A設備的接口上做外環(huán)回，見左圖。如果A用戶聽不到自己的回音，則A設備有問題。具體原因同上一步。如果此時A用戶仍然可以聽到自己的回音，則在UMG8900另一側進行內環(huán)回，見右圖。如果用戶A不能聽到自己的回音并且UMG8900沒有使用EC的話，則說明是UMG8900內部出現(xiàn)問題，后面作為專題進行介紹。如果用戶A仍然能夠聽到自己的聲音則證明UMG8900到A設備到用戶A都是正常的，需要確認UMG8900與B設備直接的連線和B設備內部是否存在問題。問題解決2.1純TDM路徑下單通問題定位對于UMG8900內部產(chǎn)生單通的原因有以下三個原因。UMG8900內部級聯(lián)光纖連接錯誤；UMG8900設備的TDM交換網(wǎng)板、TDM資源板的硬件問題；時鐘不同步造成。對于原因1可以通過排查告警來確認，一般需要注意告警“級聯(lián)鏈路連接與配置不符”（告警ID818），核對TDM級聯(lián)光纖的收發(fā)是否與對端TDM級聯(lián)光口的收發(fā)相匹配并且與MML命令配置的TDM級聯(lián)吻合。對于原因2同樣要通過收集活動告警來確認。需要搜集連接A設備和B設備的兩塊TDM接口板及其所在框主備TNU單板的活動告警以及中心框TNU和各個BLU單板的活動告警來確認是否有硬件的FMEA告警。對于原因3需要確認時鐘板和各框NET板（或者TNC板）時鐘是否同步，需要收集一下所有單板的活動告警來分析解決。問題解決第1章噪音問題定位第2章單通問題定位第3章回聲問題定位第4章2833問題定位內容介紹3.1回聲簡介在通話過程中，如果說話人聽到了自己的延遲后的聲音，這個延遲后的聲音就稱作回波?；夭ǚ譃橐韵聝煞N：電學回波信號在接收端（由于Hybrid的線圈匹配性不好造成的信號的泄漏）有一部分被反射回發(fā)送端，轉換器（Hybrid）將2－Wires本地環(huán)分接成兩對獨立的線，一對用于發(fā)送路徑，另一對用于接收路徑。理想情況下，轉換器（Hybrid）將來自4－Wires環(huán)路的信號全部耦合到2－Wires環(huán)路上，但是由于2－Wires環(huán)路與4－Wires環(huán)路設備之間的阻抗不匹配，導致轉換器只傳遞了大部分的信號到2－Wires環(huán)路上，而還有一小部分被“泄漏”到了轉換器的發(fā)送路徑上，這些被“泄漏”到發(fā)送路徑上的信號就是回波。3.1回聲簡介聲學回波聲學回波也稱作“多徑回波”，它是由電話機揚聲器與話筒之間的聲學耦合問題導致的。在無線電話和有線電話，或者在揚聲器的免提設備中都會出現(xiàn)這種回波。這些問題是由低質量的電話聽筒、周圍環(huán)境中的回波（例如在汽車、旅館或工廠中）或者電話聽筒串話造成的。統(tǒng)一維護手冊3.2回聲問題定位方法1. 固網(wǎng)應用環(huán)境，PSTN電話互通聽到回聲固網(wǎng)應用環(huán)境的EC處理位置如圖1-5這時的回聲絕大多數(shù)都是電學回聲，屬于UMG8900的處理范圍，根據(jù)對端受益的原則，先分析清楚是哪個UMG8900的EC沒有處理好導致的回聲。2. 2G純TDM組網(wǎng)，UMG8900作為端局，手機打手機這種情況如果出現(xiàn)回聲，屬于聲學回聲，UMG8900作為純TDM組網(wǎng)，不會引入時延，可以排除不是UMG8900的問題，并且UMG8900無法處理這種回聲。3. 2G純TDM組網(wǎng)，UMG8900作為關口局，手機打固話這種情況的的EC處理位置如圖1-6所示，2G純TDM組網(wǎng)，UMG8900作為關口局，手機打固話產(chǎn)生回聲。這時如果固話側聽到回聲，屬于聲學回聲，與UMG8900無關，可以排除不是UMG8900的問題。如果是手機側聽到回聲，則和UMG8900相關。4. 2G出IP組網(wǎng)，跨IP網(wǎng)段手機打手機2G出IP組網(wǎng)，跨IP網(wǎng)段手機打手機出現(xiàn)回聲，這種情況的的EC處理位置如圖1-8所示。這屬于聲學回聲，UMG8900無法處理這種回聲。初步判斷3.2回聲問題定位方法5. 2G出IP組網(wǎng)，跨IP網(wǎng)段手機打固話這種情況的的EC處理位置如圖1-8所示，2G出IP組網(wǎng)，跨IP網(wǎng)段手機打固話出現(xiàn)回聲。這時如果固話側聽到回聲，這屬于聲學回聲，UMG8900無法處理這種回聲。如果是手機側聽到回聲，屬于電學回聲，則和UMG8900相關。6. 2G和NGN互通，跨IP網(wǎng)段手機打固話這種情況的的EC處理位置如圖1-7所示，2G和NGN互通，跨IP網(wǎng)段手機打固話出現(xiàn)回聲。這時如果固話側聽到回聲，這屬于聲學回聲，UMG8900無法處理這種回聲，但是該組網(wǎng)環(huán)境下仍然會加電學EC，可能導致UMG8900的電學EC無法處理聲學回聲而出現(xiàn)固話側聽到回聲。如果是手機側聽到回聲，屬于電學回聲，則和UMG8900相關。7. 2G撥打3G手機，跨IP網(wǎng)段2G撥打3G手機，跨IP網(wǎng)段出現(xiàn)回聲，組網(wǎng)類似圖1-8，這屬于聲學回聲，UMG8900無法處理這種回聲。8. 3G撥打3G手機，跨IP網(wǎng)段3G撥打3G手機，跨IP網(wǎng)段出現(xiàn)回聲，組網(wǎng)類似圖1-8，這屬于聲學回聲，UMG8900無法處理這種回聲。9. 3G撥打固話，跨IP網(wǎng)段這種情況的的EC處理位置類似圖1-6所示，手機打固話產(chǎn)生回聲。這時如果固話側聽到回聲，屬于聲學回聲，與UMG8900無關，可以排除不是UMG8900的問題。如果是手機側聽到回聲，則和UMG8900相關。初步判斷第1章噪音問題定位第2章單通問題定位第3章回聲問題定位第4章2833問題定位內容介紹2833特性介紹在VoIP的應用中通常采用低速率編解碼來獲得較高的帶寬利用率，但是目前采用的低速率語音編碼（例如G.729，AMR等）都是針對語音信號來設計的，而對于單音信號（例如DTMF信號和傳真音等信號），經(jīng)過低速率語音編解碼后會造成質量的損傷，對端無法正確地接收到單音信號，導致依賴于這些單音信號的業(yè)務不能正常地運行。簡而言之，就是語音壓縮編碼格式的IP包不適合傳輸單音信號。解決這個問題的方法就是采用2833傳送單音信號。RFC2833協(xié)議命名包結構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é)議音頻包結構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)一維護手冊4.1常見問題處理方法【問題描述】用戶反饋二次撥號業(yè)務概率失敗?！締栴}確認】經(jīng)確認UMG8900打開2833發(fā)送開關后導致二次撥號業(yè)務概率失敗。了解組網(wǎng)，UMG8900處于發(fā)送2833的位置，然后通過跟蹤或者查詢對端的收號設備（SCP），發(fā)現(xiàn)有多檢和漏檢的情況?！締栴}分析】分析二次撥號問題首先需要分析組網(wǎng)，和典型組網(wǎng)1類似，都是UMG8900發(fā)送2833，對端設備再還原檢測到的2833信號，SCP設備在TDM進行檢號。組網(wǎng)如下：PSTN（TDM）UMG8900（IP）MGW(TDM)SCP2833漏號是因為DTMF的檢測需要一定的時間，根據(jù)協(xié)議，檢測到有效DTMF信號至少20ms才認為該DTMF信號有效，并且在檢測到DTMF信號以后才可以發(fā)送2833包，因此會造成DTMF漏傳（即以語音編解碼的形式傳輸DTMF，也稱漏號）。UMG8900是將檢測到PSTN發(fā)送的DTMF號碼以2833的形式發(fā)送到MGW，MGW檢測到2833后還原為DTMF信號，最終由SCP完成號碼的檢測。漏號是由于UMG8900的檢測引入，而MGW在還原DTMF后會導致漏過去的DTMF信號和還原后的DTMF信號電平和相位出現(xiàn)不連續(xù)，導致SCP設備出現(xiàn)漏檢或者多檢。2833的漏號問題4.1常見問題處理方法【問題解決】目前R005和R006及后續(xù)的版本支持緩存進行扣號，即在檢測到DTMF前引入一定的時延，減少漏號的長度。這個R005和R006的版本是通過軟參控制，R005的軟參是：P6bit11（缺省1表示打開，設置0表示關閉）；R006的是P96bit1（缺省1表示打開，設置0表示關閉）。注：這種組網(wǎng)并非都會有問題，這種組網(wǎng)下是存在UMG8900的漏號問題，如果對端檢號設備符合DTMF檢測標準，是不會出現(xiàn)問題的。2833的漏號問題4.1常見問題處理方法【問題描述】用戶反饋正常通話中可以聽到撥號（DTMF）聲音?！締栴}確認】經(jīng)確認打開2833發(fā)送開關后正常通話中才可以聽到撥號（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信號的頻率，則會導致出現(xiàn)誤檢。打開2833發(fā)送開關后，UMG8900出現(xiàn)誤檢后采用2833包的形式發(fā)送給MGW，MGW在檢測到2833后還原成標準的DTMF信號，這時B用戶就會聽到標準的DTMF信號。即打開2833后，UMG8900出現(xiàn)DTMF誤檢，然后導致被誤檢的語音被MGW恢復成標準的DTMF信號。正常通話中聽到DTMF聲音4.1常見問題處理方法【問題解決】根據(jù)前方的抓承載包（RTP包），分析被誤檢的DTMF信號的頻率特點，修改UMG8900的DTMF檢測門限進行規(guī)避。不建議隨意調整DTMF的檢測門限，如果無法抓包，并且也無法確認誤檢的DTMF號碼，聯(lián)系研發(fā)人員提供臨時的DTMF門限進行測試。注：在抓包的時候需要打開UMG8900的一個開關：SETRFC2833:TPKT=ENABLE;即發(fā)送2833的時候同時發(fā)送語音包。該開關默認是關閉的。正常通話中聽到DTMF聲音4.1常見問題處理方法【問題描述】用戶反饋二次撥號業(yè)務不成功?！締栴}確認】目前現(xiàn)網(wǎng)采用二次撥號的方式有兩種，2833和G.711透傳，因此首先需要了解是采用2833還是G.71