NGN Fault Analysis SoftX3000

HUAWEI TECHNOLOGIES CO., LTD.

www.huawei.com

HUAWEI Confidential

Security Level:

NGN Fault Analysis

ISSUE 1.0

HUAWEI TECHNOLOGIES CO., LTD. HUAWEI Confidential

Introduction

Introduction

This course introduces NGN fault analysis-SoftX3000.

This course introduces how to process the typical faults of SoftX3000 in the NGN application.


After this course, you should be able to:

Know the prerequisite of the SoftX3000 fault process

Know the judging methods of the NGN fault location

Master the process methods and information recording of the NGN faults


Chapter 1 Prerequisites of SoftX3000 Faults ProcessChapter 1 Prerequisites of SoftX3000 Faults Process

Chapter 2 SoftX3000 Fault Process Information

Collection

Chapter 3 SoftX3000 Typical Faults Process Example


Prerequisites of SoftX3000 Faults Process

Know the SoftX3000 version: query the SoftX3000 version through the hidden MML command: “dsp inver:CONFIRM=Y;” or get the SoftX3000 version through selecting Help->About on the GUI and then pressing Ctrl + Shift + F12; confirm the device version matching information through the SoftX3000 Version Matching Table and make sure whether the peripheral device versions are matching each other.

Know the SoftX3000 patches information: query the patches versions and patches states (running, activated, deactivated) through the commands “DSP PATCHVER” and “DSP PATCH”.

Confirm all cards hardware states in Device Management on the SoftX3000 GUI; or confirm all cards hardware states through the MML command “DSP FRM:;”.

Confirm whether all module data is consistent with BAM through the MML command “STR CRC: MN=255;”.


Prerequisites of SoftX3000 Faults Process

Generally, we consider the SoftX3000 can run normally when the previous four conditions are met. The faults caused by un-matching version, cards abnormality and data are unknown and unexpected.

Note: For the bill problems affecting SoftX3000, you should use the MML command “DSP BILPOL:;” to confirm that there is no bill on the FCCU and then you can reset or swap the FCCU.


Prerequisites of UMG8900 Faults Process

Know the UMG8900 version: query the UMG8900 version through the MML command: “CHK VERSION: VT=BRD;” and “CHK VERSION: VT=BAM;” , And check BAM file through the MML command: “CHK FILE:;” . Also we can get the UMG8900 version through selecting Help->About on the GUI and then pressing Ctrl + Shift + F12;

Know the UMG8900 patches information: query the patches versions and patches states (running, activated, deactivated) through the commands “DSP PATCH”.

Confirm all cards hardware states in Device Management on the UMG8900 GUI; or confirm all cards hardware states through the MML command “DSP FRM:;”.


Prerequisites of UMG8900 Faults Process

Generally, we consider the UMG8900 can run normally when the previous four conditions are met. The faults caused by un-matching version, cards abnormality and data are unknown and unexpected.


Chapter 1 Prerequisites of SoftX3000 Faults Process

Chapter 2 SoftX3000 Fault Process Information Chapter 2 SoftX3000 Fault Process Information

CollectionCollection

Chapter 3 SoftX3000 Typical Faults Process Example


Information Collected before NGN Fault Location

The following information should be collected before SoftX3000 fault location:

The central office, the contact man and telephone number

Phenomenon of the fault (call module, service fault phenomenon, related device, protocol type and so on)

User information (user number, trunk group number, TID and so on), regularity (inevitability/regularity/probability), fault occur time or frequency

Operations taken before the fault

Operations taken after the fault; especially how to restore the service


Information for NGN Fault Location

Related data setting; many faults are caused by incorrect setting of the data

Calling signaling (exterior protocol trace, interior interface trace)

Network packet capture information

Log (operation log, system log)

Debug information

Alarm base

Others (serial port message and so on)


Message Trace for SoftX3000 Fault Process

The message trace of SoftX3000 should be taken in Trace Management of MONITOR in GUI. The trace can be divided in to Interface Trace Task and User Trace Task.

