附件四:

烽火PON設備故障處理手冊

目錄

一、根本語音業務配置方法2

1.1語音配置流程圖2

1.2根本語音業務配置方法2

局端vlan配置2

1.2.2AC16配置3

1.2.3ONU端用戶語音業務配置5

二、語音故障處理流程圖6

三、定位語音業務故障根本原那么6

3.1檢查外線6

3.2核對配置7

3.3檢杳硬件7

3.4檢查上層路由7

3.5抓包分析7

四、根本語音業務故障分類查找8

4.1網關未注冊上軟交換8

4.2端點未注冊上軟交換9

4.3摘機無撥號音11

4.4被叫不振鈴13

4.5上叫撥打聽忙音15

4.6放置一段時間后不能正常通話17

4.7摘機有撥號音，但語音不通或單通19

4.8語音質量23

王、增值語音業務故障分類查找25

5.1來電顯示25

5.2/Modem27

5.3POS機/彩票機32

5.4智能公話33

5.5話吧計費業務35

附一語音業務高級配置參數37

I.NGN心跳參數配置37

2.軟交換平臺互通參數配置38

根本語音業務配置方法

1.1語音配置流程圖

烽火EPON系列產品采用集中式網管管理，語音業務開通主要由局端配置和遠端ONU配置兩大步。

局端配置用于配置各ONU共同的配置項，例如軟交換平臺地址，vlan等；ONU配置用于配置ONU

的配置項，例如IP地址，域名和端口ID等。其流程如下：

1.2根本語音業務配置方法

局端vlan配置

在GSWC盤上點右鍵，選擇“配置“局端vlan”，翻開配置窗口，按照以下說明填寫相關信

息：

業務類型:包含data、iptv、ngn、voip、vod、cncview、system,此項選擇只是用來顯示作用,并

不代表實際意義。一般按照業務類型來選擇，語音業務可選擇ngn或者voip。

業務名稱：可根據工程需要自定義填寫，主要用來形象的標記vlan業務區分。

起始VLANID：填寫業務vlanid范圍的最小值。

結束VLANID：填寫業務vlanid范圍的最大值。當起始VLANID和結束VLANID相等時，該業務

使用唯一的vlanid。

上聯接口號或TRUNK組號：選擇具體業務的上聯端口號。如果上聯接口采用了TRUNK方式，那

么選擇TRUNK組號。

TAG/UNTAG：上聯接口是TAG模式那么選擇“不剝離”，上聯接口是UNTAG模式那么選擇“剝

離工

注意：

此處所說的svlan并不一定肯定是雙層vlan的外層vlan,僅僅只是代表最外層的vlan,不管是否是

雙層vlan。如果沒有使用雙層vlan,那么此svlan與onu的cvlan相對應。

筒單說：對丁onu端只需耍配置單層vlan(例如3001),那么這個svkm就對應丁onu的uvlan,

也只是單層vlan(3001),此時就不存在外層vlan了；對Fonu端需要配置雙層vlan(cvlan為1()01,

svlan為401),那么此處的svlan就對應onu端的svlan(401)。

1.2.2AC16配置

1.在AC16盤上點右鍵，翻開“配置”?…“NGN配置”窗口，選擇"NGN上聯接口配置”，填

寫如下信息：

1)業務名稱：選擇局端vlan中的相應語音vlan名稱。

2)MGC協議：選擇工程上所使用的語音協議類型，如：H.248、MGCP、SIP。

3)心跳開關：建議選擇使能，表示0W獨立控制心跳，默認為“使能”。

4)根據2)選擇的協議類型，進行后續相關參數的配置，其他參數默認配置即可：

H248/MGCP協議配置：

A、MGC1IP地址或域名地址：填寫主用軟交換平臺的IP地址。

B、MGC1端口號：根據對應滔音協議填寫對應端口號，如：H.248辦議對應2944,MGCP協議

對應2727,也可根據特殊要求填寫其他端口號。

C、MGC21P地址或域名地址：填寫備用軟交換平臺的IP地址。

D、MGC2端口號：根據對應語音協議填寫對應端口號，如：H.248協議對應2944,MGCP協議對

應2727,也可根據特殊要求填寫其他端口號。

E、MGC31P地址或域名地址：填寫備用軟交換平臺的IP地址。

F、MGC3端口號：根據對應語音協議填寫對應端口號，如：H.248協議對應2944,MGCP協議對

應2727,也可根據特殊要求填寫其他端口號。

SIP協議配置:

注意：般情況下只需要修改模板中RTP資源名稱、起始值、結束值和撥號完全匹配是否立

即上報處理，其它參數默認不變（如果其他參數有特別要求，參見附件中軟交換平臺互通參數解

釋）。

I）模板名：可自定義編寫。

2）RTP資源名稱固定局部：RTP資源命名的不變局部，可根據工程具體需要填寫，如“RTP/”。

3）RTP資源名稱可變局部起始值：可根據現場情況填寫，默認為4000。

4）RTP資源名稱可變局部結束值：可根據現場情況填寫，默認為9000o

5）RTP資源名稱可變局部步長：一般為1。

