Go to Chapter 2.3.   :  Chapter 2.5        Contents

Section 2.4 Debugging Tools and Taking action

• 2.4.1 Debugging Failed calls
• 2.4.2  Pinging an IP Address
• 2.4.3 Tracing
• 2.4.4 Making a Test Call
• 2.4.5 Busyout Channels

2.4.1 Debugging Failed calls

It is straight forward to know all about connected calls by watching the DS0 Graphic Elements and the Call Information Text Box, but it is not quite so with failed calls. A failed call may show as a short flash or maybe even as connected when there has been no real connection, even worst, not all calls that fail will show on the GW_monitor. In order to get to be displayed a call attempt will need to have a channel, but this may not happen if:

• a VoIP call attempt  finds no match to a dial peer
• a VoIP Call attempt finds no available channel in the assign DS0 group
• a Pots Call attempt with an unmatched dialed number (or just no dialed number)

That is why there is this Failed Call Indicator. The Failed Call Indicator works as followsl:

• Failed calls with matching dial peers, will blink the background in red with the number of failures detected in white, then it goes back to gray but still showing the count,
• Calls with no matching dial peers, will make the background blink in blue displaying DstUnk 1 in white, then back to gray 
• If no calls are detected the indicator will blink in green and then back to gray with no count showing.

If you need to know why are the calls failing, all you need to do is check the Debug Check Box. From that moment on, detailed information on failed calls will be sent to the Debug Info Window. Unfortunately, only those calls that matched a dial peer have detailed info to be shown.

Each leg of every failed call is reported together with the hour the report was received. This make it easier to trouble shoot link problems.

2.4.2  Pinging an IP Address

Of course you can ping any IP address from a command line in your computer without help from Big Bro, but no body can guarantee that the return time reads the same that when issued from the gateway itself. The only way, is to use a TELNET session an have the gateway ping that IP address. It is undeniable that is a lot easier to click mark on the channel where you spot trouble, hit the ping button and watch the ping result on the Debug Info Window.

2.4.3 Tracing

This is an evolving feature, the final goal is to be able to select one or more channels in a span, and send to the Debug Info Window all the information that is received regarding the marked channels. As for now, when Trace checkbox is checked, the Call Information Text for all the marked channels is sent to the Debug Info Window.

This features allows you to track latencies, gap ratios, bandwidth, etc. as call progresses.

2.4.4 Making a Test Call

This feature requires access to privileged commands (See 2.3.1). The Test Call button "Start" will go black, meaning it is enabled. Before making a test call, you must enter a valid phone number and it will be properly routed according to the dial peer definitions on the gateway. The result of the call will go into the Debug Information Window:

2.4.5 Busyout Channels

This feature requires access to privileged commands (See 2.3.1). When access is granted, the Busyouy and Unbusy buttons are blacken meaning they are enabled. There can be quite a lot of traffic operation reasons for removing channels from service:

• to block traffic from a client that has exceeded his credit limit
• to divert traffic when a termination is down
• to avoid outbound traffic in the event of a rate increase from a provider.
• to divert traffic from a provider that is not terminating with an acceptable completion rate.
• to regulate traffic
• and more...

The term busyout is generally used in reference to CAS spans, PRI DS0's are said to be set "Out Of Service" not busied-out, this is not just a naming issue, commands on the gateway are totally different. Big Bro is taking the liberty to use the term busyout for CAS as well as for PRI, even though, internally, the commands will be handled differently. In the case of aCAS span, it will set its signaling bits to the busy state, this will prevent the network from sending further traffic into that channel. PRI spans will send a service request through it data channel, telling the switch that a specified channel or channel interval is Out Of Service. Of course, we are assuming that the connected switch supports busyouts and service requests, which, unfortunately, is not always the case.

To busyout a channel or a group of channels, you must first mark them (See 2.1.1). Once all the channels to busyout (or Unbusy) are marked you may hit the buttons Busyout or the Unbusy. To avoid anxiety it is good to know that it can take several seconds for the blue to show in the Call State Square.

There's a Hard/Soft checkbox, some software versions in some gateways support a feature called Soft Busyout. It consists in that, if a channel has a call in progress, it will wait until it is done and then busyout the channel. To know if the feature is supported, you will just have to try on one with a call in progress, if it drops the call, too bad. If, on the contrary,  it doesn't and after the call is finished it goes blue, well...good for you.