Interface Trace Task is the NGN related interface/protocol trace and call status diagnosis tool.

In User Trace Task, the User Interface trace and User Status trace are in common use.



User Trace Task is the effective and most common method for locating faults of SoftX3000.

In the R001 version, the maximum length of the DN is 8 digits; the last 8 digits should be taken as the DN if the whole length is more than 8 digits. For example, for 0123456789, the DN is 23456789. In the R002 and latter versions, the maximum length of the DN is 12 digits.The outgoing message Local DNSet=xx; the xx can be queried through the “LST LDNSET:;” command. The incoming message Local DNSet=65534; (ISUP/H323/SIP)



All information trace tasks have auto saving marks.

The information trace results are saved in :\SoftX3000\TRACE by default.

The file is named as date + time + trace type + sequence, such as 0312_055530_MGCP_01_1.tmf

1126_032611_MTP3_01_1.tmf

The saved message trace can be queried and analyzed through the tool of U-SYS SoftX3000 Trace Viewer.


Debug Collection for SoftX3000 Fault Process

You should right select the Debug item in the GUI output window to output the Debug of SoftX3000.

By default, the Debug switch is not on but the Debug message function runs.

The switch command of Debug is “STR SFTD:;”. Before trace, you should confirm with R&D the modules that should be traced.


SoftX3000 Log

The abnormality of running will be printed to DeviceAlarm.Log and DeviceAlarmLog.bak files in e:\mssql\data. These two files are important for locating system switchover, shutdown and reset.

Use the “LST CMDLOG” command to query the operation log of the system.

The D:\SoftX3000\RunLog directory contains the log of each process in the SoftX3000 system: maintain, exchange, dataman, stats and so on. The logs should be analyzed when the daemon maintenance system fails, such as a process of bamservice cannot start.

The STXBAM.INI file is in D:\SoftX3000; it defines the SoftX3000 BAM parameters.


Alarms Collection for SoftX3000 Fault Process

The SoftX3000 alarms can be divided as event alarm and fault alarm. When the system reckons that the event alarm reaches the level of fault alarm, the alarm window will be switched to fault alarm window.The mapping alarm record table is the tbl_WarnReason in the ALARM database. This table contains process suggests.In the MML, you can use the LST ALMLOG command to collect the needed alarm information.Before process, check whether there are fault alarms.


Exchange Information Collection for SoftX3000 Fault Process

The output switch of the SoftX3000 Exchange should be switched on through Ctrl+Shift+F12

After selecting output switch, you should select the output information type and information output direction.


Guide to Collecting Location Information of Core Network NGN Network Failure

On Support.huawei.com, there is a document 《 Guide to Collecting Location Information of Core Network NGN Network Failure-20050908-A 》 to tell us how to Collect Information.


Gateway/Terminal Register Fault

[Phenomenon]

The service gateway (MGCP/H248) and the multimedia terminal (SIP/H323) cannot register to the SoftX3000

[Fault information collection]

1. Version (the version of the SoftX3000 and the service gateway or multimedia terminal)

2. Networking and service application (such as whether the signaling agent is taken for networking)

3. Query the data setting through “LST MGW + LST VSBR/LST MMTE + LST MSBR”

4. For MGCP/H248 gateway MGW (IAD/AG/UMG), the signaling trace is important

Operation:

The trace operation of MGCP/H248 interface is rather simple. Double click the MGCP/H248 in the Interface Trace Task and then input the MGW mapping EID in the displaying dialog box.



Note: As the trace is taken for the whole MGW, the MGCP/H248 signaling of all subscribers of the gateway can be traced and so the number of messages is rather large. Therefore, you should select “Auto Save to File” for the trace. Do not trace multiple gateways at the same time to avoid affecting the BAM performance. As the H248 can trace single TID, for the H248 user, you can trace the TID distributed to the user only (the command LST VSBR can query the EID and TID of the user gateway). Currently, the MGCP gateway does not support tracing single TID.



For the register fault of multimedia terminal (SIP/H323), you should take signaling trace.