6）RTPname固定長度：不用更改，默認為固定（填充）。

7）完全匹配任意規那么后立即上報：一般不用修改，默認為唯一匹配上報。與華為軟交換平臺

對接時設置為“立即上報”。

4,軟交換互通模板綁定

可根據需要把相應的軟交換平臺互通參數模板綁定到具體的ONU。

1）槽位號：EC2盤所在槽位號。

2）ONU號：對應ONU的授權號。

3）模板名：選擇前面設定的“軟交換平臺互通參數模板”的模板名。

ONU端用戶語音業務配置

在“配置”―-"EPON/GPON用戶管理”窗口中對onu正常授權，選擇具體onu,翻開“用

戶業務配置”界面，開始配置如下信息：

選擇fxsl口，點擊占用后，再點擊高級選項，可根據需要選擇“QINQ使能狀態”，如語音不需Svlan,

那么POTS口處于QinQ非使能狀態。

I）號碼：填寫與AC16"NGN上聯用戶信令數據配置”中對應的號碼。

2）信令VLANID：填寫語音的vlanid,如果語音采用雙層vlan,那么填寫cvlanid。

3）語音編碼：優先處理的語音編碼，可根據需要選擇，默認為G.7I1A。

4）模式：可根據需要選擇，默認為透傳，即T30模式。

5）靜音開關：可根據需要選擇，默認為選中。

6）回聲抑制：可根據需要選擇，默認為選中。

7）輸入增益：不需要修改，默認為0。

8）輸出增益：不需要修改，默認為0。

9）DTMF模式：不需要修改，默認為透傳。

10）“QINQ使能狀態”：語音采用雙層vlan時,需要選中此復選框。

II）SVLANID：選擇了QINQ使能后,在此處填寫外層vlanid。

注意：GSWC盤上配置語音業務局部的局端svlan,當。nu配置中“qinq使能狀態”打勾時，后面

填寫的Svlan對應于GSWC盤上配置的局端svlan；當onu配置中“qinq使能狀態”不打勾時，上

面填寫的“信令Vianid”對應GSWC盤上配置的局端svlan。

二、語音故障處理流程圖

三、定位語音業務故障根本原那么

定位語音故障時，首先應咳確認故障范圍。由故障范圍來進行故障點的初步定位。例：

個別現象的問題，排查重點就放在對終端設備（外線，設備端口）上，或者檢查端口級的配置。

ONU下用戶同樣問題，排查重點放在設備級別的配置或者硬件故障。

不同ONU下用戶同樣問題，排查重點就應該放在分路器，和對應的PON口上。

如果一個OLT下用戶全部故障，那么重點就應該放在數據配置，上聯路由和平臺上。

3.1檢查外線

在定位問題時，首先要排除外界可能的干擾因素。在EPON工程中，外線的距離都不會很長，但也

有可能會出現短路，搭線等問四。所以排查個別用戶報障時，首先要排除外線原因，

與外線關系較為密切的故障大致有以下幾種：

1.摘機沒有饋電。

2.通話中有較大的雜音。

3.串號等

對此類故障，首先要排除外線因素，最好的方法就是，在ONL?端直接接設備測試。如果是FTTN設

備，那么直接在內線上（不經過ODF架）直接測試。

對I?新開的設備，特別是端口數比擬大的FTTN設備，需要檢查是否有線路短接或者多個用戶相互

搭線。當出現此類問題時，該設備下的用戶會頻繁上報摘掛機，致使軟交換平臺不對該設備的消

息進行回應，嚴重情況下會導致整臺設備下的用戶都無法使用。

3.2核對配置

在工程中有許多故障是由于和平臺配置不符造成的，特別是新開的工程。

以卜幾種故障與配置錯誤有較大的聯系：

i.主叫摘機沒有撥號音，產生原因有可能是網關域名或端點用戶名配置錯誤

2.被叫摘機放忙音，產生原因可能是RTP值配置有誤，

3.3檢查硬件

端口級的語音故障，應該先考慮更換端口。比方端口無饋電，端口不振鈴，端口長振鈴等故

障，建議一般先更換端口，排除個別端口硬件問題。然后再進一步杳找具體原因。

3.4檢查上層路由

許多通話質量問題都和上層路由有關，如通話時時斷時續，通話中單通等情況就有可能是上層路

由上有丟包所致。

3.5抓包分析

抓包分析是定位問題最后的手段，也是最行之有效的方法C口述故障現象一不準確，二是無法定

位具體問題。可利用圖形網管“信令追蹤功能”捕獲設備和平臺交互的信令或利用Wireshark等

抓包工具在OLT上聯口，ONU端口等地方捕獲語音信令和媒體流信息，按照相應語音協議來分析問

題原因。

四、根本語音業務故障分類查找

4.1網關未注冊上軟交換

【問題現象】

摘機沒有撥號音，查看網關狀態為未注冊上或者正在注冊中。

【原因分析】

EPON系統中，ONU同時擔任信令網關(MG)的角色。在進行業務開通時，首先要向軟交換平臺

注冊。網關注冊失敗主要由以下3種原因導致：

