HowTo: Tracing outgoing calls due to connection problems

NiclasCpm · ‎12-18-2008

Hi,

our phone systems consists of a voice gateway, a publisher, a subscriber, a mobility manager, an UMS-server and two VG224 gateways. The publisher runs Cisco Call Manager 4.3.

Phone calls are forwarded directly into the exchange (line).

Recently we're having the problem that some users receive a fast busy signal for outgoing calls. They have to try twice or even three times to establish a connection.

To checking purposes I'm tracing the outgoing calls by telneting the gateway and using the "show voice call summary" command.

Important for me are the informations concerning the outgoing interfaces (here: SE010 and SE011).

There I can see the established connections and I'd like to see if the 60 ports in the whole (30 for each interface) are busy.

Now is there a way to export these details ?

irisrios · ‎12-24-2008

Most commonly these problems are caused by a calling search space issue on the gateway. Please double check and confirm that the calling search space of the port matches the calling search space of another port that is working.

Nicholas Matthews · ‎12-24-2008

Hi Niclas,

'show call active voice brief' will probably be more helpful for you.

Each call will have two call legs, one IP and one PSTN. Each call leg will begin with 3-4 hex values followed by a colon. You can use this to match two call legs. In the IP leg you will see some interesting information: IP address this RTP stream is sent to (normally the phone or other gateway), the transmitted and received packets, the codec, and the lost/jittered packets.

In the PSTN leg you will see some values like: received and transmitted packets, the serial interface the call is on, the channel of that interface the call is on, and signal levels of the rx/tx.

What you'll be most interested in is the interface and channel on the analog leg, and the IP address of the IP leg. Using the duration that is listed in both legs is a good sanity check to make sure you have the right call.

'show voice call summary' is good to get a better visual of where calls are landing.

This is how I would troubleshoot this issue:

Make sure that the failed call are actually making it to the gateway. It's possible there's something going on in CUCM. You can do this by:

-enabling the logging buffer

-starting 'debug isdn q931'

-clear log, place a call. If it worked, clear log, try again. Keep placing calls until a call fails. When the call fails, 'undebug all'.

-check the logging buffer for the called number you called. See if it's even in the log.

-If it is in the log, see who disconnected it. You'll see either a RX or TX direction on a DISCONNECT, RELEASE, OR RELEASE COMPLETE.

Based on this you'll know some very important information:

1) If CUCM is disconnecting the call

2) If the gateway is disconnecting the call

3) If the provider is disconnecting the call

Without knowing who is disconnecting the call it's not even worth speculating.

Hope this helps you track this down a bit :)

-nick

NiclasCpm · ‎01-07-2009

Hi nick,

please excuse my late answer but your information is very helpful.

I'll look through the informations being provided by the command and hopefully see what the matter is.

Regards,

Niclas