Quickly Figure Out Why Calls are Failing

Reaching back to my days as the Principal Engineer in support, I wanted my first blog to touch on something that the users of our system can utilize to save them time when something causes their calls to stop working correctly.  The key for a CIC administrator is to first narrow down whether the call problem lies on the SIP/network side OR the TDM/telephony side.  Figuring this out quickly can save the business countless calls, time, and essentially money!

The best place to determine which side the problem exists in is the gateway.  The two makes of gateway sold by Interactive Intelligence are AudioCodes and our own Interaction Gateway Generation 2.  We will concentrate on what to look for with these two gateways, but the logic can be applied to any make of SIP to TDM gateway.

Interaction Gateway Gen2

This is truly where the Interaction Gateway shines in ease of use.  The CIC administrator simply has to note one of the failed calls’ call IDs and then using a web browser navigate to the Interaction Gateway’s FTP site.  This will be ftp://IP_ADDRESS_OF_GATEWAY.

The username is: iguser

The password is: FetchL0gs (where the ‘0’ is a zero)

Then navigate to Logs->’Date_folder’->CallLog.csv and download the file.

Since this file is in a .csv format you do not need a log reader to open it (albeit it might be easier to read in a log reading program).

Open the file and perform a ‘control+F’ to find the trouble call ID.  Once you find the call you might have to adjust excel to read the entire call flow.  It should look similar to below.


Let’s dissect the above image.  First thing to note is that the call is broken into two different sub calls.  The first is the SIP side call and the second is the TDM side call.  You can tell which is which by looking at the text just after the callID= portion of the text.  This is a key point because whichever one of these “sub-calls” come first tells you whether this is an outbound or inbound call.  Whatever side the gateway starts logging first tells us which side “talked” to the gateway first.  In the image above that means that the SIP side was first, which means that this was an outbound call from the CIC server.  If it is an inbound call the TDM “sub-call” would be on top and the SIP “sub-call” would be on bottom.

The next key and what will immediately tell us whether this is a SIP or TDM issue is where the Remote Disconnect is logged by the gateway.  These calls are logged with respect to the gateway so the Remote Disconnect means that the far end side told the gateway to disconnect the call.  Notice that the other “sub-call” will always result then in a Local Disconnect because the gateway is responsible for hanging up the opposite side of the call once it is told to hang up the call.  Notice also that behind the Remote Disconnect is a numeral.  This numeral will tell the CIC administrator what the cause code was for the problem call.  The cause code can then be researched online for a quick reference to provide more explanation to the cause of the issue.

ISDN Cause Codes

SIP Cause Codes

At this point the CIC Administrator should have a good idea of whether he/she should call Interactive Intelligence support OR their telephony provider’s support.  Of course we will always be willing to join a telephony carrier call as well to assist if we can.


Now lets tackle the AudioCodes gateways.  The logic behind the process will be very similar to above.  We just have to use a different method of getting the tracing.

AudioCodes has a real time view to grab gateway communication.  To get to this view you simply navigate to the IP address of the gateway.  Login.  Then from the home menu go to Status & Diagnostics -> Message Log.  You will see the Message Log start producing as soon as the screen refreshes.  This is actually somewhat of a hindrance because it just adds more tracing to sort through later.  A way to seclude the tracing into a log is also available on our support site
This method of using ACsyslog allows the log to be written off onto any network connected device for review later.  This is useful for ongoing troubleshooting, instead of a quick glance.

Below is an example of a snip of the message log:

The message log is a mixture of SIP messages (that you can see are formated without a space between lines) and TDM messages, which I’ve outlined in Red.  The specific message I’ve outlined shows that the call in question was disconnected by the carrier because the gateway Received the message from the PSTN.  Also you notice at the end of the message that the ISDN cause code (called NetCause by AudioCodes) was 16.  Three lines below you also notice that the AudioCodes gateway sends a message via ‘PSTN send’ message to confirm to the carrier that we are releasing the line for future use.  If this call was disconnected by the CIC system then you would see the CALL_DISCONNECTED message behind the ‘pstn send’ message.

Again, at this point the CIC Administrator should have a good idea of whether he/she should call Interactive Intelligence support OR their telephony provider’s support.  We will always be willing to join a telephony carrier call as well to assist if we can.

Hopefully this will save some CIC Administrators some downtime one day!

Beau Benjamin

PSO – Field Services Manager