1.VLANID配置不正確：VLANID配置信息不正確使得CNU和軟交換平臺之間無法正常的通信，

從而導致網關注冊失敗。

2.MG的1P配置重復：在軟交換系統中，每個MG都應該有唯一的IP地址，當兩個或者兩個以

上MG配置相同的IP地址的時候,將導致MG網關注冊失敗。

3.MID配置錯誤：在軟交換系統之，用MID來標識網關。MG上配置的網關MII)必須與平臺的

配置一致，否那么當MG向軟交換平臺注冊時，軟交換平臺會認為是非法的網關，從而導網關注冊

失敗。

【解決方法】

出現網關注冊失敗的故障笈照以下的方法進行排查：

1.檢查ONU與軟交換平臺之間網絡連接是否正常。

從ONU中ping軟交換的IP,如果ping不通，請檢查VLANID的配置信息和MG的IP配置

信息是否正確。

2.檢杳ONU是否從網管得到H248配置及相關配置是否正確

如果MG能夠正常ping通軟交換平臺，而網關注冊失敗，請檢查MGip和MID配置是否正確，

是否與軟交換平臺上配置的MG信息相匹配。

【現網案例】

某FTTH工程AN5116-02設備在一個PON口下發現IP網關名稱為10.32.160.2的ONU語音不通，在該PON

口下更換為另一個IP網關名稱為的IAD軟交換語音用戶通話正常。

測試中發現軟交換平臺(.2)在審計時，IAD回510UNKOWNENDPOINT,更換為另一個測試后正常，

用戶通話也正常，通過對包的分析發現在配置原10.32.160.2IP時網關名稱后多敲了字符空格鍵，

刪除網關名稱后的字符空格鍵后經過驗證解決，IP網關名稱為的IAD軟交換語音用戶通話也正常。

4.2端點未注冊上軟交換

【問題現象】

端點注冊狀態為reg_fail,摘機沒有撥號音

端點注冊沒有應答，在命令行中發端點注冊也無效。

端點注冊狀態持續為reging,

【原因分析】

端點注冊不，軟交換時，笫一步首先要檢查網關注冊狀態。如果網關注冊成功，端點注冊失

敗，需要檢杳端點配置，與軟交換平臺核對數據。

確認配置正確后，需要鏡像抓包分析軟交換信令，查找具體原因。端點無法注冊上軟交換平

臺的可能原因有下面幾個。

1.外線短路，導致端點頻繁上報摘掛機。這種情況一般常見于FTTN型ONU。該類ONU一般外

線比擬長，容易發生短路，導致ONU認為是真實摘掛機事件，上報軟交換平臺。軟交換平臺認為

這是惡意呼叫，拒絕應答，引起ONU發起網關注冊。所以外線有問題時，圖形網管上會頻繁出現

MGC鏈路斷開告警。

2.軟交換平臺未下發摘掛機檢測事件。原有的注冊流程是，O\U|阿關注冊成功后，會發起端

點注冊。在某地EPON工程中跟軟交換平臺對接時，大量端點注冊導致軟交換平臺的CPU利用率居

高不下。后來對注冊流程做了修改，設備L電或者網絡中斷后恢復時，ONU只發網關注冊，不發端

點注朋。如果軟交換平臺對某端點下發摘掛機檢測事件，就將其置為IDLE.如果軟交換平分未下發

摘掛機檢測事件，那么端點注冊失敗，狀態為REG-FAIL。需要摘機觸發端點注冊。

3.端點用戶名配置錯誤。設備上配置的端點用戶名與軟交換平臺不一致，或者軟交換平臺未

配置相關數據，導致端點注冊失敗。

【解決方法】

可能原因總結及解決方法：

1.檢查網關注冊狀態，確認網關注冊成功。

2.檢查端點配置，確認數據正確。

3.椅杏外線，排除外線故障導致頻繁上報摘排機，引起軟交換平臺不回包。導致網關注冊失

敗。

4.抓包分析信令，查看注冊流程，分析定位具體原因。

【現網案例】

某市EPON工程使用我司AN5U5-020LT系統，下掛AN5006-07/09,AN5006-15/16型ONU。軟交換協議為H.248

協議。局方對城域網進行改造，凌晨改造完畢，之后局部OLT下掛的局部C類ONU無法注冊上軟交換平臺，網管

上出現大量“與MGC通信中斷”告警，語音業務大面積中斷。

經過在OLT上聯口鏡像抓包，分析發現，ONU網關注冊成功后會發起端點注冊。但是有局部

端點的注冊消息沒有收到軟交換平臺的應答。ONU在端點注冊沒有收到應答消息時，促發網關注冊。

當時城域網中斷剛剛恢復，有大量的設備發起注冊請求，軟交換平臺處理不過來時，就丟棄一些

請求包，不予回應。設備在發出請求包沒有收到應答時，重新發網關注冊，一直處于“網關注冊

成功”一）“注冊端點”好”局部端點注冊失敗”一〉“重發網關注冊”的惡性循環之中。

當時的解決方法是，我們修改NGNvlan,斷開ONU與上層城域網的通信，之后逐步恢復。后

