No Incoming Calls – Now What?

The 3 troubleshooting steps to help you succeed

In this post, “No Incoming Calls – Now What?”, I have listed three steps to help you find and fix the most common issues that you may find when fixing this type of issue. From line identification, to testing the wire and verifying your system programming.

As a technician or system administrator, you are responsible for fixing the day-to-day breaks as they show up. I have experienced this issue many times and found myself trying to guess exactly where the problem exists. The purpose of this post is to help you speed up the process and help your customer along the way.

Here are the three steps that you may consider=

1. Investigate
2. Know where to start
3. Process of elimination

1.- Investigate

The first things you must do when arriving to the customer site are the following=

Communicate with the site contact –  In this stage, you are taking notes and jotting down the customer’s frustration.

Survey the site – Run a quick survey of the MDF and all the IDFs available, including patch panels, CAT3 Wiring blocks and any other Feeders coming into the customer’s premises.

2.- Know where to start

Now that you understand each component responsible for delivering your physical trunks into the building, it is your responsibility to start troubleshooting and diagnose which piece is defective.

I have put together the following procedures for you to follow when troubleshooting the “No incoming calls” issue.

Demarcation Point – For those who are not familiar with this terminology, it is simply how the Phone Service Provider delivers their dial-tone to the customer’s premises. This piece of equipment could be 66-Blocks, Smart-Jacks, or a 3rd party device.

Troubleshooting Copper trunks – Your job as a telecom technician is testing from the CPE (Customer Premise Equipment) side which is the other side of the demarcation point, normally the left side of the block, then connect your butt-set to test for dial-tone.

Checking Smart Cards (Smart Jacks) – These Network interfaces Devices or NIDs allow the Service Provider to deliver their DS1 T1/E1 service out to their customer via an RJ45 Connection located normally on a physical white box or extended jack.

These type of cards show an alarm when there is something wrong with the physical connection between the PBX (Avaya IP Office / Avaya Aura) equipment. It is one of the most common issues related to the “No Incoming Calls”. They also show B8ZS and ESF errors.

Wiring Specifications and regulations – There are a few things to consider when troubleshooting trunks, the first action step should be understanding what type of trunk has been implemented and who’s the Service Provider.

Type of Trunks – Copper LS (Loop Start) or GS (Ground Start) trunks are the two most common types of copper trunks delivered. Another consideration is knowing if they are part of a Centrex network. Ground Start trunks require the IP Office or Avaya Aura to be grounded in order for these trunks to work.

IP Office Caveat – GS trunks only work with the Analog ATM expansion modules.

Centrex Loop Start Trunks are normally found on local municipalities or townships; use to interconnect the local township authorities and facilities such as Police, Fire, Public Works, Yard Waste, etc.

T1/E1 Trunks – These are delivered to the customer’s premises and tested by the Service Provider prior to turning them up. Loop-back keys are commonly use to troubleshoot issues related to Framing, Slips, and dropped Packets. The recommended cable length is about 300 feet and for those using a 3rd party Integrated System Device or IAD to deliver and convert their services from Ethernet to DS1-T1/E1, a T1 cross-over cable is needed.

A T1 Cross-over t1 cable switches pins 1, 2, 4, and 5.

Phone Equipment – Each system such as the Avaya Aura or IP Office have boards where the line terminate into. You can look at the status LED of each card to see if there is an alarm or power going to them.

By now you should have determined if the problem was related to a physical trunk or connection. If the problem persists, then move on to the next section.

3.- Process of elimination

We have eliminated some of the items listed above. From the Wiring, Connections, Connectors, and PBX Line Cards, or Ethernet links are some of the elements that you should check before moving on to verify the PBX configuration.

Trunk Group Types – Many times when the customer complains that they are not receiving incoming calls, they hardly ever make an attempt to make an external call. When you first start troubleshooting, you should have the customer first call internal extensions, voicemail, then external calls should be tested ( local, long distance, and international calls if possible).

By performing the outgoing tests, you can pinpoint if the problem is related to a specific trunk or trunk group. In some cases, customer have trunk groups assigned base of call treatment or call type. For instance, a Verizon trunk group could be configured for long distance if the price is right, the same goes for a SIP trunk for international calling.

Busy-out / Reset / Release – For Avaya Aura, these commands can help you find the problem, by referencing the event code or denial event. Head to the Resource section of this post.

For SIP trunks try following =

• Ethernet Links – Test the link between the gatekeeper and the ITSP by running the ping command (On IP Office this could be accomplished trough the SSA application, and for Avaya Aura you can run it from the bash terminal).
• Check that NAT has been implemented – Some ITSPs will required this feature on, in order to receive multiple requests with a single FQDN or Gatekeeper IP Address.
• Authentication Expiry – Check with the ITSP, and see if the account is active. The Gatekeeper keeps the account active by sending hello packets to the ITSP. I have seen where the gatekeeper may stop sending these packets and the ITSP blocks the connection when the system is down for a long period of time. Another reason might be caused via the firewall and new implemented rules.
• Network updates – If the Gatekeeper’s FQDN or IP Address change, you must contact the ITSP so they can update their database.
• Licensing – Check if the licenses are active.

Automated Attendant – These can also cause the same results as “No Incoming Calls”. If the voicemail system happens to be offline, all of the calls directed to an automated attendant will receive a busy signal.

Follow these procedures to troubleshoot the voicemail system=

• Voicemail Pro for IP Office – It uses windows services that allow the database to run in the background. Make sure these services are running. If the voicemail system stops every two hours, then the problem is related to the local windows account, where it doesn’t have the rights to run these services. Licensing can also be an issue here; make sure they are active and valid.
• Intuity Audix Signaling Groups – Depending if embedded or external server are implemented, you should be able to ping across. Also check the links and TCP/IP Ports related to the communications link between the Aura Communications Manager and Audix. You can also busy/release the signaling groups to see if that restore the connection.
• Modular Messaging – These are server operated voicemails where you have a monitor attached and run diagnostics locally to see if there is anything wrong with the Kernel or OS.
• Connectivity – Voicemail communicate via IP / SIP / T1 or Analog stations.

 

Resources

Avaya Aura Denial Events

IP Office Monitor Doc – Refer to the ISDN section

Question – What steps do you take, when troubleshooting trunk related issues?