NGN Product Training Technical Cases

NGN Product Training Technical Cases
2012
Table of Contents
Chapter 1 SoftX3000 Cases .........................................................................................................1 1.1 Not able to Dial Centrex short code due to wrong digit map sent by softx ......................1 1.2 How to set Brazilian Automatic Collect Call rejection .......................................................1 1.3 Default value of ISUP Special Tone Timer is very small, caller cannot hear long announcement .............................................................................................................................4 1.4 session internal was different cause sip calling fail ..........................................................5 1.5 Parallel ringing service not working when call coming from non-softx subsciber ............6 1.6 What is the relationship between RV value and payload value of RFC2833 ...................6 1.7 MSBR subscriber unable to recieve incoming calls problem due to wrong SIP port number .........................................................................................................................................7 1.8 Softx3000 - No Route Available caused by IAM type ......................................................9 1.9 No SDP information in 183 message sent cause no ringback to A side. ...................... 11 1.10 Call duration control base on prefix CNACLD destination is not working due to incorrect softwareparameter. ................................................................................................................... 12 1.11 How to trace the R2 message in the softx3000 ............................................................ 14 1.12 Incoming voice call to certain BRA Terminal fail due to missing 'progress indicator' in SETUP ...................................................................................................................................... 15 1.13 CPG message with status=ALERTING will overwrite the actual ACM time in CDR with the time stamp of CPG(status=ALERTING) ............................................................................. 15 1.14 what is the INAP version used between NGN SX and fixed IN SCP ............................ 16 1.15 One way speech due to ptime value not matching in SDP message ........................... 17 1.16 wrong code was added with Caller Number in CDRs due to wrong Software parameter setting 19 1.17 SIP Terminals unable to register with SoftX3000 if deregister due to power outage or network disconnection .............................................................................................................. 21 1.18 How to send voice and video call through separate Trunk Group ................................ 22 1.19 How to configure SOSM interception when used UMGmini (ssm -4) for TG and IGW. 23 1.20 Charging source code incorrect causes no CDRs generated for the calls received in SX from a certain TG ...................................................................................................................... 24 Chapter 2 iGWB Cases ............................................................................................................. 26 2.1 How to configure save one copy of CDR in igwb for sepcial CDR ................................ 26 2.2 Call Termination reason in CDR.................................................................................... 26 2.3 Remote site iGWB login failed due to the Wrong client port configuration ................... 27 Chapter 3 MRS6100 Cases ....................................................................................................... 29 3.1 Eliminate annoucement tone files consist of both Chinese and English tone to English RVA 29 Chapter 4 UMG8900 Cases ....................................................................................................... 30 4.1 Newly installed FVPD board in mini UMG expansion didn't start and influence to service of installed board....................................................................................................................... 30 4.2 What is the difference between G711_VAD_NORMAL and G711_VAD_OPTION ...... 31 4.3 How to set Wrong Ptime for G723 codec to release the call immediately before IAM or select different codec and ptime. .............................................................................................. 31 4.4 Different Ptime in RTP packets and Signaling causes one-way audio ......................... 33
Chapter 5 SG7000 Cases .......................................................................................................... 36 5.1 How to check the SCCP loop ........................................................................................ 36 5.2 STP deletes F character from end of called number in the IAM message after number changing operation ................................................................................................................... 37 5.3 SG7000 can't forward message to HLR after FNR process ......................................... 39
Chapter 1
SoftX3000 Cases
1.1
Not able to Dial Centrex short code due to wrong digit map sent by softx
Information Type: Update Time: Fault Type: Permission Level: Symptom:
Troubleshooting Cases 2012-09-03 14:35:52 Data Configuration 02Huawei Partners Permission In Softx3000 V300R010C03SPC223 Customer Not able to dial centrex short codes starting with 6 and 2.Not able to use" * " in dialing for centrex activation and deactivations. NA In This we checked that after off hook softx sends centrex digit map to ESL in MOD RE Q ,But this digit Map not include 6 and 2 digits so customer not able to dial digit 6,2 .it i s checked that no configuration is their for centrex digit Map, so new digit maped in ADD CXGRP. We have followed below steps:1.Checked Traces suggested customer to change Digit Map 2.As customer digit map not showing changed in trace even after configuration change in LDN SET 3.Explained customer that change in LDN SET will change normal call digit Map,that is second Digit Map in traces 4.Suggested to add digit map in ADD CXGRP and add 6xxx and 2xxx and E for "*"
Alarm Information: Cause Analysis:
Handling Process:
Suggestions and Summary: Attachments:
in case of centrex subscribers two digit map will be send to subscriber first for centrex and second for normal dailing. noida_ss_Interface_Signaling_Trace_2012-08-24-17-00-05.tmf
1.2
How to set Brazilian Automatic Collect Call rejection
Troubleshooting Cases 2012-08-31 10:08:14 Service 01Huawei Engineers Permission Product Line: SOFTX3000 SW version: V300R010C03SPH218 In the Brazilian Telecom network, there is a specific scenario which is called Automatic Collect Call. When caller side does not want to pay for the call, it dials the automatic collect call prefix code and the called number. Called side answers the phone, an announcement is played telling that is a collect call and if called side stays on the call, it will pay for the bill. In some situations, called side does not want to receive this type of call at all, then SoftX3000 can provide
NGN Cases
this setting. The following Call Scenario example can depict this case:
Chapter 1
SoftX3000 Cases
A-> TDM -> ISUP -> SX3000 -> SIP-I -> IN Platform -> SIP-I -> SX3000 -> B Definition:
A subscriber: Any subscriber type that does not belongs to SX3000. In this case, A is calling to B side through ISUP signaling protocol. It dials the Collect Call Prefix Code + B number. B subscriber: VSBR subscriber that has Automatic Collect call barring.
None In the Brazilian Standards for ISUP protocol, when Caller Side is making a collect call, the bit M in the Forward Call Indicator of the IAM message is set to 1 and sent to destination point code.
In this call scenario, B subscriber will pay for the bill when the call is answered and accepted. In s ome cases, B subscriber does not want to receive this type of call and in this point SoftX3000 can be configured to reject it.
Handling Process:
SoftX3000 V300R010C03SPH218 has a specific patch for Brazil on which a modification needs to be done in the VSBR table to reject the automatic collect call. The parameter Call-in Authority needs to have the value Custom Call-in Authority 9 set to 0.
The automatic collect call will be rejected when this parameter is set in the MOD VSBR command. This configuration is applied when ISUP IAM message has the bit M set to 1, as well as TUP IAI with bit L set to 1 and R2 II-8 category is received.
Suggestions None and Summary: Attachments:
NGN Cases
Chapter 1
SoftX3000 Cases
1.3
Default value of ISUP Special Tone Timer is very small, caller cannot hear long announcement
Information Type: Troubleshooting Cases Update Time: Fault Type: 2012-08-31 10:06:14 Service
Permission Level: 01Huawei Engineers Permission Symptom: Customer added configuration of playing voice announcement using PFXPRO. Incoming call from SS7 TG to configured number finished after 20 s due to ISUP Special Tone Timer expiration. First idea was increase this timer value. But, according to Timer description the recommended max value is 30 s, it's not enough for customer. Need find some way to make possible to hear announcement for longer time.
Alarm Information: None Cause Analysis: Timer description: 1.1.1 ISUP Special Tone Timer Purpose of It determines the duration for which the SoftX3000 plays a special tone to Parameter the caller when the incoming ISUP trunk call fails. PID 168 Timer Group 0 Timer Sequence 31 Value Range 1030s (recommended) Default Value 20s The SoftX3000 starts the timer when the incoming ISUP trunk triggers a Start Time special tone. The SoftX3000 stops the timer when it receives an REL message from the End Time caller. Timeout The SoftX3000 releases the call, sends an REL message to the peer Processing office, and starts ISUP T1. The function for the ISUP trunk to trigger a special tone is enabled when Remarks an ISUP trunk call to SoftX3000 fails and Send exceptional tone is set to TRUE for the ISUP trunk group. Same time timers of other protocol (MGCP, SIP) support longer value and dind't meet such problem. According to ISUP call flow, announcement stage is similar to hear ringing signal, wait ANM message. This stage is controlled by ISUP T9 timer, by default 120s. So, Special tone timer make strong limit of announcement playing time. Maybe it's softw are limitation.
Handling Process: Make call to R&D. R&D confirmed that max timer value can be modified bigger. So we modified timer to 90 s using the command MOD ITIMER: PID=168, YWLX=0, SEQ=31, NVL=90; System works perfectly and allow to hear long announcement without ANM message.
Suggestions and Summary:
Value 90 s for ISUP special tone timer has been confirmed by RND, tested on real site and can be used freely.