來新的軟件版本中，我們對注冊流程做了修改，網關注冊成功后是否發端點注冊做成可配，默認

不發端點注冊，解決注冊包數目過多的問題。

4.3摘機無撥號音

【問題現象】

配置好語音業務，摘機后無饋電；

配置好語音業務，摘機有饋電，但聽不到撥號音。

用戶使用過程中，突然出現摘機沒有撥號音的現象，重啟設備后恢復。

【原因分析】

摘機無撥號音的現象，常見于業務開通的時候。碰到這種故障，首先可以根據摘機有無饋電，

對故障做一個大概的定位。

1.如果摘機無饋電，屬于便件問題。可能的原因有話機本身問題，外線問題，語音接口盤（POTS

盤）問題。此類問題查找時建議首先從外線查起。

對于直接安裝在用戶家的面包盒式ONU,例如AN5006-04,AN5006-05,沒有外線，可以檢查話

機或線問題。排除話機和線問題后，故障的原因可以確定為ONU硬件故障。

對于樓道型ONU和節點型ONU,排查硬件故障時，最有效的方法是拋開外線，直接在設備端口

檢測。根據測試結果，可以將故障定用戶側或者設備側。

2.摘機有饋電，但是沒有撥號音，首先要確定故障類別。判斷是個別端口無撥號音/整個單

盤的端I」無撥號音/整個設備端U無撥號音。根據現象作進一步的檢查。

整個設備端口無撥號音，首先要檢測網關注冊狀態。網關注冊失敗，常見于新設備開通時。

需要檢查跟軟交換平臺之間的通信是否正常，從IADping軟交換平臺看是否能夠ping通。如果

Ping不通，那么檢查VLA”上層路由和物理線路是否正常。如果可以ping通，但是網關注冊不上，

需要檢查IP,域名等數據，確認設備配置的數據跟軟交換平臺一致。網關注冊不上軟交換，一般

都是因為數據配置錯誤或與軟交換通信不正常引起。

整個單盤所有端口無撥號音（針對C類有語音接口盤的ONU）,而其他單盤的端口正常，在確

認端口己經使能，及用戶名配置正確的前提下首先更換POTS盤。

單個端口無撥號音，檢查端點配置。端點需耍配置的數據只有用戶名，使能/去使能兩項，需

要確認配置.正確。比擬常見的情況是，設備配置的用戶名與軟交換平臺不一致，導致端點注冊失

敗，摘機沒有撥號音。

目前烽火04、05,07,09,15,16型的0NU都已經大面積商用，與中興，華為，貝爾的軟交

換平臺都有對接。如果是開通過程中出現摘機沒有撥號音，排除硬件問題，一般都是數據配置有

誤引起，與軟交換平臺的對接不存在問題。

3.使用一段時間后出現摘機無撥號音，排查的思路跟業務開通時相似。排查外線，檢查網關

注冊狀態，端點注冊狀態，檢查0NU與軟交換平臺的通信。如果0NU與軟交換平臺的道信正常，

數據配置也正確，但是端點狀態不是IDLE,可以先在命令行中發送端點注冊，查看端點能否成功

注冊，摘機是否有撥號音。再發網關注冊，盡量不要重啟設備，這樣問題現象會消失，不利于查

找問題真實原因。

如果排除配置問題（配置喪失或者不正確）和通信問題（ping不通軟交換平臺），那么需要在

0LT側鏡像抓包，分析信令，查找具體原因。

對于摘機沒有撥號音，重啟設備或者重新發網關注冊后恢史，過段時間又重現的故障，原因

可能有多種。比方軟件，硬件工作異常，與軟交換平臺互通出現問題,碰到這類情況時，建議盡

量不要重啟設備，保存故障現象，同時聯系我方技術支持人員，查找具體原因。

有效排查手段總結：

1.判斷摘機有無饋電

2.判斷個別端口無撥號音/整個單盤的端口無撥號音/整個設備端口無撥號音

3.查看端口注冊狀態。

4.在0LT側鏡像抓包，分析0NU與軟交換平臺之間的信令。

【解決方法】

可能的原因及解決方法主要有以下幾種：

1.網關注冊失敗，端點名未配，端點名配置錯誤或與軟交換平臺不一致,跟軟交換維護人員

核對數據，確認配置的正確性。

2.設備硬件故障(包括外線短路，斷路，POTS盤硬件故障，語音模塊硬件故障，)需要更換

硬件，將有故障的設備返廠檢修。

3.端點狀態異常，重啟后恢復，過短時間又重現。這類故障一般不常見，如果出現，請保存

故障現象，盡量不要重啟設備，同時聯系我方技術支持人員。

【現網案例】

新疆某地EPON工程在開通語音業務時，摘機沒有撥號音。遠程登錄到ONU上發現，網關注冊狀態為

registeredo但是端點的注冊狀態為reg-fail。

在OLT上做鏡像抓包發現，IAD發去端點注冊時，軟交換平臺回復430(unknowntcrminationlD)

錯誤，后來反復跟軟交換中心的維護人員核對數據，發現設備配置用戶名時，將用戶名配錯。修