Open the Monitor\Maintenance Navigator\Trace Management\Interface Trace Task\H323(SIP) in the SoftX3000 maintenance console and input the peer end IP in the following dialog box and then click OK.


Protocol (MGCP/H248/H.323/SIP/ISUP/PRA) Fault

[Fault phenomenon]: Basic call fails, modem/FAX is blocked

[Fault information collection]:

1. Software version (SoftX3000 and MGW)

2. Networking, service type and call module

3. Query the data configuration through the “LST MGW/LST VSBR/LST MMTE/LST MSBR” command.

4. Protocol message trace

5. Use Interface signaling trace and this is the most common method for locating SoftX3000 fault.

a) If the trunk is passed, choose the related trunk checkbox; for example, when the PSTN user is called, the ISUP trunk is passed, and the ISUP checkbox should be chosen

b) The trunk incoming call can be traced through the caller number; Local DN set should be filled as 65534



Tips ①As the H248 can trace single TID, for the H248 user, you can trace the TID distributed to the user only (the command LST VSBR can query the EID and TID of the user gateway). Currently, the MGCP gateway does not support tracing single TID.

Because the H323 call contains the negotiation of TCP protocol. (H323 protocol use TCP to establish H225 or H245 connection). But now SoftX3000 only can trace Q.931 and H245 protocol and cannot trace TCP protocol, thus we should capture packets of IFMI FE port for analysis.The right flowchart describes communication between fast-start H323 subscribers. Note the TCP negotiation part. 。



Tips ② For incoming SIP/H323/ISUP call, if you want to trace caller inter-

module message, you can input the subscribe number of "from" field of INVITE message (SIP trunk) or the subscribe number of "calling party number" field of SETUP message(ISUP/H323 trunk); and Local DN set must be 65534 。

---------SIP/H.323/ISUP trunk-------(incoming call)--------> SoftX3000

On the Softx3000, execute the MOD MGW command to modify the MGW attribute parameters. Delete “SDP HEX” to support clear text. The SDP part in the H.248 message sent from the SoftX3000 to the UMG can be changed into clear text.


Accounting Failures

[Failure Phenomenon]

Bill format is incorrectAccounting type is incorrect, etc.

[Failure Information Collection]

Version information (SoftX3000+iGWB)Service type and call modelBill format database and bill filesBill trace message 、 inter module message and protocol message

For caller or callee bill trace, the physical numbers of caller or callee and the local DN set should be inputted. For trunk bill, only inputting the trunk group number is enough.


Service Fault

[Fault phenomenon]

Basic service fails

Supplementary service fails

[Fault information collection]

Software version (SoftX3000 and MGW)

Networking, service type and call model

Test operation process

Service configuration and related services registering information

Inter module trace

Protocol message trace


Number Format Failures


The number displayed format does not meet the customers’ requirements

The number format on the bill does not meet the customers’ requirements

The other fields in the bill do not meet the customers’ requirements

[Failure Information Collection]

Version information (SoftX3000 and MGW)

Networking structure, service type and call model

Execute LST MGW/VSBR to display the data configuration

Check the related software parameters in the software table (LST FSFP)

Take message trace for related protocols according to call model. If the call relates trunk (ISUP, PRA, R2, SIP, H323 and so on), trace for trunk signaling is necessary.

For failures related bills, bill trace operation is necessary also.


Common Location Tools

Ethereal --- Capture/Analyze data packet tool

Audio transiting tool of PESQ and so on---Transit data packet as audio

GetiGWBinfo --- Capture iGWB location information


Packet Filtering of EtherealInput the condition directly, such as “mgcp”

You can also set multiple conditions for filtering


Packet Analysis and Audio Restoring of Ethereal

1. Packet analysis

2. Audio restoring

3. Call flow chart display


Audio Restoring Tool

IPVQT

It can transit most packets of code/decode G.711, G.729, G.723 to .wav file.

Soft phone.cap


GetiGWBInfo

GetiGWBInfo is used to collect iGWB running information and configuration , then generate file “iGWB_0.ARJ” .


Questions

