It is sometimes difficult to figure out why a certain call is being call is being routed a certain way, or behaving unexpectedly. As a troubleshooting step, it can be helpful to peform call traces.

It is common to setup a phone switch with multiple T1s, each purposed with a special use. An example of such a configuration might be to have one used for local calls, and one for long-distance calls. To test the route that the call will make through the switch, you can run a couple commands and get a great deal of information.

The Avaya Audix VoiceMail system is fairly common in today's VoIP environments. I recently had a user report that they were unable to contact the Audix server. When the user tried dialing the Audix extension, it just kept ringing and ringing.

To check on the status of the channels in use, I used my browser to login to the server. I did the following:

It is good practice to check on the health and capactiy of your phone system. Ideally you should regularly check to see how many of your T1 channels are in use. On a typical T1 PRI, you have 23 voice channels available for calls. To view the number of channels in use....

If you are having outbound call problems, it is recommended that you check your equipment before calling the phone carrier. It is likely that your phone carrier will try to blame your equipment, and you need to make sure you've done your homework. You can check the health of your T1 PRI on an Avaya Definity gateway by doing the following...

Today was a day filled with phone calls to Avaya Support regarding their SoftConsole application. The SoftConsole application is intended for a switchboard style view for a receptionist/attendant.

The receptionist was given a new computer with a fresh install of SoftConsole. Avaya Support was contacted, because the SoftConsole would crash and lock the computer everytime an inbound call was received.

My previous post about "Use a Cisco IOS Switch to Serve DHCP to Avaya Phones" was inspired by my need to quickly test connectivity with a remote site. The solution worked very well for us. Eventually we were able to deploy a server to handle all DHCP, and needed to switch over to the services on the box. My initial reaction was to simply use the "no service dhcp" command to disable DHCP, followed by adding an "ip helper-address" to the VLAN interfaces. Surprisingly the DHCP server never received any of the requests. After comparing configurations with another switch, I discovered I needed to re-run the "service dhcp" command. I had compared the "show proc | include DHCP" and noticed the DHCP processes missing on my new switch. Apparently the "ip helper-address" uses some of those DHCP services for analyzing and forwarding to the server. I ended up just removing all the "ip dhcp pool" statements to keep things clean and from causing any conflicts.

Avaya VoIP phones require a special option in a DHCP scope, so they know how to make calls. There may be times where it is desirable to have the DHCP running on a piece of networking equipment on a remote site, so that a separate server is not needed for the role. In this example there are two VLANs on each port of a Cisco switch running IOS. VLAN 52 is for user traffic, and VLAN 222 is for the VoIP traffic.