改用戶名后業務恢復正常。

4.4被叫不振鈴

【問題現象】

端口做主叫正常，做被叫不振鈴，摘起話機后能夠正常通話。

端口做主叫正常，做被叫不振鈴，摘機后話機無音。

端口做主叫正常，做被叫不振鈴，摘機后聽到撥號音。

用戶使用一段時間后，某些端口出現做被叫無法振鈴現象，重啟設備后恢復正常。

心跳不匹配導致端點狀態為OUTofservice

【原因分析】

首先判斷做主叫是否正常，如果做主叫也出現異常，那么參考“摘機無撥號音”或者“撥打聽

忙音”等原因分析。

如果做被叫不振鈴，摘機能正常通話，說明業務正常，無法振鈴只是硬件故障。可能的原因

的有話機損壞無法振鈴或者設備振鈴模塊損壞。

用戶做被叫不振鈴，遠端聽到的是忙音，被叫摘機后還能聽到撥號音，說明無法做被叫是軟

交換平臺的問題。在業務開通前進行試運行時，軟交換平臺一般會做一個虛擬號，可以做主叫，

但是無法做被叫。割接后未來得及修改，導致用戶投訴。

如果用戶久不掛機或者因為線路問題沒有掛好，設備在翱鳴音超時后，會將端點的狀態自己

置為。utofservice,此時無法做被叫。用戶再次掛機時，會促發端點注冊，如果注冊成功，那

么端點狀態恢復為inservice。

端點狀態正常，但是無法做被叫。抓包分析發現，做被叫時軟交換平臺不予接續。在軟交換

平臺查看，端點狀態為outofservice。導致這種情況的原因比擬多，需要抓包分析置為。utof

service之前，ONU與軟交換平臺的信令交互過程。工程曾經出現過因為ONU的心跳沒有開啟，軟

交換平臺在過段時間后，認為0NU已經不在線，將其端點狀態置為。utofservice導致用戶無法

做被叫。

【解決方法】

1.被叫不振鈴，摘機能正常通話，屬于硬件問題，可以用替代法杳找故障點，然后更換相關

設備。

2.被叫不振鈴，主叫聽到忙音，被叫摘機后聽到撥號音，屬于軟交換平臺配置問題，聯系平

臺維護人員解決。

3.線路有問題，導致掛機未上報。可以用替換法查找話機和線路故障，更換相關設備。

4.設備或者軟交換平臺上，端點的實際狀態為。utofservice。導致此類問題的原因一般都

是因為0NU跟軟交換平臺的互通出現“誤解”，導致一方認為另一方已經不在效勞狀態。具體原因

的查找要從分析信令做起，分析異常之前的信令過程，找出具體原因，再確定解決方法。

【現網案例】

北京某工程一04型0NU,做被叫時沒有振鈴。

經過抓包分析，發現拄機后沒有上報拄機，導致放翱鳴音結束后，端點被置為OUTOFSERVICE

狀態。軟交換平臺發審計時，發現端點已不在效勞狀態。因此做被叫時，平臺不予接續。該問題

更換用戶線路后解決。

4.5主叫撥打聽忙音

【問題現象】

1.主叫時一摘機就放忙音

2.主叫摘機有撥號音，但覆號時1號碼未撥完）放忙音

3.主叫摘機有撥號音，但徵完號（號碼撥完）后放忙音

4.主叫摘機及撥號均止常，對方也有振鈴，但振鈴后中斷，或對方摘機后中斷

【原因分析】

I.這種情況大多是由于網關域名或端點用戶名配置有誤所致。可在網管中選中AC16盤進行

“ngn狀態回調"，查看"MGC注冊狀態”與“端口狀態:正常情況下“MGC注冊狀態”應該是已

注冊。而“端口狀態”應該空閑。

如果“MGC注冊狀態”為注冊中，那么說明網關沒有注冊上，需檢杳網關域名的設置：如果“端

口狀態”為未激活或注冊中，說明端點用戶名沒有注冊上。

2.這種情況通常是撥打的號碼不在平臺所定義的撥號數圖的范圍內。

例如平臺卜.發此撥號數圖

｛（200|20118434441843445）｝此時如果撥打“1”開頭的號碼，因為沒有任何一個撥號方案是

以“1”開頭的，所以平臺認為撥打的號碼非法，直接放忙音。故只要所撥打的號碼與任一撥號方

案都不匹配，就會有此故障.

3.此故障有可能是撥號后超時引起的。可讓客戶在撥完號后加撥號，如果加撥號

后沒有問題，那么根本確定是超時所引起的。此故障大多是因為平臺的撥號方案“x.L”所致。

4.此故障根本上是平臺設置的RTP值和IAD上RTP值不匹配所致。

【解決方法】

1.需檢查端點用戶名配置。

2.這種情況需要檢杳平臺上設定的撥號數圖。

3.為了防止此情況，需將我們設備上的“立即上報”功能翻開。

4.修改RTP值與軟交換平臺匹配即可。

【現網案例1]