From the real packet analysis, you can get the follows.

1. SoftX3000 IP address

2. Caller gateway IP, callee gateway IP

3. callee number

4. The packet sequence numbers of the key points in the call process

5. The ports numbers adopted by the protocol and the medium

call


Chapter 1 Prerequisites of SoftX3000 Faults Process

Chapter 2 SoftX3000 Fault Process Information

Collection

Chapter 3 SoftX3000 Typical Faults Process ExampleChapter 3 SoftX3000 Typical Faults Process Example


Example of SoftX3000 Typical Fault Process

H.248 MGW fail to register MGC

MRS announcement error

One-way audio fault process

Digit Map causes slow connection

Time inconsistence in CDR Problem

No Ring Back Tone Problem

PPS service secondary number receiving fault




SoftX3000 interconnect with 3rd party H248 IAD ， but the IAD cannot register to softswitch. First, let’s look at the DH authentication flow, as follows:

MGW MGC

1 SVC CHG REQ

2 SVC CHG RLY

4 MOD RLY

3 MOD REQ

6 MOD RLY

5 MOD REQ



[Analysis Process]

The register messages are as follows:

The event numbers of the 9th, 10th and 11th messages are the same and the interval is 1 second. It indicates the SoftX3000 has re-sent the MOD message for three times and not received the response message from the gateway. Four seconds late, the gateway sends the MOD_REPLY message (the 13th message).

The cause of this problem is that the gateway does not process DH authentication message in time.



RFC3525 《 Gateway Control Protocol Version 1 》

D.1.5 Repeating Requests, Responses and Acknowledgements

The protocol is organized as a set of transactions, each of which is

composed of a request and a response, commonly referred to as an

acknowledgement. The protocol messages, being carried over UDP, may

be subject to losses. In the absence of a timely response,

transactions are repeated.

… …

It is, however, important that the maximum delay of retransmissions

be bounded. Prior to any retransmission, it is checked that the time

elapsed since the sending of the initial datagram is no greater than

T-MAX.



[Solution]

This problem can be evaded through configuration. Execute the “SET BCPARA” command to modify the event timer as 2 seconds. Then, the interval of SoftX3000 sending MOD message becomes 2 seconds; the time of waiting gateway response becomes 6 seconds. The key of the problem is that the gateway responds DH authentication message slowly.

SET BCPARA is used to set bearer control parameter.

%%LST BCPARA:CONFIRM=Y;%%

RETCODE = 0 Operation succeeded

BC timer information

--------------------

Transaction retry count = 5

minimum heartbeat Period = 28

Link failure detection count = 3 //Specify the number of times of audits in which the MGC (that is, the SoftX3000) detects UDP link failure.

Transaction timer in milliseconds = 2000//Specify the duration of the transaction timer in millisecond


H.248 MGW fail to register MGC H248 DH authentication flow: the first released key algorithm is in the thesis

by Diffie and Hellman; so the algorithm is called Diffie-Hellman key switch.

① The gateway reports register request SVC CHG REQ

X-EA: algorithm number; X-RANDOM: random number; X-DH: value switched with DH

MEGACO/1 [182.20.20.123]:2944 T=30630883{C=-{SC=ROOT{SV{MT=RS,RE="901",X-EA=100,X-DH=0004000000000000,X-RANDOM=8271FDF179322101953110D3893B8E7F2F2B772A788FFB3A1688B2FC90F32A95D4AD4CFCE7EA36E74709D84AAB560FE2A412E673DBD261A0E9F4DE17F9BCEDE6,X-AUTH=bf083ead0ba36b111579e9cedf43c64f}}}}

② The SoftX3000 respond:

MEGACO/1 [182.20.20.1]:2944 P=30630883{C=-{SC=ROOT{SV{V=1}}}}

MGW MGC

1 SVC CHG REQ

2 SVC CHG RLY

4 MOD RLY

3 MOD REQ

6 MOD RLY

5 MOD REQ



③ SoftX3000 send MOD REQ to the gateway (random number of share key and algorithm ID) auth/authdh: Used to exchange DH key

