Hello, guys!
Good day to you!
The topic describes how to deal with the problem that cannot make the outside call.
Issue description
The customer reported an issue when placing an outbound call from a POTS user under an IAD1224. The customer is using software version V200R003C30SPC500B011 (Built on 2017/07/25 11:08:18).
The call flow is as follows:
Calling: +3751XXXX1990 ( Local number 991990 )
Called: 130 = +3751XXXX3011
Both calls go through trunk 0, the same office route.
In our case the number 130 emergency calls while the 3751XXXX3011 number is for international calls
IP address assignation and topology:
10.4.1.12 - U1981
10.4.1.11 - SBC ( office route 0 ) goes to outside IMS
10.4.1.21 - IAD 1224 Huawei ( 991990 connected here )
Handling Process
In order to further troubleshoot the reported issue, we wanted to make sure that the exact call flow and network topology were understood. As such we requested the following information from the customer:
The firmware version of the U1981 unified gateway.
Exact reported calling number, called number in both cases since it is not clear from the above information and type of user that is being called.
Are both calls going to the same trunk that you interconnect with the PSTN/SIP provider/ Are using the same office route?
Service configuration of the SIP user under the unified gateway that is calling (configuration of the SIP user in order to check the call rights and so on).
Network topology.
Call flow.
Are there any Huawei IP phones involved in this process? If this is the case we would need the debug logs from the Huawei IP phone. This can be done by following the below process:
Also since there were two calls reported; one that is working and one that is not we wanted to make sure to capture the signaling trace for the good call as well as for the bad call that did not work in order to compare them.
From the provided debug log we could notice that there is only one call session that was failed when the number dialed was +3751XXXX3011. The call was rejected by the peer side.
IsCallMsg:[Y], Direction:[10.4.1.11--->10.4.1.12] SIP/2.0 480 Temporarily Unavailable Via: SIP/2.0/UDP 10.4.1.12:5060;branch=z9hG4bKs2xcsd4c0r4b3n1zsyssrxdbx Call-ID: 4465rnxxbcr03s2z2n0zxbnd06x00rz6@10.4.1.12 From: "991990"<sip:991990@10.4.1.12;user=phone>;tag=2cx0y2sd To: +3751XXXX3011 <sip:+3751XXXX3011@10.4.1.11;user=phone>;tag=m9b67akm-CC-1018-OFC-86 CSeq: 1 INVITE Reason: Q.850;cause=21;text="Call rejected" Content-Length: 0 Also, we could notice from the log that there is a different caller number display between a normal scenario and the issue scenario. The issue scenario: a caller number is a short number.
IsCallMsg:[Y], Direction:[10.4.1.12--->10.4.1.11] INVITE sip:+3751XXXX3011@10.4.1.11:5060;user=phone SIP/2.0 Via: SIP/2.0/UDP 10.4.1.12:5060;branch=z9hG4bKs2xcsd4c0r4b3n1zsyssrxdbx Call-ID: 4465rnxxbcr03s2z2n0zxbnd06x00rz6@10.4.1.12 From: "991990"<sip:991990@10.4.1.12;user=phone>;tag=2cx0y2sd To: +3751XXXX3011 <sip:+3751XXXX3011@10.4.1.11;user=phone> CSeq: 1 INVITE Contact: <sip:991990@10.4.1.12:5060;user=phone> Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,UPDATE,PUBLISH Supported: timer Max-Forwards: 70 Content-Length: 258 Content-Type: application/sdp
IsCallMsg:[Y], Direction:[10.4.1.12--->10.4.1.11] INVITE sip:+3751XXXX3011@10.4.1.11:5060;user=phone SIP/2.0 Via: SIP/2.0/UDP 10.4.1.12:5060;branch=z9hG4bKcz5nbx55nz1zr42xxcn311rrx Call-ID: 2s04442c4cszr06yry5sd2c14r32yr2b@10.4.1.12 From: "991990"<sip:+3751XXXX1990@10.4.1.12;user=phone>;tag=552rb2x1 To: +3751XXXX3011 <sip:+3751XXXX3011@10.4.1.11;user=phone> CSeq: 1 INVITE Contact: <sip:+3751XXXX1990@10.4.1.12:5060;user=phone> Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,UPDATE,PUBLISH Supported: timer Max-Forwards: 70 Content-Length: 258 Content-Type: application/sdp
v=0 o=HuaweieSpaceV200R003C30SPC500 4205 4205 IN IP4 10.4.1.12 s=Sip Call c=IN IP4 10.4.1.21 t=0 0 m=audio 50118 RTP/AVP 8 0 18 a=rtpmap:8 PCMA/8000 a=ptime:20 a=rtpmap:0 PCMU/8000 a=ptime:10 a=rtpmap:18 G729/8000 a=ptime:10 a=fmtp:18 annexb=no
There is a different prefix usage for these two scenarios. The issue scenario matches prefix 130, which didn’t activate a long number for caller number.
[125][0x000008d0][2018-06-18 02:40.61][ta_telnoana.c 2742]HandleCalledNoAnalyseMsg: match prefix 130,result = [50],ucComplete = [0] [99][0x000008d0][2018-06-18 02:40.61][ccm.c 76816][CCMNo = 2230] CCM_HostNumAnalysis: Host ucNumNetwork[0] [96][0x000008d0][2018-06-18 02:40.61][ccm.c 76825][CCMNo = 2230] CCM_HostNumAnalysis: numbers is:991990 [107][0x000008d0][2018-06-18 02:40.61][ccm.c 76871][CCMNo = 2230] CCM_HostNumAnalysis analysis NoMatch result[49] [87][0x000008d0][2018-06-18 02:40.61][ccm.c 7309][CCMNo = 2230] Caller number analysis failed! [102][0x000008d0][2018-06-18 02:40.61][ccm.c 7325][dwCCMNo= 2230] CCM_CallStartInfomationMsgProc: ucComplete 0 [74][0x000008d0][2018-06-18 02:40.61][ccm.c 34209][dwCCMNo= 2230] CCM_NumAnalysis [93][0x000008d0][2018-06-18 02:40.61][ccm.c 35381][dwCCMNo= 2230] CCM_CalledDNAna: subpbxno is: [0] [125][0x000008d0][2018-06-18 02:40.61][ta_telnoana.c 2742]HandleCalledNoAnalyseMsg: match prefix 130,result = [50],ucComplete = [0] [91][0x000008d0][2018-06-18 02:40.61][ccm.c 35537][dwCCMNo= 2230] Callee number analysis succeeded [75][0x000008d0][2018-06-18 02:40.61][ccm.c 27340]CCM_GetEmergencyCallSource Enter [106][0x000008d0][2018-06-18 02:40.61][ccm.c 27345]cannot find the component according to emergency ip 0xffffffff [75][0x000008d0][2018-06-18 02:40.61][ccm.c 37789][dwCCMNo= 2230] CCM_CLDDNProcess [74][0x000008d0][2018-06-18 02:40.61][ccm.c 44143][dwCCMNo= 2230] CCM_IsTailPound [96][0x000008d0][2018-06-18 02:40.61][ccm.c 37656][dwCCMNo= 2230]CCM_CallerNumberChangeProcess Entered. [146][0x000008d0][2018-06-18 02:40.61][ccm_patch_sph502_ims_blindtransfer.c 454][dwCCMNo= 2230]CCM_CallerNumberLongProcess Entered. CallerNumber is 991990 [113][0x000008d0][2018-06-18 02:40.61][ccm_patch_sph502_ims_blindtransfer.c 460][dwCCMNo= 2230]Caller doesnt use LongCLI. [116][0x000008d0][2018-06-18 02:40.61][ccm.c 37429][dwCCMNo= 2230]CCM_CallerNumberMapProcess Entered. CallerNumber is 991990 [86][0x000008d0][2018-06-18 02:40.61][ccm.c 37435][dwCCMNo= 2230]Caller doesnt use NumberMap. [120][0x000008d0][2018-06-18 02:40.61][ccm.c 37520][dwCCMNo= 2230]CCM_CallerNumberPredealProcess Entered. CallerNumber is 991990 Under normal circumstances, it matches the prefix 0 and it activates the caller long number function so the call succeeded.
[123][0x000008d1][2018-06-18 02:40.83][ta_telnoana.c 2742]HandleCalledNoAnalyseMsg: match prefix 0,result = [51],ucComplete = [0] [91][0x000008d1][2018-06-18 02:40.83][ccm.c 35537][dwCCMNo= 2231] Callee number analysis succeeded [75][0x000008d1][2018-06-18 02:40.83][ccm.c 37789][dwCCMNo= 2231] CCM_CLDDNProcess [74][0x000008d1][2018-06-18 02:40.83][ccm.c 44143][dwCCMNo= 2231] CCM_IsTailPound [96][0x000008d1][2018-06-18 02:40.83][ccm.c 37656][dwCCMNo= 2231]CCM_CallerNumberChangeProcess Entered. [146][0x000008d1][2018-06-18 02:40.83][ccm_patch_sph502_ims_blindtransfer.c 454][dwCCMNo= 2231]CCM_CallerNumberLongProcess Entered. CallerNumber is 991990 [127][0x000008d1][2018-06-18 02:40.83][ccm_patch_sph502_ims_blindtransfer.c 555][dwCCMNo= 2231]CCM New Caller Number is: d3751XXXX1990. [140][0x000008d1][2018-06-18 02:40.83][ccm.c 37991][dwCCMNo= 2231] CLDPredeal Process entered. Called Number is: 03751XXXX3011, Predeal Index is : 1 [84][0x000008d1][2018-06-18 02:40.83][ccm.c 38023][dwCCMNo= 2231] find Predeal Index is : 1 [124][0x000008d1][2018-06-18 02:40.83][ccm.c 38054][dwCCMNo= 2231] CLDPredeal Process Succeeded. New Called Number is: d3751XXXX3011
Root cause
The root cause of this issue is that customer did not activate the display long number function for prefix 130.
Solution
Activate the long number display for prefix 130.
Thanks for reading!