某地開EPON試點工程，主叫摘機無撥號音，同時在AC16盤上對ngn狀態進行回調時，發現網關未注冊上。

抓包分析，當設備發注冊信息后，平臺回復402(unknownMGW)錯誤，如下列圖：

判斷是網關域名配置有誤，修改網關域名后，業務恢復正常。

【現網案例2】

某地開EPON試點工程，主叫摘機無撥號音。網關已經注冊上，但是端口摘機沒撥號音。分析抓包后，發現

播機后，軟交換平臺回復430(unknownterminationlD)(>

初步判斷是端口用戶名配置有誤，后來查明，局方給的前緩是大寫，我們配置成小寫。修改

端點用戶名后，業務恢復正常。

【現網案例3]

某地新開工工程，做主叫時，對方有振鈴，但一接就放忙音；做被叫時，有振鈴，但一提機就放忙音。

檢查配置時發現，軟交換上設置的RTP值是RTP/0000-RTP/0015,而設備上配置的是

RTP/OO-RTP/16.修改RTP值后，業務恢復正常。

4.6放置一段時間后不能正常通話

【問題現象】

設備正常開通后主被叫業務都正常，但是閑置一段時間（通常5-10分鐘）之后，摘機要等幾秒

鐘后才有撥號音，無法做被叫。重新發網關注冊之后才能恢復語音業務。

【原因分析】

設備之前業務正常，閑置一段時間之后，登陸設備查看端點的狀態時正常的，但是在平臺上

查看該設備的狀態，發現其狀態變成不在效勞。用戶摘機之后，平臺就只回復了Reply,沒有其它

的信令下發。比照其它正常的設備，發現區別在于心跳。正常的設備開了心跳，出問題的設備沒

有開心跳。

之所以產生一段時間之后平臺與設備狀態不一致的問題，是由于設備沒有開心跳，導致平臺

認為設備不在位，所以將設備的狀態置成不在效勞。

心跳的相關知識：

1.心跳作用

由于UDP傳送的不可靠，MG應能夠及時檢測到軟交換平臺的故障，軟交換平臺也應能及時

檢測到MG故障。為了實現這兩方面，MG和軟交換平臺之間應該實現心跳機制。

2.心跳機制

1）W；默認每隔30秒發一次心跳消息，針對軟交換的最大心跳間隔為64000秒，最小間隔為

1秒，而且心跳可以關閉。

2）MG每次向軟交換發送心跳的間隔是恒定的（配置的間隔），如果連續屢次［配置的次數）

沒有收到響應，那么停止發送心跳，并開始發起注冊。

3.心跳實現方式

主要有兩種方式:

1)只有MGC控制的心跳消息

MGC可以為MG設置一個最大沉默時間，即正常工作MG允許未收到MGC發送的任何消息的最

大時間。MGC應該保證向UG發送消息的時間間隔不超過最大沉默時間。即使在最大沉默時間內

沒有任何其它消息，MGC也必須通過向MG發送心跳消息來說明自己還“活著”。建議MGC用針

對ROOT終結點的空AuditValje命令作為心跳消息，心跳周期在UGC中可以設置，象TG這樣的

大型網關可以設短些，而IAI)那么應該設長些，每個心跳周期MGC向MG的ROOT終結點發送一

個AudilValue消息。最大沉默時間設為8個心跳周期，當MG連續8個心跳周期沒有從UGC收

到任何消息時，就判定MGC發生了故障，雖然實際上可能是網絡故障，而不是MGC故障，但對MG

而言沒有區別。

這種心跳方式即是我們常說的被動心跳。

2)MGC和MG分別獨立控制的心跳消息

MGC和MG互相向對方發送心跳消息，心跳周期由各自獨立決定。協議實體利用事務請求的重

傳機制依靠LOMG-TIMER超時來判定對方實體故障，由于有周期性發送的心跳消息息，可以保證協

議實體及時檢測到對方實體故障。與前一種方式相比，MG可以更自主地控制發送心跳消息的時機。

MGC仍采用針對ROOT終結點的空AuditValue命令作為心跳消息。MG采用的心跳消息待研

究。

注：目前在實現上有采用針對ROOT終結點的Notify命令作為UG心跳消息的做法，其中采

用周期性上報事件it/ito(見H.248.14),事件的RequestID為0。

這種心跳方式即是我們常說的主動心跳

【解決方法】

翻開設備的心跳功能。

【現網案例】

湖北某地AN5006-16設備開通后幾分鐘業務無法使用

通過信令跟蹤發現注冊和流程都正常，軟交換下發的審計命令也正常回復，但如果5分鐘

內沒有語音業務后，軟交換就不再下發審計命令。翻開ONU設備的主動心跳，按默認30秒發送，

問題解決。

4.7摘機有撥號音，但語音不通或單通

【問題現象】

用戶摘機后能聽到正常的撥號音，撥打號碼后能聽到回鈴音或彩鈴，但被叫用戶摘機，通話

建立后，出現單通或通話雙方都聽不到語音。

問題出現有如下幾種情況：

A.外部正常，OLT內部問題；

B.外部接通后單向無語音；