MEGACO/1 [182.20.20.1]:2944 T=379453451{C=-{MF=ROOT{SG{auth/authdh{dhkey=0008000000000000},auth/authreq{key=b4b36a36f53cb5ba7b718f458d5c63c8,ea=100,random=011B2F333D91C01DA50D0DAB338D7E5E}}}}}

④ The gateway respondMEGACO/1 [182.20.20.123]:2944 P=379453451{C=-{MF=ROOT}}

⑤ SoftX3000 authenticate it and reply MOD REQ to the gatewayMEGACO/1 [182.20.20.1]:2944 T=379584524{C=-{MF=ROOT{SG{auth/authreq{key=b3097e3d5f6f2d101d661c8defac14af,ea=100,random=3ee66874a63ab1c39311a864c7dbcae0}}}}}

⑥ The gateway respondMEGACO/1 [182.20.20.123]:2944 P=379584524{C=-{MF=ROOT{SG{auth/authreq{ea=100,key=35321f349cafe3162a40e641e861aa34}}}}}



[Configuration]MOD MGW is used to configure the authentication data of H248 gateway:MOD MGW: ET=DH, KEY="12345678", DHMGID="abcdefgh";① KEY ： It is one of the parameters used for interworking with a media gateway.

When MGCP/H.248 messages between the SoftX3000 and a media gateway need to be encrypted, this parameter is used to define the key required by the MD5 encryption algorithm or the DH authentication algorithm. It is a string of 8 to 16 characters (eight characters at least). 。

② DHMGID ： It is one of the parameters for the SoftX3000 to interconnect with a media gateway. When the DH authentication algorithm is needed between the SoftX3000 and a media gateway, this parameter defines the gateway ID used in the DH authentication procedure.

Gateway ID contains the manufacturer and equipment information of the media gateway, and it is unique for a media gateway. It is a string of 8 to 16 characters.

③ In the gateway, the key and the DHMGID also should be configured and they must be the same as SoftX3000.


MRS Announcement Error

For example, after the IAD user dials 117(time announcement), but MRS play the wrong tone.

The following is the MGCP message flow that IAD104 plays 117 tone through built-in MRC.

IAD104:190.1.100.2; SoftX3000: 190.1.1.1; MRC:190.1.100.3



MRS6000 tone index maps the RQNT index of MGCP incorrectly

A. Trace the MGCP message of MRS, and then view the “an” field of the RQNT packet




B. In the MRS tone index file “SxAudioCfg.xml”, query the RQNT AN field HWXXXXXXXX mapping decimal numner.

Note: the “.XML” is saved in the directory of BAM D:\DATA\VOICE by default.

SxAudioCfg.xml




C. On the MRS, reload the needed tone file according to the queried clipIndex

Note: the following SxLoadBasic.bat is the MRS default batch loading tone script

SxLoadBasic.bat


Code Negotiation Causes Call Failure

When A calls B, the communication is normal; when B calls A, after A picks up the phone, the two parties hear busy tone.

The following is the one-way audio of IAD132 calls IAD208. IAD208 config audio code PCMA and G.729, IAD132 only config G.723 audio code. When the IAD208 calls IAD132, after IAD132 picks up the phone, the communication is disconnected immediately.

Code Negotiation Causes Call Failure.tmf


One-way Audio Problem (SIP)


The third-party SIP terminal calls SIP openeye and the coding negotiation succeeds; however, the one-way audio problem still exists.

[Analysis Result]

The packet time of the rtp packets that SIP terminal send out is different with the result of SDP negotiation.

sip to openeye


One-way Audio of Videoconferencing Terminal and IAD

The H323 terminal of the videoconferencing network calls IAD on the NGN; after negotiation success, one-way audio occurs. Can the doubtful points be found on signaling and medium stream?

H323 to iad


Digit Map Causes Slow Connection

The ring back tone can be heard long after the callee number is dialed through the IAD.

Note: Digit Map is the number receiving solution of gateway (IAD) indicated by MGCP/H248 protocol.

