利用H.248協(xié)議挖掘通知機隱性故障

張燕君 陳 俊 廣東宜通世紀(jì)科技股份有限公司

1 引言

隨著下一代網(wǎng)絡(luò)（NGN，Next Generation Network）技術(shù)的不斷發(fā)展，作為其核心的軟交換技術(shù)已經(jīng)廣泛應(yīng)用于各運營商和通信設(shè)備廠商。軟交換是NGN的控制功能實體，為NGN具有實時性要求的業(yè)務(wù)提供呼叫控制和連接控制功能，其核心思路是通過業(yè)務(wù)與呼叫控制分離、呼叫控制與承載分離實現(xiàn)相對獨立的業(yè)務(wù)體系。呼叫控制由MSC SERVER設(shè)備實現(xiàn)；連接控制由傳輸設(shè)備和媒體網(wǎng)關(guān)（MGW，Media GateWay）組成，回聲抑制器、編解碼器和通知音等資源已經(jīng)移植到媒體網(wǎng)關(guān)。

軟交換是多種邏輯功能實體的集合，各實體之間通過標(biāo)準(zhǔn)的協(xié)議進(jìn)行連接和通信。H.248協(xié)議是軟交換與媒體網(wǎng)關(guān)之間的標(biāo)準(zhǔn)接口協(xié)議。在呼叫建立過程中，H.248協(xié)議通過命令建立終端，描述終端的屬性，控制在MGW中的資源。由于H.248協(xié)議信令攜帶了終端、資源、請求的結(jié)果應(yīng)答等信息，通過信令分析手段對H.248進(jìn)行分析，可以更詳細(xì)地進(jìn)行通知音資源的故障定位以及隱性故障挖掘，幫助運營商提升用戶感知度，增強運營商的競爭力。

2 軟交換通知機原理

在移動網(wǎng)中，通知機是用來為客戶提供數(shù)字通知音服務(wù)的設(shè)備，利用通知音正確地引導(dǎo)用戶行為。通知機設(shè)備通過裝載不同的配置數(shù)據(jù)和音軌內(nèi)容，分別為普通GSM用戶和智能網(wǎng)預(yù)付費（PPS）用戶服務(wù)。錄音通知機廣泛地應(yīng)用于愛立信設(shè)備的MSC SERVER/MGW、GW等網(wǎng)元中。

愛立信軟交換MSC SERVER把普通通知音或智能網(wǎng)通音的語音號（ANNC）和通知音變量（智能網(wǎng)通知音才有，變量對應(yīng)于年月日、圓角分等變量）使用H.248協(xié)議命令下發(fā)給MGW，MGW得到ANNC號后查找得到對應(yīng)的通知音信息（MESSAGE_ID，MESSAGE_ID=ANNC），再通過對應(yīng)的信息調(diào)用通知機音軌進(jìn)行播放。

3 通知機的H.248信令流程

H.248工作在主從模式，并定義了連接模型，如圖1所示。連接模型中有終端、流以及上下文。終端是出/入分組網(wǎng)絡(luò)的媒體流的連接，它允許信號應(yīng)用到媒體流上，如發(fā)送忙音；也允許從媒體流中接收發(fā)生的事件，如收到DTMF信號。上下文則是將終端上媒體流混合并橋接在一起，且描述媒體流之間的關(guān)系。

在呼叫建立過程中，網(wǎng)關(guān)控制協(xié)議（GCP）通過命令建立終端，描述終端的屬性，控制在MGW中的資源。

（1）正常流程

播放通知音的H.248正常信令流程如圖2所示：

1）Play Announcement Request消息，本地MGW接收從MGC發(fā)來的包含在SignalsDescriptor（信號描述符）的Generic Announcement Package。如果是ADD命令，則本地MGW為通知音產(chǎn)生一個終端，同時將它加到媒體流里；如果是Modify命令，則本地MGW把指定的終端作為通知音終端。該消息中包括交換機中定義的通知音編號、通知音播放的方向、信號的類型及信號完畢提示等信息。

2）Play Announcement accepted消息，本地MGW回答MGC通知音已經(jīng)開始。

3）Announcement Completed Notify消息，通知音播放完畢，根據(jù)信令描述，本地MGW需要通報MGC通知音的播放情況。

4）Notify Reply消息，MGC返回確認(rèn)消息給本地MGW。

5）Release Termination Request消息，本地MGW接收從MGC發(fā)來的釋放通知音Termination（終端）的請求。

6）Release Termination accepted消息，本地MGW釋放終端后返回給MGC確認(rèn)消息。

（2）異常流程

播放通知音的H.248異常信令流程如圖3所示：

圖3 播放通知音的H.248異常信令流程

1）Play Announcement Request消息，本地MGW接收從MGC發(fā)來的包含在SignalsDescriptor（信號描述符）的Generic Announcement Package，請求分配終端及播放通知音編號等信息。