C.外部接通后雙向無語音。

【原因分析】

1.對于A類問題確認

如果屬于A類問題，只是OLT內部時才出現語音不通，很有可能跟媒體代理有關，需先弄

清是否使用OLT代理功能。媒體代理功能可以由外部的媒體效勞器或者OLT內部實現，但兩者只

能取其一。如果OLT代理功能已開啟1默認開啟），同時信令協商中又指定使用外部媒體效勞器，

那么在通話建立過程中，很可能出現爭搶作媒體代理的情況。

另外，對于AN5006-15/16設備，如果采用OLT作媒體代理，需特別注意：不要遺忘做“NGN

上聯接I」配置”。

2.對于B類和C類問題確認

語音通話能否正常取決于如下兒個因素：呼叫雙方協席的編碼方式和包間隔是否一致，RTP流

的ip和RTP流的端口號是否正確。為了確認上述幾點，這兩類問題都需通過捕獲本次通話的信令

流和語音流來加以分析定位問題。

圖4-7-1語音業務RTP流向

1）呼叫雙方協商的編碼方式是否一致：

如果編碼方式協商失敗，兩個方向的RTP流采用不同的編碼方式，那么會出現語音雙向不通。

2）協商的RTP包間隔是否一致:

當兩個方向RTP流的包間隔不同時，會出現語音單通的情況。

3）RTP流的ip和RTP流的端口號是否正確，從兩個層次加以確認（缺一不可）：

a.查看信令包，確認信令協商媒體流的本地ip和端口號、遠端ip和端口號是否成功；

b.RTP包所使用的ip和端口號是否就是信令協商出的媒體流所使用的ip和端口號，即需分

別查看兩個方向的RTP包使用的源ip地址、源端口號、目的ip地址和目的端口號是否與VOIP信

令協商結果一致。

4）檢查dspip是否配置不正確，例如dspip沖突。對于AN5006-04/05/07/09設備，語音

流使用的ip與信令ip為同一個，但是在AN5006T5/16設備中，語音流ip與信令ip是可以不相

同的，dspip代表的是語音流使用的ip地址。Dspip沖突的判斷方法：修改dspip為另一個ip

地址，化ONU側ping原dspip,能通，說明原dspip已被占用。

5）上述4個檢查點均沒有問題的情況下，在（NU側ping媒體效勞器ip地址不通，或在OLT

側只捕獲到ONU發出的RTP包，未見媒體效勞器發給ONU的RTP包，與軟交換平臺側聯系。

6）上述4個檢查點均沒有問題的情況下，ONU側只捕獲到媒體效勞器發給ONU的RTP包，需

聯系ONU側工程人員。

【解決方法】

1.外部正常，OLT內部問題解決方法

1）OLT代理功能使能/去便能配置方法

在OLTAC16盤的ngn目錄下，使用如下命令進行OLT代理功能使能/去使能配置:

OLT代理功能使能:

Config\ngn#setoptionprivatedisablearp-proxyenable

OLT代理功能去使能：

Config\ngn#setoptionprivatedisablearp-proxydisable

OLT代理功能使能/去使能顯示命令（arp-proxyprotocol選項表示代理功能使能/去使能）：

Config\ngn#showoption

privateprotocokDisable

arp-proxyprotocol:Enable

2）NGN上聯接口配置方法：

NGN上聯接口配置為圖形網管的配置界面，用于配置0NU語音業務中與軟件換平臺

（SoftSwitch）通信的相關參數。

操作步驟：

1）在“邏輯樹”窗格對象樹上右犍單擊AC16盤，在彈出的快捷菜單中選擇“配置”）"NGN

配置”,再點擊“NGN上聯接口配置”標簽°

2）單擊磁按鈕，在彈出的“請輸入增加行數：”對話框中輸入“1”，單擊“確定”，表示

新建1個上聯接口。

3）按照數據規劃，配置如下：

“業務名稱”：雙擊空白格，在下拉列表選擇該0NU當前使用的業務名稱，如

"ngrwuhan1”；

“MGC協議類型”：雙擊空白格,在卜拉列表選擇0NU使用的VOIP協議類型,如“H.248”：

"MGClIP地址或域名地址”：雙擊空白格，輸入ONU使用的軟交換平臺ip地址，如

“192.168.1.101”；

“MGC1/2/3端口號”：輸入ONU使用的軟交換平分端口號，通常H248協議端口號為

“2944”，MGCP8協議端口號為“2727”；

“心跳開關”：雙擊空白格，在下拉列表中選擇''使能”：

“DHCP配貴”：雙擊空白格，在下拉列表中選擇“去使能"（除非ONU采用dhcp方式獲

得設備ip地址,選擇“使能”）；

其它使用默認配置。

4）點擊“售”，將配置應用到設備。在窗口下部的命令窗格中，首先顯示下配置到設備“命

令成功”，然后顯示從設備讀配置“命令成功:如錯誤！未找到引用源。所示。

H.248語音業務的NGN上聯接口配置

2.接通后單向或雙向無語音解決方法

針對?“原因分析”中定位的故障點，逐一解決。