Digit Map Causes Slow Connection.tmf



Rule 1: The analysis speed of the callee prefix will not be affected by the digit map. In case of no digit map matching the callee prefix, IAD or AG will report the received number after time-out waiting. The time-out time is 4 second generally.

Rule 2: A DN set maps a digit map. For sending MGCP or H248 messages, if the set digit map is not found, a default one will be sent.

H248: [2-9]xxxxxx|13xxxxxxxxx|0xxxxxxxxx|9xxxx|1[0124-9]x|E|[0-9EF].L

MGCP: [2-9]xxxxxx|13xxxxxxxxx|0xxxxxxxxx|9xxxx|1[0124-9]x|*|x.#|[0-9*#].T

Case: If the minimum digit of the prefix 2 is 7, and the user dials 201 without other numbers; then, after how many seconds, the SoftX3000 will disconnect the connection------20 seconds; if the digit map is incorrect, there should be another 4 seconds delay of IAD/AG.

Note: Currently, the digit map is applied to MGCP user and H248 user only. On the SoftX3000 side, you can use the “LST LDNSET” command to query.



The following is the message trace of call in the same IAD. Number A AALN/1 is 65432199 ; number B AALN/3 is 234567.

Note the time difference between the first RNQT and NTFY of the two calls.


Time inconsistence in CDR Problem [Failure Phenomenon]

The SoftX3000 and the opposite central office interconnect PRA. It is found that the communication durations on the SoftX3000 side and the PSTN side are not consistent.

[Analysis Process]

1. Generally, the method to solve the problem is to make dialing test, get the signaling of failed call and take analysis of the opposite PSTN bill. The required signaling contains inter module message, bill trace message, protocol trace message.

2. First, we analyze the bill message:

The right picture describes the local central office (SoftX3000) bill message. The data in the red frame is required. We can see that the beginning time of the communication was 2005-04-26 11:14:17; the ending time of the communication was 2005-04-26 11:16:22; the duration is 125.42 seconds.

Note: the communication duration is the value of the “conversation time“ (12542) with the unit of 10ms; the real communication duration is 12542*0.01=125.42 seconds.



Then, analyze the internal module information. The time of the bill begins when the callee sending Connect message to the SoftX3000 and ends when the SoftX3000 sending Release message to the caller and callee. The following analyzes SoftX3000 internal message trace in the same communication. In the black frames, you can see that the SoftX3000 received the Connect at 2005-04-26 11:14:17; the SoftX3000 sent Release at 2005-04-26 11:16:22. The time were the same with the communication beginning time and ending time in the bill. The communication duration was calculated accordingly.



At last, check the message interaction with the opposite end. The SoftX3000 received the Connect message from the opposite at 2005-04-26 11:14:17; at this time, the SoftX3000 began to charge the opposite end. The SoftX3000 sent the Release message to the opposite end at 2005-04-26 11:16:22; at this time, the SoftX3000 stopped charging the opposite end. They are consistent with the information in the SoftX3000 internal trace and the bill.

From the previous analysis, we can judge that the SoftX3000 processes the communication duration well. The problem should be solved by the opposite end.




SoftX3000

|

Network diagram ： IAD——UMG8010——PRA trunk——GSM

IAD call GSM subscribe via UMG8900 and PRA trunk but cannot hear ring

back tone. After callee pick up the phone, they can hear each other.[Analysis Process]

The following is the call flow, the ring back tone is played by landing office 。


No Ring Back Tone Problem Whether caller has prepared for hearing tone? Whether TMG has transmitted th

e ring back tone? Whether callee has played ring back tone?

1. After analyzed the MGCP and inter-module message, we known that the call flow is : IAD subscribe picked up the phone at 17;00:40 and heard dialing tone, then dialed callee number.SoftX3000 sent CRCX message to IAD at 17:00:42 and request IAD create rtp endpoint and mode is “receive only”.

2. Then, IAD reported SDP information in CRCX_RSP message and it included RTP IP and port, IP address is 10.96.5.68 and port is 30000.