If you need bigger value, it's better to confirm the value with RND. Ofcourse this value should not exceed the value of ISUP T9 timer (default value is 120 s). Attachments:
1.4
session internal was different cause sip calling fail
Troubleshooting Cases 2012-08-31 09:59:13 Data Configuration 03Equipment Users Permission When sip subscriber of softx3000 call international subscriber,after dialing number, the call was failure, Softx3000 received SIP 422 Session Interval Too Small message from opposite side. the sofrx version is SX3000 V300R010C05SPC100
Null 1,open the trace file , and open INVITE message, we can find the Minimum session is 90 seconds:
2, open the 422 message that softx3000 received,we can find that the Minimum session of opposite s ide is 600 seconds.
So, we can see that the problem happened because the Minimum session of both sides was differen t, Softx3000 side is 90 seconds, opposite side is 600 seconds.
Handling Process:
the Minimum session can be set in two place: 1 command SET SIPCFG, there is parameter Minimum session interval(s), the default value is 90 seconds, in but this command control whole office, if it was change, all SIP direction will be changed. 2 in command MOD SIPTG,there is parameter Session interval , it only control one SIPTG. So ,we used the second solution, and use command MOD SIPTG: TG=XX, EA=YES, SI=600; after that ,the problem was solved.
Suggestions the parameter of command SET SIPCFG control whole office , if the parameter is changed, the all SIPTG and direction will be changed, it's better cahnge SIPTG parameter, it only controled one SIPTG direction. Summary: Attachments:
NGN Cases
Chapter 1
SoftX3000 Cases
1.5
Parallel ringing service not working when call coming from non-softx subsciber
Information Type: Update Time: Fault Type: Permission Level: Symptom: Alarm Information: Cause Analysis:
Troubleshooting Cases 2012-08-24 12:10:11 Data Configuration 01Huawei Engineers Permission In SoftX3000 V300R010C03SPC120 ,Parallel ringing service not working in case call coming from some ISUP TG. None. Call is getting drop at SCP status enquiry for MNP query .after checking found Call source of some ISUP TG not defined. SCP selection source code ,it should be defined as 201 or 10 as in SCP CFG ,MN P service Key was defined with. SCP selection source code as 0 and 201. 1.Checked Traces found call droping at ssp-dbms-query-scp-status, 2.With call testing found problem is when call coming from some sepecfic N7TG . 3.Check N7TG and Callsource configuration and compared with normal TG 4.Found No SCP selection source code in call source ,it should be defined as 201 or 10 as in SCP CFG ,MNP service Key was defined with SCP selection source code as 0 and 201. None.
Handling Process:
1.6
What is the relationship between RV value and payload value of RFC2833
Troubleshooting Cases 2012-08-14 09:06:28 Service 03Equipment Users Permission Q: The third company engineers issist that in ADD_REQ messages from SoftX3000 to MSAN,as follows: (contextid=4294967294 handle=5917) !/1 [10.106.1.110]:2944 T=393799075{C=${A=A0{M{O{MO=SR,RV=OFF,RG=OFF}},E=387385867{al/*},SG{}},A=${M{O{MO=IN,RV=OFF,RG=OFF},L{v=0 c=IN IP4 $ m=audio $ RTP/AVP 8 97 a=ptime:20 a=rtpmap:97 telephone-event/8000 a=fmtp:97 0-15 },R{v=0 c=IN IP4 10.101.6.190 m=audio 3334 RTP/AVP 8 97 a=ptime:20 a=rtpmap:97 telephone-event/8000 a=fmtp:97 0-15 }}}}} string 'm=audio $ RTP/AVP 8 97' means that MSAN should reserve resources for both alternatives 8 and 97. So in SoftX3000,why we set RV=OFF? If we set RV=OFF, MSAN reserve resourses only for G711. As result RFC2833 (97 payload) don`t support.

Alarm Information: Cause Analysis: Handling Process:
None. None. A: The third company engineers made a mistake about the protocol, the right way of understanding this protocol should be like this: If a Local or Remote descriptor contains multiple groups of properties, and ReserveGroup is True, then the MG is requested to reserve resources so that it can decode or encode the media stream according to any of the alternatives. H.248 protocol defines the codec relationship as follows: G.711U = 0G.726 = 2G.723G.7231 = 4G.711A = 8G.729G.729A = 18 But In a=rtpmap:97 telephone-event/8000 ,97 is 2833 protocol, 2833 is not used for codec function for voice channel. 2833 only has complementary function for codecs(coding and decoding function). If Softx3000 send many codecs to MSAN to reserve resources, then the value of RG and RV would effect the number of reserved sources, that is right. But 2833 is not codec ;it is used to define the payload format for DTMF signal, other telephone signal and telephone events in RTP packets. So 2833 will not be affected by RG and RV value.
Suggestions None. and Summary: Attachments: H.248 protocol.rar
1.7
MSBR subscriber unable to recieve incoming calls problem due to wrong SIP port number
Troubleshooting Cases 2012-08-13 09:27:02 Data Configuration 01Huawei Engineers Permission The A-number (MSBR configured on the GPON access node) can make out going calls to another B number (Mobile or any other fixed), but cannot receive calls (i.e. B number cannot call A number). SoftX3000 V300R010C05SPC100
None.
The configuration at SoftX3000 side has SIPLP as 5062, and remote side configured the default SIP port 5060. When a call is made towards the A-number (MSBR), SoftX side send the port 5062 but the call does not get to the re mote side, because they receive a wrong SIP port number. configuration at Softswitch side is as below: %%LST SIPLP:;%% RETCODE = 0 Operation succeeded SIP local port configuration ---------------------------MSG module number SIP local port 211 5062 (Number of results = 1) O&M #4384909 %%LST SIPCFG:;%% RETCODE = 0 Operation succeeded SIP global configuration -----------------------T1 timer length = 5
NGN Cases
T2 timer length = 40 Use compact coding = False Use session timer = Session Timer Session timer length = 2 Minimum registration expiry duration (min) = 5 Maximum registration expiry duration (min) = 60 Minimum local port = 5062 Maximum local port = 5188 Minimum server port = 5060 Maximum server port = 5061 Minimum session interval(s) = 90 Session interval(s) = 300 Software control parameter = NULL Protocol Type = UDP DNS Default Port = 5060 Num of released calls per sec = 50 (Number of results = 1) --- END The trace at softswitch is as below:
Chapter 1
SoftX3000 Cases
The trace at remote side is as below:
Handling Process:
When I check the configuraion at SoftX side, i found out that we configure our SIP local port as 5062, but the remote side expect the default SIP port 5060 for them to process the call. I checked the software parameter P494 bit 7, and it was 1. I changed it to 0 and tested agiain. P 494-parameter 494 bit7 Bit7: Use it control whether UDP source port in SIP request message is the port of msg board that has sended the message =1: YES The port that MSG board configuration (Default) =0: NO , The famous port 5060 After modifying the software paramater, the MSBR able to recieve calls because both sides were having the same port (5060).
Suggestions Always refer to the Software Parameter description. and Summary: Attachments: MSBR fail trace.rar msbr success trace.rar
1.8
Softx3000 - No Route Available caused by IAM type
Troubleshooting Cases 2012-07-31 08:43:17 Others 02Huawei Partners Permission Version : Softx3000v300r010c05sph218. Topology: PLMN ---- UMG8900 ----- SX3000 ------ UMG8900 ---- PBX R2. When call came form PLMN the call fail to get R2 circuit with thereason "No route available" but the route has many free circuits also in low traffic period problem happen. When call came from different operator on PLMN there is no problem.
None.
From the TRACE NOT OK ( NOK ) we can see the following fail cause reason
NGN Cases
Chapter 1
SoftX3000 Cases
But we can see there is many available circuits from that outgoing TG +++ SX-SP-VMA50 2012-07-16 09:26:25-03:00 O&M #2221272 %%DSP OFTK:LT=TG,TG=2110,DT=AT;%% RETCODE = 0 Operation succeeded Sum of trunk -----------Number of trunk circuits
Status of trunk circuits
Percentage 88.33% 11.67% 0.00% 0.00% 0.00% 100.00%
Free 159 Busy 21 Block 0 Unknown or locked 0 Fault 0 Installation number 180 (Number of results = 6)
Comparing the 2 traces ( OK and NOK ) the incoming IAM have important difference 1- NOK IAM ( PLMN---IAM---> UMG8900)
2- OK IAM ( PLMN---IAM---->UMG8900)
Handling Process:
As you can see the field "ISDN-user-part-preference-indicator" on NOK call is configured to use isdn part ALL THE WAY , so all hops need to be isdn In the topology the peer device is R2 , so when SX3000 identify 2 TG it doesnt occopy it because of this p armeter. To solve the problem caller side (PLMN) should fix the message accord the network. But to speed up the solution SX3000 can configure one mask to change this specific field Solution: MOD IFLDVAL: MSG=IAM, FLD=FCIIP, OLDV=2, ACT=ALT, NEWV=0
Suggestions None. and Summary: Attachments: Cielo_origemVivo_Fail.tmf traceOK.tmf
1.9
No SDP information in 183 message sent cause no ringback to A side.
Troubleshooting Cases 2012-07-30 13:53:56 Service 01Huawei Engineers Permission A-------isup------->MGC(siemens)-----sip-------->SX_RJO-------sip------------->Sx_SPO_LP-----------sip------->B------------sip(with sdp information)------->Sx_SPO_LP--------sip(no spd information)-----> Sx_SPO_LP receive the SDP message but can't send it. the 183 message that Sx_SPO_LP sent is missing SDP information causing the no ringback tone to A side. V300R010C05SPH128.
None. Traces from Sx_SPO_LP, 183 message is missing SDP information.
NGN Cases
Chapter 1
SoftX3000 Cases
Ex. 183 message with SDP information(Right)
Handling Process:
P 491 , bit
bit 4
bit4 Bit 4 It determines whether the SoftX3000 transparently transmits the media information contained in the 18X message sent by a SIP callee to the caller side. Description = 0: The SoftX3000 transparently transmits the media information to the caller side. (default value) = 1: The SoftX3000 does not transparently transmit the media information to the caller side. We change this parameter to 0, this is the default value. Suggestions None. and Summary: Attachments:
1.10 Call duration control base on prefix CNACLD destination is not working due to incorrect softwareparameter.
Information Type:
Troubleshooting Cases
Update Time: 2012-07-27 10:43:20 Fault Type: Permission Data Configuration 01Huawei Engineers Permission

Level: Symptom: Customer wants to control the call duration base on prefix CNACLD destination. They had tested on ADD LCCTRL but failed. Need to check if any alternatives to control the call duration. SoftX3000 version - V300R10C05
Alarm Information:
None.
Cause Analysis:
1. Incorrect data configuration - LCCTRL. 2. Incorrect software parameter.
Handling Process:
1. Checked on configuration of ADD and LST LCCTRL and LST CNACLD. 2. Result as below: %%LST LCCTRL:;%% RETCODE = 0 Operation succeeded Long Call Limit Data -------------------iIndexID iCallSrcCode Call source name SubCategory iWarnType Limit use type Maximum call length Send prompt tone Prompt before release 1 201 HUTCH Call 60 False 2 10 MSHTB Call 60 False 3 65534 NULL Call 60 False (Number of results = 3) --END 65534 0 No prompt 65534 0 No prompt 65534 0 No prompt Release Release Release
3. LCCTRL configuration is correct. 4. Check on related software parameter setting for LCCTRL. 5. Check on software parameter P354 %%LST FSFP: ID=354, ListType=P1;%% RETCODE = 0 Operation succeeded SoftX3000 fix soft parameter ---------------------------Parameter ID = 354 Parameter name = parameter 354 Parameter value = 1111 1111 1111 1111 (Number of results = 1) --- END 6. Need to modify bit 6 to 0. Explaination of P354 parameter for bit 6 as below: bit bit6 Bit 6: It controls whether the SoftX3000 applies the configuration of ADD LCCTRL to an incoming trunk call. = 0: The SoftX3000 applies the configuration of ADD LCCTRL to the incoming trunk Description call. = 1: The SoftX3000 does not apply the configuration of ADD LCCTRL to the incoming trunk call. (default value) When processing trunk calls, the SoftX3000 determines whether to apply the Application treatment defined through ADD LCCTRL based on the setting of bit 6 of P354. When Scenario processing calls originated by local subscribers, the SoftX3000 directly applies the treatment defined through ADD LCCTRL regardless of the setting of this bit. 7. Problem resolved after modified bit 6 to 0. P354 = Parameter value = 1111 1111 1011 1111
NGN Cases
Suggestions Please refer to software parameter for system setting values. and Summary:
Chapter 1
SoftX3000 Cases
Attachments:
1.11 How to trace the R2 message in the softx3000

Troubleshooting Cases 2012-07-26 10:37:34 Others 02Huawei Partners Permission Q: How to trace the R2 message in the softx3000? Sometimes by the subscriber number , it is impossible to get all the message during the call ,why this happened ? In this situation how to get the R2 message trace in the Softx3000 None. When we do the message trace by subscriber number in the trunk , the system will match the num ber , but some time ,the R2 report the number to softx3000 one by one , in this situation , before s oftx3000 received the whole number , it can't get any message. A: Use the MID+UID+PSN to trace the R2 message
Suggestions and None. Summary:
Attachments:
1.12 Incoming voice call to certain BRA Terminal fail due to missing 'progress indicator' in SETUP
Information Type: Troubleshooting Cases Update Time: Fault Type: Permission Level: Symptom: 2012-07-25 09:11:04 Network Warranty Users Permission Incoming call to BRA subscriber failed. SOFTX3000V300R010C05 Call scenario: ISUP--->SOFTX--->BRA(DSS1),Call failed with cause value incompatible-destination (88) send by BRA terminal
Alarm None. Information: Cause Analysis: Some BRA terminal (CPE) is very strict on standard Q699 (ISUP-DSS1 mapping). For incoming call, it require the 'progress indicator' parameter in the SETUP message a ccording to Table 74/Q.699.. but it is found that our Softx3000 (V300R010C05) did not i nclude the parameter. so the call fails.
Handling Process:
SOFTX3000V300R010C05SPH121 have developed a patch to solve this issue. (SPH121 Release Notes Item 2.1.12). By modifying software parameter P361 Bit 15 to 0, Softx3000 to include progress indicator parameter in DSS1 SETUP message to BRA. MOD FSFP: ID=361, ModType=P1, Bit=15, BitVal=0.
Suggestions and Engineer must know and familiar about the protocol standard to be able to identify the root Summary: cause of the problem. CBJSS1_no progress indicator_2011-11-13-17-28-46.txt Attachments: CBJSS1_Progress indicator_2011-11-13-16-53-59.txt
1.13 CPG message with status=ALERTING will overwrite the actual ACM time in CDR with the time stamp of CPG(status=ALERTING)
Troubleshooting Cases 2012-07-23 17:26:21 Data Configuration 01Huawei Engineers Permission Version: V300R010C03SPH221 When SX received CPG message with status=ALERTING, it will overwrite the actual ACM time in CDR with the time stamp of CPG(status=ALERTING). Normally, operators will use the ACM time for charging in the CDR. For example: CDR below shows that CPG timestamp overwrites ACM time stamp which is CPG time is 13:22:30 while ACM timestamp
NGN Cases
Chapter 1
SoftX3000 Cases
13:22:16.
None.
This is due to default setting of the software parameter 888 bit 12 set to 1.
Below are the software parameter explanation on 888 bit 12.

Bit 12: It determines when the SoftX3000 records the start time of alerting on the CDR. = 1: The SoftX3000 records the start time of alerting on the CDR when it migrates to the alerting status. (default value) = 0: The SoftX3000 records the start time of alerting on the CDR when it receives the alerting message. Modify software parameter 888 bit 12 to 0. MOD FSFP: ID=888, ModType=P1, Bit=12, BitVal=0.
Suggestions None. and Summary: Attachments: CPG-Trace.png CPG_CDR.txt
1.14 what is the INAP version used between NGN SX and fixed IN SCP
Information Type: Update Time: Fault Type: Permission Level:
Troubleshooting Cases 2012-07-03 15:05:42 Network 03Equipment Users Permission

Symptom: Q: what is the INAP version used between NGN SX and fixed IN SCP? Many customer ask about that to inform SCP side which may need it to adjust SCP settings SoftX3000V300R010C05SPH113
Alarm Information:
None.
Cause Analysis: None. Handling Process: A: Generally SX support INAP CS-1 And follow the standard for INAP (ITU-T Q.1218) For the INAP type, the SoftX3000 can interwork with SCP with a certain INAP type, by default with C-INAP-Compatible SCP. To set SoftX3000 to interwork with SCPs of other INAP standards such as R-INAP, run SET INAPTP to set the INAP protocol type.
Suggestions and generally SX follow a certain version, type and standard for INAP conenction like other Summary: protocols. Attachments:
1.15 One way speech due to ptime value not matching in SDP message
Troubleshooting Cases 2012-06-29 09:12:20 Testing Warranty Users Permission SOFTX VERSION: V300R010C003 SBC: V200R007C01 GPON Device: SIP client can be attached using GPON Problem Description: Doing the testing with GPON device. GPON connected with SBC thrugh SIP protocol .When they call from GPON to Softx, they sending ptime value 10ms in SDP message.One way speech issue. Signaling Flow: GPON------->SBC-------->SOFTX Media Flow: GPON-------->router--------->SBC-------->LSW-------->MGW Media attribute= PCMU/8000 Media attribute: ptime=10ms None.
Alarm Information:
Cause Analysis: INVITE msg with SDP description sent by GPON: Via: SIP/2.0/UDP 10.41.1.82:5060;rport;branch=z9hG4bK15711 From: <sip:4960010@10.41.4.38;user=phone>;tag=2628 To: <sip:8800991113@10.41.4.38> Call-ID: 27225@10.41.1.82 CSeq: 21 INVITE Contact: <sip:4960010@10.41.1.82:5060> Proxy-Authorization: Digest username="4960010", realm="Huawei", nonce="13:14:45:7226", uri="sip:8800991113@10.41.4.38", response="4488f483fb6135859dc552fe77cb3c6d", algorith m=MD5 Max-Forwards: 70 User-Agent: Ericsson ONUG R2.5.0.17 Expires: 600
NGN Cases
Chapter 1
SoftX3000 Cases
Handling Process:
Supported: 100rel,replaces Allow: INVITE, ACK, UPDATE, INFO, CANCEL, BYE, OPTIONS, REFER, SUBSCRIBE, N OTIFY, PRACK Content-Type: application/sdp Content-Length: 150 v=0 o=- 2 1 IN IP4 10.41.1.82 s=conversation c=IN IP4 10.41.1.82 t=0 0 m=audio 51048 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=ptime:10 a=sendrecv 180 ringing with SDP description sent by softx : Trace: Sip Message is going to be sent to 10.41.1.82:5060 vpn 0, local 10.41.4.3 8:5060 vpn 0 *0.3109596816 interfacegiga SIP/8/debug:SIP/2.0 180 Ringing Via: SIP/2.0/UDP 10.41.1.82:5060;branch=z9hG4bK32479;rport=5060 Call-ID: 13356@10.41.1.82 From: <sip:4960010@10.41.4.38;user=phone>;tag=13002 To: <sip:8800991113@10.41.4.38>;tag=zyw3zzr4-CC-22 CSeq: 21 INVITE Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY, UPDATE ,MESSAGE,REFER Require: 100rel RSeq: 1 Contact: <sip:10.41.4.38:5060;user=phone> Content-Length: 153 Content-Type: application/sdp v=0 o=HuaweiSoftX3000 16353 16353 IN IP4 10.41.4.38 s=Sip Call c=IN IP4 10.41.4.38 t=0 0 m=audio 10706 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=ptime:20 When we compare those message detailed. We can find: SIP terminal send RTP packet with Ptime=20ms, but from trace message its showing 10 ms. From the trace msg we find the softx is sending ptime=20ms which is default value of pt ime. 1.We checked in LST BCPTM and found for the codec PCMU the ptime value is set to 20 ms. %%LST BCPTM:;%% 2. We had checked in RFC3264 and found the ptime and bandwidth attributes in the answer MUST equal the ones in the offer, if present. If not present, a non-zero ptime MAY be added to the answer. 3. Checked the software parameter p370 and change the value of bit 7 from 1 to 0 (ptime in message from caller side will be adopted). Software parameter p370: Bit 7: When called side negotiating CODEC, whether configured packtime of MGW is preferred or not:: =1: Yes (Configured packtime will be adopted) =0: No (Packtime in message from caller side will be adopted) 4.After doing this changes we make another call and found ptime value in SDP message has been changed to 10ms from softx end.It means softx adopting the ptime value of caller side. 5. one way issue has been resolved. The setting of bit 7 of P370 has no impact on normal narrow-band calls. It takes effect only on incoming SIP trunk calls.
Attachments:
1.16 wrong code was added with Caller Number in CDRs due to wrong Software parameter setting
Troubleshooting Cases 2012-06-29 08:54:19 Data Configuration 01Huawei Engineers Permission The version information of SoftX3000 is. V300R010C05SPC100. When dial from other network , there was double code added with caller number e.g 051 is are code when dial from mobile number 0302xxxxxx to NGN number 05192xxxx than in CDR the caller number was displayed 0510302xxxxxx which was wrong that 051 should be not added infornt of caller (mobile) number.
Alarm Information:
None.
Cause Analysis:
when dial from mobile 0302xxxx to 05192xxxx Check the CLI on Called party display , it was shows normal CLI that on CLI it was shows 0302xxxxx but in the CDR additional LA C was added . Check the below procedure. 1- Check the PFXPRO against the prefix 051 than there was no prefix.
Handling Process:
than check the software parameter 184 it ws default 05FF after change it to 055F than check it as Parameter ID = 184 Parameter name = Bill parameter 1 Parameter value = 055F ( 10101011111) Default Value = 05FF (10111111111 ) after changing the 184 parameter to 055F the caller number in the CLI was disply properly . the software parameter information is
bit
bit7---bit5 Bits 5 Control the type to normalize caller numbers. The default C7: Used with P184BIT0 Description value is 7.
NGN Cases
Chapter 1
SoftX3000 Cases
=0: Normalizes numbers according to GSVN. =1: Normalizes numbers to international numbers. =2: Normalizes numbers to national numbers. =4: Normalizes numbers to subscriber numbers. =3,5,6,7: Not Normalize numbers.
Certain carriers require that the SoftX3000 normalizes the calling numbers on the CDRs to the same format. Therefore, bits 7 of C5 Application P184 are used. For example, bits 7 of P184 can be used to enable C5 Scenario the tandem office to normalize the calling numbers to the national number format or the international number format. The normalization does not affect number analysis or CLIP service. Related Software Bits 7 of P184 are valid only when bit 0 of P184 is set to 1. C5 Parameter Impact on The settings of bits 7 of P184 affect the calling numbers on the C5 System CDRs. Therefore, excise caution when setting these bits. 1. Bits 7 of P184 are used after bits 10 C5 C15 of P179 are used. That is, the SoftX3000 normalizes the calling numbers first based on the rules defined by bits 10 C15 of P179 and then based on the rules defined by bits 7 of P184. C5 2. Bit 4 of P413 determines whether the SoftX3000 normalizes the calling numbers or the called numbers from the international number format to the national number format based on the settings of bits 7 of P184 or bits 9 of P412. The SoftX3000 normalizes the C5 C7 calling numbers or the called number only when the country codes in the calling numbers or the called number are the same as the country codes in the local DN sets of the calling parties or called parties. This prevents necessary information of the calling number or called numbers from missing. 3. Bits 11 C10 of P346 determine whether the SoftX3000 adds the toll prefix to or deletes the toll prefix from the calling numbers that are normalized based on the settings of bits 7 of P184. C5
Remark
bit
bit15---bit8 Bits 8-15: Define the bill pool space protected or deprotected subsequently. It ranges from 0 to 255 expressed in 0.1 megabit. The default value is 5.
Description P184 bit0: Controls whether to unify the caller and the callee number before bill storage. =0: No.
=1: Yes.
Application Scenario Related Software Parameter Impact on System Remark
Omitted. None. Omitted. None.
Suggestions So if the Double LAC is added with Caller number in the CDR than check the FSFP parameter and Summary: P184. and do modify it as mentioned above handling procedure than it will be OK.
Attachments:
1.17 SIP Terminals unable to register with SoftX3000 if deregister due to power outage or network disconnection
Troubleshooting Cases 2012-06-26 15:07:37 Service 01Huawei Engineers Permission If SIP terminal registered with SoftX3000, disconnects from SoftX3000 due to power outage (at SIP terminal) or network disconnection, then at the time of restoration of conection, it takes a long time to get the SIP Terminal to register with SoftX3000 which may be in hours. Sometimes URG EDPT needs to be used for de registering, then it gets registered. SoftX3000 version: SoftX3000 V300R601C05SPH171 None. Analysis carried out in follwoing steps: 1. Traces were captured on SoftX3000. 2. Packets captured at network layer, to check if netowrk layer is causing some changes. During the investigation of the problem it was found on comparison of initial Register requ est with that of Register request sent after the restoration of connection. The problem fou nd was to be different port numbres sent by terminal everytime. To resolve this issue, we have modified Software parameter P54 (Bit 5), By default its value is 0, we modified it to one to resolve this issue. This Bit actually determines whether to check IP address and port number in above mentioned situation. If its value is zero, it will check IP address and port number if SIP terminal registered again and again and if anything is different then it will not register. Opposite is the case for its value=1, so we kept its value as "1", so that if port number changed while sending re-register request, it should not check it.
Handling Process:
NGN Cases
Chapter 1
SoftX3000 Cases
Modifying Software Parameter always has the global affect, so always be careful in implementing such solutions.
1.18 How to send voice and video call through separate Trunk Group
Information Type: Troubleshooting Cases Update Time: Fault Type: Permission Level: Symptom: 2012-06-11 09:48:59 Data Configuration 01Huawei Engineers Permission Q: We need to send Voice and Video call to separate trunk group. For example, there is voice through incoming trunk, we need analyze the caller service is voice call and send it to a specific outgoing trunk group, if it is video call, we need to send it to an other outgoing trunk group. For example, we have SIPTG for video call through IPBB call and N7TG for voice call through PSTN, and depend to the caller call type we can select the right TG.
Alarm Information:
None.
Cause Analysis: None.
Handling Process:
A: Suppose we have two call sources 0 and 1 with two Route Selction Source 0 and 1 respectivly. We configure two RTs 10 and 20 to route 10 the voice call and route 20 to route the video service In RTANA, according to the Route Selection Source Code (RSSC) gotten from Call Source Table, the Route Selection Code (RSC) gotten from CNACLD table and the condition "Transmission Capability" set, the route RT will be selected. Voice service, the parameter is TP=Voice : ADD RTANA: RSC=10, RSSC=0, RUT=ALL, SAI=ALL, CLR=ALL, TP=VOICE, TMX=0, R=10, ISUP=NOCHG, NCAI=ALL, CST=ALL; Video service, the parameter is TP=Video : ADD RTANA: RSC=20, RSSC=1, RUT=ALL, SAI=ALL, CLR=ALL, TP=VIDEO, TMX=0, R=20, ISUP=NOCHG, NCAI=ALL, CST=ALL. Suggestions and None. Summary:
Attachments:
1.19 How to configure SOSM interception when used UMGmini (ssm -4) for TG and IGW
Troubleshooting Cases 2012-04-18 09:30:53 Data Configuration 02Huawei Partners Permission Q: How to configure SOSM interception when used UMGmini (ssm-4) for TG and IGW functions. SOFTX3000 version is V300R010C05SPH126 UMG8900 version is UMG8900V200R008C02SPC163
None.
During configuration of SOSM intercetion i have found that configuration of SOSM interceprion when used m ini UMG (ssm-4) as TG and IGW not same with configuration when used midle UMG (ssm-32). There are not need divide UNG8900(mini) to different virtual media gateways for TG and IGW functions.
Handling Process:
A: Typical network of SOSM interception.
NGN Cases
Chapter 1
SoftX3000 Cases
When we use miniUMG (ssm-4) as TG and IGW we don't need create another VMGW for IGW on UMG. There are we have to use one VMGW. In configuration on Softx3000 side we use ADD LIGW command for specify IGW. In our case we have to use same MGW for IGW and TG function. All other configuration you can make according guide.
Suggestions None. and Summary: Attachments:
1.20 Charging source code incorrect causes no CDRs generated for the calls received in SX from a certain TG
Troubleshooting Cases 2012-03-31 09:29:38 Data Configuration 02Huawei Partners Permission There is no CDRs generated for the calls come from a certain TG, the call come from a certain SIPTG is OK but there is no CDR on IGWB for these calls. SoftX3000V300R601C05BSPH163.
Alarm Information:
None.
Cause Analysis: we checked the configuration done (attached) and found that we use UN-CENTRALIZED charging and SIPTG with no CHARGING SOURCE CODE, Charging source code = 655 35, so no charging case will be used for such calls, so ther is no CDRs generated.
Handling Process:
If need only one CDR for the peer side subscriber----- "Charging source code" should be changed from 65535 to any required value from "caller charging source code" defined in CHGIDX for the required CHGANA like that MOD SIPTG: TG=13, RCHS=xx; ADD CHGIDX: CHSC=yy, RCHS=xx, CHA=x; ADD CHGANA: CHA=x, CHO=NOCENACC, CHGT=DETAIL; If need two CDRs one for peer side subscriber and the other for trunk, should change as above besides change charging office to be centralized if need.
we should check the configuration carefully in such cases. MML_2011-12-19-09-20-14.txt
NGN Cases
Chapter 2
iGWB Cases
Chapter 2
iGWB Cases
2.1
How to configure save one copy of CDR in igwb for sepcial CDR
Troubleshooting Cases 2012-05-22 18:05:24 Others 01Huawei Engineers Permission Q: IGWB version is V300R001C15B006SP16 ,the format is 953-554. IGWB all the CDR will save in two folder.One is backsave\X3KF ,Another is backsave\Second\X3KF. Customer want the failer CDR save only in one folder for saving disk space .but detail CDR still need two folder .how to configure it in igwb ? None.
Alarm Information:
Cause Analysis: None.
Handling Process:
A: 1.We can configure in the igwb.ini file to meet customer requirement. 2.Current igwb in file ,the key information is [AccessPoint1] SaveSecond = 1 ;Flag of offering the second copy of final bill files, 0-no 1-yes From the configuration ,we can see all the CDR save two folder in the AccessPoint1 .but we can configure the channel of failer CDR dont save the second folder . We can add the parameter in the igwb.ini file [channel1-8] SaveSecond = 0 the parameter [channel1-8] means channel 8 .the channel 8 is for failer CDR .the parameter SaveSecond=0 ,means dont save the second folder . 3.The priority of channel1 is higher than the AccessPoint1 .The Accesspoint1 parameter works for all the channel1 .but parameter channel1 works for special channel . The channel1 meaning can check it the c:\igwb\config\format\8.chl. but in the readme file of format .the explain for channel is wrong .need pay attention to it . billing fail igwb.rar
2.2
Call Termination reason in CDR
Information Type:
Update Time: 2012-03-31 09:25:38 Fault Type: Permission Level: Others 01Huawei Engineers Permission

Symptom: In CDRs there is field called Call Termination reason Field terminating_reason 1: called party release; length(bytes) 0.5 Offset 75.5 Remark 0: caller party release;
2: inter release 3: peer caller release 4: peer called release the possible values for this field are 0, 1, 2, 3 and 4, but what are the difference between these values and what they represent? Alarm Information: Cause Analysis: None. The meaning of each of termination cause values are as follows: 0 caller party releaseThe caller number is NGN user and release the call. 1 called party release:The called number is NGN user and release the call. 2 inter release: SOFTX3000 release the call (not user) 3 peer caller release:The caller number is not NGN user and release the call. 4 peer called release:The called number is not NGN user and release the call. to fully inderstand these values lets consider below networks: 1- Calling user OR called user us SX subscriber calling user ---------- SX OR SX -------------- Called User For the first case, If calling user released the call, the value will be 0 For the second case,If the called user released the call, the value will be 1 2- If SX work as toll office to caller office OR called office Calling User ----- Calling Office -------- SX OR SX ------- Called office ------- Called user For the first case, If calling office released the call, the value will be 3 For the second case,If the called office released the call, the value will be 4 In point 1 and 2 if SX released the call for some internal reason the value will be 3
Handling None. Process: Suggestions None. and Summary: Attachments:
2.3
Remote site iGWB login failed due to the Wrong client port configuration
Information Type: Update Time: Fault Type: Permission Level: Symptom: Alarm Information:
Troubleshooting Cases 2011-12-24 14:17:32 Others 02Huawei Partners Permission When we tried to login Remote site iGWB, it was failed reporting error messgae "Connect Server failed". None.
Cause Analysis: When we have tried to login iGWB for remote site following error message appears on cl ient
NGN Cases
Chapter 2
iGWB Cases
Handling Process:
Even though iGWB server was running normally, but still we was unable to login iGWB c lient. It is because Client Management communication port in wrongly configured at server and client end. In iGWB.ini file following port was configured for server communication with client. [MML] LocalIpToMMLClient=192.168.200.12 LocalPortToCM = 6216 when we installed iGWB client, it by default use port 6000 for communication with iGWB server. [PORT] MAINTAINPORT=6000 wrong configuration of port among server and client causes failure of iGWB client login. Any one of the procedure can be adopted from mentioned below two methods to resolve this problem 1- Check the "LocalPortToCM" value from iGWB.ini file and then set this value in client config file under this path ( iGWB client installation directory \iGWB_Client\Data\uiconfig.ini ) in remote PC installed with iGWB client software. 2- Set the "LocalPortToCM" value to 6000 in "iGWB.ini" in iGWB server installation directory. Note: if you adopted 2nd method you need to restart iGWB Server process to take effect of this change. None.
Chapter 3
MRS6100 Cases
3.1
Eliminate annoucement tone files consist of both Chinese and English tone to English RVA
Troubleshooting Cases 2011-12-31 21:01:04 Voice Loading 02Huawei Partners Permission When Huawei own subscribers call to number not exist (hwf001000c.chi) and the line is busy (hwf0010006.chi), the annoucement played with RVA Chinese followed by English. We need to change all the format to the only English RVA. Null
Change default RVA with Chinese+English version to only English RVA. This is to fulfill c ustomer requirement to play only English annoucement. 1. Get the tone files from D:\Data\voice directory of BAM hard disk. 2. Modify the original wave files using software tool Cooledit2000. 3. Check the modified tone files, Chinese announcement part is eliminated correctly. 4. Confirm with customer this fulfilled the requirements. The two files are for UNALLOCATED NUMBER and NO CIRCUIT AVAILABLE. 5. Proceed with replacement procedures of English rva. Replace the modified tone file using the same file name as original files into the BAM hard disk. 6. Before hand, backup the original tone to keep a copy of original tone. 7. Perform test call to check if the tone files replaced successfully. However, the announcement played still consists of Chinese+English, that means the old files are not replaced successfully. 8. Replaced the new tone files under MRS 6100 BAM, D:\Data\Voice directory. 9. Execute RMV MSUV: FN = XXX; (to delete the old voice file) 10. Execute ADD MSUV: FN = XXX; (to load the new tone file to board) 11. New RVA loaded was success. Test call for both scenario cases, got English RVA as expected. RMV MRCV: FN="HWF001000C.chi"; ADD MRCV: FN="HWF001000C.chi", UMF=1, FD="English number not exist"; RMV MRCV: FN="HWF0010006.chi"; ADD MRCV: FN="HWF0010006.chi", UMF=1, FD="English the line is busy"; UPD MRPAWF: MN=212, MRPAID=LMRPAB; LST MRCV: FN="HWF001000C.chi"; LST MRCV: FN="HWF0010006.chi"; Suggestions The remove command is to make sure the old file deleted from the board then add again to load and Summary: back. If the file is not replaced then we need to execute UPD MRPWF. rva chinese before loading_LOCAL_Interface_Signaling_Trace_2011-11-07-08-29-25.tmf Attachments: rva still chinese after loading_LOCAL_Interface_Signaling_Trace_2011-11-07-09-05-54.tmf change rva success_BAM_Interface_Signaling_Trace_2011-11-08-17-41-34.tmf
NGN Cases
Chapter 4
UMG8900 Cases
Chapter 4
UMG8900 Cases
4.1
Newly installed FVPD board in mini UMG expansion didn't start and influence to service of installed board
Troubleshooting Cases 2012-09-03 14:35:04 Network 03Equipment Users Permission Initially miniUMG was equipped with one FVPD board in slot 3, slot4 was empty. Some time later customer decided to expand the system with additional FVPD board. All proper configuration was added, board installed, but new board didn't start work and caused influence to service like during ethernet storm. Board was immediatelly isolated. Need find reason of this problem.
Alarm Information:
A lot of alarms 3266 were displayed for both boards: Frame=1 Slot=3 Board Position=front, Board Type=VPU, Board The gateway resolving Major 3266 UMG_mini No.=3, IP Address=10.100.20.20, Interface Type=ETH, Interface failed number=0 Frame=1 Slot=4 Board Position=front, Board Type=VPU, Board The gateway resolving Major 3266 UMG_mini No.=4, IP Address=10.100.20.21, Interface Type=ETH, Interface failed number=0
Cause Analysis:
System displays alarm "The gateway resolving failed" -- board 3 and 4 lost connection to gateway. We should check configuration and network structure.
Handling Process:
Configuration was checked and no any problems were found. Then check network, capture packets during problem situation. Analysis of such data showed amazing case: Conflict of MAC address, DSP IPIF show, that Hardware address is 00e0.fca5.82e9 for slot 3 and 4 boards interfaces (see attached "DSP IPIF (problem case).txt") The procedure of changing MAC address is following: 1) Run command DBG CMD: FN=1, SN=4, BP=FRONT, CM="vrp setmac eth 0 00E0FCD94030"; (just select some unique value of MAC address, please see below) 2) Reboot slot 4 board 3) Ensure, that isolation is cancelled. After this procedure MAC address of Board 4 was changed and system become works perfetly. How to select new MAC address: From existing MAC you should keep first three bytes and randomly set other three bytes. First three bytes correspond to vendor identify (Huawei). For example: Existing MAC is 00e0.fca5.82e9, new MAC should be 00e0.fcXX.YYZZ, where XX, YY, ZZ -some hexademal bytes, such as: 17, A1,B5 Finaly MAC address will be: 00E0FC17A1B5
Suggestions When add new board need check MAC address first. and It can be done by command DSP IPIF. Summary: comment for approver: During debugging this case I seek support site, wanted to find procedure of expanding FVPD board and problem of staring FVPD board -- and didn't find similar cases. In fact, we found, that during _expansion_ of existing frame, we installed _new_ board and this new board MAC was set to the same value with existing board. I don't know, it's random case or software bug, or maybe FVPD has limited ammount of MAC address, but definitely address of new board was not ff ff ff ff ff ff -- thus my case is different from SE0000541244, it has different initial conditions, different alarm messages, if somebody will meet the problem described in current case he will not be able to case SE0000541244, because of different key words and different symptom. So please check again, maybe reasonable to publish this case. Attachments: DSP IPIF (problem case).txt
4.2
What is the difference between G711_VAD_NORMAL and G711_VAD_OPTION
Information Type: Troubleshooting Cases Update Time: Fault Type: 2012-07-04 16:54:11 Service
Permission Level: 03Equipment Users Permission Symptom: Q: What is the difference between G711_VAD_NORMAL and G711_VAD_OPTION?
Alarm Information: None. Cause Analysis: None.
Handling Process: A: When using VAD for G711, UMG sends CN packets instead of transcoding the silence with noise. Those packets use payload 13 and the frame formats are: Normal Format and Optional Format. Normal Format: The background noise energy (1 byte) and the reflection factor (10 bytes) are sent. The payload length is 11 bytes (G711_VAD_NORMAL). Optional Format: Only the background noise energy (1 byte) is sent (G711_VAD_OPTION). Suggestions and Summary: Attachments: Only use G711_VAD codecs when local and peer device are Huawei UMG8900.
4.3
How to set Wrong Ptime for G723 codec to release the call immediately before IAM or select different codec and ptime.
Information Type: Update Time: Fault Type: Permission Level:
Troubleshooting Cases 2012-06-29 08:57:21 Data Configuration Warranty Users Permission
NGN Cases
Symptom:
Chapter 4
UMG8900 Cases
When SIP partners send an incorrect ptime value, for example, G723 ptime=20 instead of 30, SoftX will sent IAM to TDM but release immediately. Below is the SoftX trace that ignore the P-time, send IAM to TDM and release immediately. Actual standarf Ptime for G723 is 30.
None.
This problem happens when select G723 codec only at the particular TG. Requirements from Customer S would like to release the call immediately once detected the ptime not following the actual standard before SoftX send IAM.
Handling Process:
To solve this issue, modify UMG8900 software parameter as below:MOD SFP: ID=P10, MODTYPE=BIT, BIT=3, BITVAL=0; This parameter is to set CMU consider whether the Ptime value supported by MGC. Bit value = 1 (by default): The CMU does not consider the P-time value when selecting the codec. Bit value = 0 The CMU consider whether the P-time value supported by MGC, If supported, then select the codec; If not supported, then select another codec and P-time value. After modifying the UMG8900 software parameter, if the TG still only select G723 codec only, it will check the G723 Ptime first. If it does not meet the standard which is the Ptime 30, it will release the call immediate before sending IAM and give an error message remote codec unsupported. Below message trace as attached.
Suggestions None. and Summary: Attachments: TB-SX1_Interface_Signaling_Trace_2012-06-14-10-53-47_UMG p10bit3=1.tmf TB-SX1_Interface_Signaling_Trace_2012-06-14-11-03-16_UMG p10bit3=0.tmf
4.4
Different Ptime in RTP packets and Signaling causes one-way audio
Information Type: Troubleshooting Cases Update Time: Fault Type: 2012-01-29 15:57:52 Voice Quality
Permission Level: 01Huawei Engineers Permission Symptom: SCENARIO A --> LE --> (N7TG) --> UMG8900 --> SoftX3000 --> (SIPTG) --> SBC --> SIP server --> B PROBLEM DESCRIPTION * Call is established successfully * A cannot hear B's voice.
Alarm Information: None. Cause Analysis: One-way audio can be caused by the following: * TDM path Crossed pairs of TDM cables Inconsistent configurations of the TDM interfaces on the UMG8900 and the peer TDM device * IP path Problem in IP network (connectivity between media IP and peer side) * UMG
NGN Cases
Chapter 4
UMG8900 Cases
Fault in the TDM switching network board or TDM resource board of the UMG8900 * SIP terminal Fault in the SIP interworking device * Others Different packetization time (Ptime) in terminals. Handling Process: INFORMATION COLLECTION * Interface Signaling Trace * IP packet capture (signaling and media) * TDM recording in UMG * UMG Toolkits Info Collector LOCATING THE FAULT * From Interface Signaling Trace it can be found that codec G729 with ptime of 20 [ms] is negotiated between SoftX and Peer side. Also it can be seen that SoftX instructs UMG to use ptime of 20 [ms] * From TDM recording in UMG it can be found that UMG doesn't send audio to TDM path * From IP packet capture it can be found that the ptime in the RTP stream from peer side to UMG uses a ptime of 30 [ms]. Since UMG uses a ptime of 20 [ms], it cannot decode the RTP received SOLUTION Peerside has a problem since it uses a diferent Ptime in RTP than the negotiated in Signaling. Ask peer side to fix it. Suggestions and Summary: HOW TO CHECK PTIME IN SIGNALING (for SIP scenario) * In initial SDP offer (often n INVITE), unless "ptime=" attribute specfies it, the default ptime of 20 [ms] is used * In SDP answer (often in 183 or 200), peer side specifies the ptime in "ptime=" attribute HOW TO CHECK PTIME IN RTP * Check two conseutive RTP packets from the same source to the same destination * Calculate the difference between "Timestamp" atribute * Please refer to the following formula: Ptime = "RTP timestamp difference" x "Sampling frecuency" For an audio codec of 8 [kHz] "sampling frecuency" (like G729A, G729B, G729AB, G711A, G711u), if "RTP timestamp difference" is 160, then "Ptime" is 20 [ms] For an audio codec of 8 [kHz] "sampling frecuency", if "RTP timestamp difference" is 240, then "Ptime" is 30 [ms]. llamadaOneWayAudioIDT.pcap
Attachments:
NGN Cases
Chapter 5
SG7000 Cases
Chapter 5
SG7000 Cases
5.1
How to check the SCCP loop
Information Type:
Update Time: 2012-08-01 08:34:43 Fault Type: Permission Level: Symptom: Alarm 02Huawei Partners Permission Q: How to check the SCCP loop event.
Alarm Information:
Cause Analysis:
ALARM 5844405 Event Critical alarm System 355 Operation system Alarm occurrence time = 2012-06-12 17:15:07 Alarm name = SCCP loop is detected Alarm module = SCCP Alarm sub-module = <NULL> Location information = Reason=0x64 Message=83 9a 51 67 44 11 80 01 04 0f 1a 00 0b 12 08 00 12 04 55 72 69 21 36 19 0b 12 08 00 12 04 55 10 21 07 01 60 92 62 81 00 Other information = Alarm record is as follows: SCCP loop is detected. Reason: 1XX. Message: 2XX 3XX ... 40XX 41XX (totally 40 bytes). In alarm record, the parameter of 40 bytes is the message indicating the error. Reasons for alarm : Skip counter reaches 0 when processing XUDT or XUDTS . Recovery advice = (1)If the 7th bit in the higher order of the first byte of 'content of called address' , it means the route of this message is arranged according to signaling point and subsystem. Therefore, subsystem can be found in called address directly. Then inform exchange point specified by OPC in message to find whether translated DPC is the GT code of the local exchange point. Then at the local exchange point check if DPC translated through this local exchange point is the signaling point code of the local exchange point. If yes, re-plan translation data of GT code and reset it together with relevant responsible personnel at the local exchange. (2) If the 7th bit in the higher order of the first byte of 'content of called address' is 0, it means the route of this message is selected according to GT.Therefore, you must find GT code in address first, then test this GT code by using corresponding command. A: 1) We can check at the alarm some important informations at the Location information field.
1.1) "01" refers to the "hop counter" parameter value. 1.2) "08" refers to the SSN of the called GT. 1.3) "55 72 69 21 36 19" refers to the GT of the called side. We should read this value inv erting the bits and as result we have the "55 27 96 12 63 91" GT address. 1.4) "08" refers to the SSN of the calling GT. 1.5) "55 10 21 07 01 60" refers to the GT of the calling side. We should read this value in verting the bits and as result we have the "55 01 12 70 10 06" GT address. A.2) With these information we can characterize the origins and destinies of the message th at originated this alarm. 2.1) Check who is the called side of this message, using the command LST SCCPGT. (Re mind that we already have the GT address). 2.2) Check who is the calling side of this message, using the command LST SCCPGT. (Re mind that we already have the GT address). 2.3) We can use the Location information field "83 9a 51 67 44 11 80 01 04 0f 1a 00 0b 12 08 00 12 04 55 72 69 21 36 19 0b 12 08 00 12 04 55 10 21 07 01 60 92 62 81 00" on the DBConvert tool to check the Point Code of calling and called side. Handling The alarm appears when SG7000 receive the SCCP message with the value on "hop counter = 1" Process: (we can check at the alarm the "hop counter" value) . According to the standard Q713e, for the XUDT and XUDTS message, each time after translate, the "hop counter" will decrease 1. (The equipment that originates the message should send the "hop counter" field with the value 15). So after SG7000 do the GT translate , the value of "hop counter" will be "0" and the message will be discard. When this value happen means that this message already was translate for more then 14 times. According to the standard Q713e, it means that we have a loop on network. Suggestions None. and Summary:
Attachments:
5.2
STP deletes F character from end of called number in the IAM message after number changing operation
Troubleshooting Cases 2012-06-25 17:47:12 Others 02Huawei Partners Permission For the SG7000V200R005C05SPC001 version, STP receives IAM message which B number has "F" but after
NGN Cases
Chapter 5
SG7000 Cases
number change function STP sends IAM message without "F". STP deletes "F" indicator from end of B number.
Alarm Information:
There is no alarm for this case.
Cause Analysis:
For the SG7000V200R005C05SPC001 version, STP receives IAM message which B number has "F" but after number change function STP sends IAM message without "F". STP deletes "F" indicator from end of B number. "F" indicator means that B number length finished. If there is no "F" indicator on e nd of B number,LE is waiting for the rest of B numbers. Thats why, LEs are waiting SAM msg after IAM. This makes most of the calls establishing times ar e so long around 10 seconds and some of the calls are failure. STP incoming IAM: B number is "C0450XXXXXXXXXXF" before number change STP outgoing IAM: B number is "10450XXXXXXXXXX" after number change, there is no "F". IAM incoming to STP;
Handling Process:
This problem was recovered by upgrading SG7000V200R005C05SPC001 version to SG7000V200R005C05SPC003.
Suggestions Please use SG7000V200R005C05SPC003 version or laters. and Summary: Attachments:
5.3
SG7000 can't forward message to HLR after FNR process
Troubleshooting Cases 2012-01-29 15:42:52 Data Configuration 02Huawei Partners Permission SG7000 can't forward Location update (LU) message through M3UA link after FNR process done. Location update failed. None. 1. M3UA link is up between SG7000 and HLR. 2. GT routing configured correctly, it route to HLR point code and MTP route also alr eady configure correctly. 3. Using MNP trace, we can trace FNR process to change Called GT from IMSI bec ome HLR GT, but we can't find the message in M3UA link set between Sg7000 and HLR.
NGN Cases
4. We open the message from trace tools we find out that Nature of address indicat or is National after MNP process. Thats why the GT translation is failed. because in GT configuration we configure N ature of Address Indicator is International. Handling Process: 1. We check MNPSOFTCFG using LST MNPSOFTCFG, we found that country code = 0, this is why the Nature of address indicator change become National. 2. We need to configure the correct country code using SET MNPSOFTCFG: NC="62"; (Indonesia). After that, the Nature of address indicator is become international. 3. After configuration finish the message successfull sent LU message to correct HLR. from this case we know that in FNR process, some parameter will change base on FNR configuration. So we need to carefully configure base on real condition data. one missed parameter can make Message can't deliver to the correct destination.
Attachments:

NGN Product Training Technical Cases

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

NGN Product Training Technical Cases

Încărcat de

Drepturi de autor:

Formate disponibile

NGN Product Training Technical Cases