如果是信令協商失敗，比方編碼方式、包間隔。根據是哪方（軟交換平臺側或ONU側）發出

的信令包有問題，求助相關的工程人員解決。

如果是RTP流使用的ip地址或端口號有問題，哪方發出的RTP包有問題，就求助相關設備的

JL程人員解決。

如果是dspip地址不正確，請配置正確的dspip地址，通常在沒有明確說明信令ip與語音

流ip不同的情況下，dspip地址與信令ip地址相同。

【現網案例】

昆明某EPON工程出現某C類ONU撥打某些號碼正常，撥打另外一些號碼不正常的情況。

通過在OLT上聯抓包分析，發現撥打正常的通話在信令協商過程中的使用的媒體效勞器與出

問題的通話過程協商出的媒體效勞器不相同。在OLT上聯ping兩個效勞器，發現有問題的那個媒

體效勞器ping不通。于是請局方人員排查媒體效勞器到01T上聯之間的路由，確實發現了問題。

路由問題解決后，語音故障得以解決。

4.8語音質量

【問題現象】

普通通話過程中能聽到明顯的雜音，或者語音停頓。

【原因分析】

與傳統的PSTN網比擬，VOIP采用了語音壓縮編碼算法，將話音用數據包的形式在分組交換網

上傳遞，因此其對傳輸線路的時空利用率都有大幅度的提高。但VOIP也遇到了傳統不太關

注的語音質量問題，用戶有時會感覺到通話過程中隨時會出現令人難以忍受的語音畸變和頻繁的

斷話現象。引起語音質量問題的原因主要有以下兩大個方面：

1.設備硬件問題：

設備使用的電源不同，功率不同，也會影響到語音質量。同時設備如果質量有問題，也可能

導致語音質量差。

2.網絡延時、丟包和抖動；

由于是在IP網傳輸語音，所以任何影響到網絡的因素也同樣會影響到語音。延時、丟包和抖

動，任何一個因素都不能小視。

3.設備未接地，造成電磁干擾，影響語音通話質最。

【解決方法】

對于第一類問題的解決方法很簡單：那就是更換硬件，更換電源。

對于第二類問題，就需要從多方面去查找。

1.杳找網絡是否正常；

A、設備側ping媒體效勞器的IP地址，看看是否有丟包，網絡時延是否過大；

R、抓媒體流的包.通過抓包軟件進行分析.主要關注的地方是丟包和時延八

2.查找遠端產生的媒體流是否正常;

將抓到的媒體流兔原成聲音，聽復原出來的聲音是否與我們在聽筒上聽到的聲音一致，如果

一致，那就說明傳送過來的媒體流本身語音質量就不好，那就需要往上查找媒體效勞器的問題。

3.查找平臺下發的信令是否正確；

在建立通話的過程中，平臺會下發?系列的信令，而信令中有些參數的設置會影響到語音質

量，需要保證平臺卜,發的信令是正常的。例如nt/jit,tdmc/ec,tdmc/gain等等。

對第三類問題：FTTH型需要排查電源線是否為三相電源，同時檢查電源插座接地是否正常。

如果電源線為兩相，那么可能有電磁干擾。對于FTTN型ONU,需要檢查設備的接地是否正常。

【現網案例11

某地反映AN5116-02設備下掛的AN5006-07型號onu,打有較明顯的雜音，使用H。248協議。

更換硬件仍然有雜音現象出現，因此排除硬件問題。在設備端抓包，查看媒體流信息，時延

正常，沒有丟包，同時復原出來的聲音也正常，因此也排除了網絡問題。仔細查看信令，發現通

話建立的候平臺下發的Modify命令，其中一個參數配置有,可題，nt/jiPO。jit值表示抖動容限，

其功能是用來處理網絡路由質量不好，通過軟件算法解決語音上的損耗，如果jil值為0,那么表

示關閉該功能，當網絡路由稍有變化時就會影響到語音質量。設備上jit默認值是40,如果軟交

換平臺沒有下發nt/jit參數，那么設備就按默認的40來處理，如果平臺下發nt/jit參數，那么

設備就按平臺下發的參數來處理。如果軟交換平臺下發nt/jit=0,那么設備會按0來處理，這就

影響到了語音質量。解決的方法是軟交換平臺將nt/jit參數值設置成40。由于在VOIP應用中，

不能關閉抖動容限的功能，為了防止平臺以后出現類似的問題，設備對平臺下發的nt/jit參數進

行了相應的處理。如果軟交換平臺下發了nt/jit=O,那么設備按照默認的4()來處理，平臺下發的

其它值處理不變。

【現網案例2】

某地反映AN5006-07型號0NU設備通話過程中有時出現閃斷現象，表現為對方的聲音斷續或者無音，大概持

續1~2秒左右。

由于更換了硬件設備仍有亥問題存在，因此排除了硬件問題。在OLT和ONU設備上同時進行

抓包，信令正常，網絡時延也正常，也沒有丟包，排除了網絡方面的問題。

將傳輸的媒體流及原成聲音，發現也有斷續或者無音的現象，跟聽筒中所聽到的是一樣的，

這