2）Play Announcement Rejected消息，由本地MGW向MGC發(fā)送拒絕通話音播放的消息。

通知音播放拒絕的錯誤代碼如表1所示。

表1 通知音播放拒絕的錯誤代碼

4 應(yīng)用案例

4.1 案例一

本次信令追蹤通過在愛立信的MGW上輸入追蹤H.248信令命令，進(jìn)行信令消息的提取和保存，再進(jìn)一步分析信令結(jié)果。

首先，提取MSC SERVER向MGW發(fā)送播放通知音的請求消息，通過ADD REQ命令指示資源占用為通知音設(shè)備及資源的屬性，結(jié)果如圖4所示，可見MSC SERVER指示MGW播放Announcement通知音編號為122的通知音。

圖4 ADD REQ請求消息

然后，MGW通過ADD RSP消息回復(fù)給MSC SERVER，執(zhí)行播放音的這個動作要求的結(jié)果，從信令結(jié)果來看MGW拒絕了播放通知音，同時攜帶了拒絕的原因，其原因可見為ErrorCode:514，表示MGW無法播放指定的通知音，如圖5所示：

圖5 ADD RSP響應(yīng)消息

通過以上MSC SERVER和MGW的交互，可以找出播放通知音編號122時出現(xiàn)錯誤，說明通知音播放不成功，用戶無法正常接續(xù)而且沒有任何通知就斷了，這將造成用戶的感知很差，可以指導(dǎo)維護(hù)或者相關(guān)分析人員開展通知音的排查及故障來解決。

4.2 案例二

通過專用設(shè)備采集H.248協(xié)議信令，利用海量的信令數(shù)據(jù)對某地市的播放通知音請求和執(zhí)行結(jié)果進(jìn)行統(tǒng)計及分析，從某個小時統(tǒng)計數(shù)據(jù)結(jié)果發(fā)現(xiàn)某個通知音編號拒絕次數(shù)特別高。

通過ADD REQ命令指示資源占用為通知音設(shè)備及資源的屬性，結(jié)果如圖6所示，可見MSC SERVER指示MGW播放Announcement通知音編號為20。接下來MGW通過ADD RSP消息回復(fù)給MSC SERVER執(zhí)行播放音的這個動作要求的結(jié)果，從信令結(jié)果來看MGW拒絕了播放通知音，同時攜帶了拒絕的原因，其原因可見為ErrorCode:514。

圖6 ADD REQ消息和ADD RSP消息

此外，從某個小時的H.248信令數(shù)據(jù)中統(tǒng)計出來通知音編號出現(xiàn)的拒絕次數(shù)高達(dá)1322次，用戶使用量極高，影響用戶面極大，指導(dǎo)維護(hù)和分析人員重點解決該問題。從呼叫控制層面SERVER上檢查是否需要播放該通知音編號，數(shù)據(jù)配置上有其對應(yīng)的通知音編號的放音需求，當(dāng)普通用戶起呼時對號碼“*”、12592、12594、12595、12599會指示播放通知音編號20。同時資源承載于MGW上實現(xiàn)的，轉(zhuǎn)而分析MGW上的數(shù)據(jù)配置，發(fā)現(xiàn)MGW上未有該音出現(xiàn)，因此故障可以定位為MGW上的通知機數(shù)據(jù)配置問題。

5 結(jié)束語

在軟交換網(wǎng)絡(luò)結(jié)構(gòu)中，MGW作為承載部分受MSC SERVER的控制，它們之間的接口上傳遞的H.248協(xié)議消息非常重要，用于兩個節(jié)點間進(jìn)行連接和通信。通過分析H.248信令中的通知音資源分配請求及執(zhí)行結(jié)果消息，可以方便統(tǒng)計通知音出現(xiàn)故障的通知音編號和出現(xiàn)拒絕次數(shù)，以及定位通知機問題發(fā)生的機率和問題的挖掘，起到重要的故障指導(dǎo)和定位作用。運用新的信令協(xié)議分析手段排除網(wǎng)絡(luò)問題、服務(wù)用戶、增強用戶感知，更能提升運營商的競爭地位。

[1]中國移動通信集團公司. 中國移動Mc接口（H.248協(xié)議）技術(shù)規(guī)范[Z]. 2006.

[2] ITU-T recommendation H.248. Media Gateway Control Protocol[S]. 2000.

[3]華為技術(shù)有限公司. WA330009 H.248協(xié)議分析ISSUE3.0[Z]. 2008.

[4] 愛立信有限公司. mmgw_r5_r2b.alx[Z]. 2009.

[5] IETF RFC3525 Gateway Control Protocol Version 1[S].2003.

[6] 糜正琨,王文鼐. 軟交換技術(shù)與協(xié)議[M]. 北京: 人民郵電出版社, 2002.

[7] 趙慧玲,葉華. 以軟交換為核心的下一代網(wǎng)絡(luò)技術(shù)[M].北京: 人民郵電出版社, 2002.