PSTN incoming and outgoing problem | Fxo h.323 gateway

[SwathyEdayath]

Dear Team,

PSTN incoming/outgoing calls are not working for one of our location . we have h.323 gateway with 6 fxo lines .  attached notepad contains debug output for " debug voip ccapi inout " command , where called party number is : 909 (tollfree). please suggest on this issue.

Thanks

Swathy

[Ayodeji Okanlawon]

Your have not mentioned what call control system you are using. Cucm?

The call is been disconnected from the system where it originated from. So until we know how your gateway is configured with the other system we won't be able to troubleshoot.

+++ the cid = 25 belongs to the originating leg and the ccapi disconnect shows the gateway received this information +++

000441: *Mar 12 10:35:02.907: cc_api_get_xcode_stream : 4983 000442: *Mar 12 10:35:03.023: //25/80325535AC07/CCAPI/cc_api_call_disconnected: Cause Value=16, Interface=0x2236F218, Call Id=25 000443: *Mar 12 10:35:03.023: //25/80325535AC07/CCAPI/cc_api_call_disconnected:

[SwathyEdayath]

Hi Team,

We have cucm 11.0 .everything was working before . Now when I make outside calls there is no ring back also the calls are not getting connected . I have logged a case with telco .

Thanks,

Swathy

[Mohammed al Baqari]

I don't see any problem with your logs. Let's see what the telco is coming back with.

[SwathyEdayath]

I will let you know .Thank you so much for your support .

[Mohammed al Baqari]

You are welcome. And always remember to rate useful posts :)

[SwathyEdayath]

Dear Team,

Telco visited the site . they found the problem with the analog line physical connection . as I am not at this site I couldn't confirm this physically . now the issue has been resolved . thank you for you both for prompt help on time .

[Ayodeji Okanlawon]

Mohammed,

Something is not right with the logs. Calls are disconnecting immediately after CCAPI tries to connect . Cause code 16 is just a normal code issued when the gateway doesnt know what code to issue.

ccapi sent a call connect to call leg with cid=25 at 10.34.45

000417: *Mar 12 10:34:45.979: //25/80325535AC07/CCAPI/ccCallConnect:

at 10:35:03 ccapi received a call disconnect from that call leg. ( this is 15sec after issuing the connect message)

000441: *Mar 12 10:35:02.907: cc_api_get_xcode_stream : 4983
000442: *Mar 12 10:35:03.023: //25/80325535AC07/CCAPI/cc_api_call_disconnected:
Cause Value=16, Interface=0x2236F218, Call Id=25
000443: *Mar 12 10:35:03.023: //25/80325535AC07/CCAPI/cc_api_call_disconnected:
Call Entry(Responsed=TRUE, Cause Value=16, Retry Count=0)
000444: *Mar 12 10:35:03.023: //25/80325535AC07/CCAPI/ccConferenceDestroy:
Conference Id=0xD, Tag=0x0
000445: *Mar 12 10:35:03.023: //25/80325535AC07/CCAPI/ccConferenceDestroy:

++ So if this is an outbound call, then the issue is with CUCM, because CUCM will be the inbound call leg with cid=25, in which case it will be better to look at cucm and more logs from the gateway to know why cucm is dropping the call, otherwise chasing telco will be a waste of time ++

++ Is this is an inbound call, the cid=25 will be telco and in that case a case with them will be appropriate ++

[Mohammed al Baqari]

Hi Ayodeji,

The connect which you are referring to is part of the voice cut-through process (i.e. ringback).

000401: *Mar 12 10:34:45.979: htsp_process_event: [0/1/2, FXOLS_WAIT_CUT_THRU, E_HTSP_VOICE_CUT_THROUGH]fxols_handle_cut_thru
000402: *Mar 12 10:34:45.979: htsp_timer_stop
000403: *Mar 12 10:34:45.979: //26/80325535AC07/CCAPI/cc_api_call_connected:
   Interface=0x416DEE3C, Data Bitmask=0x1, Progress Indication=DESTINATION IS NON ISDN(2),
   Connection Handle=0
000404: *Mar 12 10:34:45.979: //26/80325535AC07/CCAPI/cc_api_call_connected:
   Call Entry(Connected=TRUE, Responsed=TRUE, Retry Count=0)

The call is outgoing call from CUCM to PSTN and based on the logs the call leg which is disconnecting the call is CUCM call leg (id 25). But based on the sequence I can imagine the scenario as call ringing which the caller can hear then no answer so CUCM will timeout and terminate the call (or caller drop the line).

Swathy, can you please confirm if this is the scenario (you can hear the ringback then the call drops or you disconnect it)?

[Ayodeji Okanlawon]

Mohammed (+5)

it does make sense that call times out but cause code 16 is very misleading so I don't generally trust it.

looking back at my post the call didn't disconnect immediately, it disconnected after 15s so that's a long time and cucm can terminate the call but cause code should be remote destination didn't answer not normal call clearing 

Thanks

[Mohammed al Baqari]

You are right Ayodeji about the cause code. I believe this might be the case on the CUCM but it might be CV=16 is sent to telco.

As the problem is fixed now I don't think we will be able to confirm it :)

[Ayodeji Okanlawon]

Swathy,

Is this trace for outbound or inbound call.

What is the protocol used between cucm and your gateway?

And why are you rating my suggestion 3 stars when I have given you a perfectly accurate answer :)

[Mohammed al Baqari]

Seems that the other party didn't answer the call. I can see ringback cut-through took place but the call wasn't answered. This was followed by normal call clearing (cause value = 16).

If the other party isn't ringing, you need to contact your telco as the problem will be at their end.

On a side note, was this working before?