trace message.zip


No Ring Back Tone Problem3. The PRA side took the operation of occupying circuit at 17:00:42. The TMG returned

callee side port information: the IP address was 10.81.46.2 and the port was 14420:

4. At 17:00:53/17:00:54, the Progress and Altering of the callee were received to indicate announcement.



5. At this time, on the caller side, the sx3000 sent MDCX message to IAD; and the connection mode was “receive only”. The remote RTP IP and port were sent; the port information was consistent with the one when the callee PRA side reserving (occupying) circuit.

6. From the signaling flow, we can see that the preparation for hearing the tone is finished. At this time, the caller can hear the tone. From the previous analysis, we can conclude that maybe, the callee side does not play the announcement and the signaling flow is correct.

7. At last, it is found that the firewall setting of the callee side is incorrect. After the setting is modified, the caller can hear the ring back tone and the communication is normal.


PPS Service Secondary Number Receiving Fault

The networking is as follows. The call flow is: a PSTN subscriber dials UNICA access code through the TMG; after hearing prompt tone, he input the PIN code and the password, but there is no response. It seems that MRS6100 interconnected with UNICA has not received the dialed secondary number.

Caller->-TMG8010->-SoftX3000->-[sip]->-UNICA->-[sip]->-MRS6100


PPS Service Secondary Number Receiving Fault Know the call flow: after the PSTN subscriber dials and hears PPS ser

vice tone (please input the card number”, the normal flow should be as follows.

The inputted PIN code is sent to TMG and TMG sends the code to MRS6100 through dtmf or rfc2833 mode; then, MRS6100 sends the code to UNICA.

1) Query the secondary number receiving modes of TMG and MRS6100. execute the command “sh ipp-ch [VSU/VSP slot number]” on TMG and the result is rfc2833 mode, which is consistent with MRS6100.

TMG8010(config-dbms)#show ipp-ch-cfg all …(some outputs are omitted)… --G.723.1 code rate :6.3kbps --Support rfc2833(Generating special DTMF payloa

ds) :support



You can use the MOD command to modify the 2833 mode: TMG8010(config-dbms)#mod ipp-ch-cfg sn 0 spe ?

0 Not support

1 Support(PT=97)

2 Support(PT=96 Redundancy mode)

ENUM Support rfc2833(Generating special DTMF payloads) Maybe, MRS6100 does not receive the rfc2833 packets sent by

TMG; or the received rfc2833 packets are incorrect. Capture the packets before MRS6100 to analyze the packets.

TMG8010 to MRS6100



From the packets, you can see the contents of 2833 and you can separate the number. The protocol specifies the 2833 RTP load format as follows:

Event: indicates DTMF event.E: indicates beginning and ending of event. When the value is 1, it indicates a DTMF event ends.

MRS6100 judges a dtmf signal according to the following two standards:

1. The value of E is 1.

2. The timestamp value of rtp packet in each rfc2833 is the same.



Timestamp: The RTP timestamp reflects the measurement point for

the current packet. The event duration described in Section 3.5

extends forwards from that time. The receiver calculates jitter for

RTCP receiver reports based on all packets with a given timestamp.

Note: The jitter value should primarily be used as a means for

comparing the reception quality between two users or two time

periods, not as an absolute measure.

Marker bit: The RTP marker bit indicates the beginning of a new

event.

1) The timestamp of sending a DTMF RTP packets should be the same.

2) Use Marker to indicate the beginning of a new DTMF.



Analyze the previous packets to find the timestamps of 2833 packets are different. Maybe, the packets sent by TMG8010 contain faults.Capture packets before TMG8010. If you cannot capture packets through port mirroring, you can execute the debugging command on TMG8010 to print information of 2833 packets and then analyze the timestamp information of the 2833 original packets sent by TMG.This fault is located as a firewall modifies the 2833 rtp packet contents.

rfc2833 from tmg.cap

tmg spi.rar

Thank You

www.huawei.com

NGN Fault Analysis SoftX3000

Documents

Transcript of NGN Fault Analysis SoftX3000