There are a plethora (a large or excessive amount) of reasons why VOIP calls may fail. Having overall knowledge of the VOIP networked components is important in troubleshooting Adtran Netvanta 7100 Failed Calls.
Having a good understanding of the infrastructure and components that make up the Voice Over IP network of an organization is important because it can help you narrow down the point of failure quicker, especially if you don’t have as much experience and training in VOIP telephony or the Adtran Netvanta 7100 PBX.
Additionally, the ability to communicate with the end user in order to get detailed information regarding failed calls can make a huge difference in the steps taken to correct the problem.
For example, at a site with a Netvanta 7100 PBX system, an end user contacts the helpdesk to report that he/ she is unable to receive incoming calls. Upon further questioning, the user states that about two out of every five calls fail.
As a technician, it is rule #1 to get as much detailed information from the user/s experiencing the problem as this information often times can narrow down the problem to a certain component or device.
Going back to our example, the user also explains that she is unable to call out and that she gets a fast busy signal when doing so. You corroborate what has been said by making a few test calls and do in fact receive a busy signal when attempting to call the site’s number. The user has previously rebooted the Adtran IP 712 phone but we know that would not make a difference because the reported issue is affecting the whole site and not just that one user.
On a previously working Adtran Netvanta PBX phone system that is now experiencing failed incoming/ outgoing calls, and if no recent changes have been made, rebooting the device resolves the problem 8 times out of 10; that is from my own experience. I consider the Netvanta 7100 PBX to be “buggy” when compared to other VOIP solutions out there; it offers great functionality and features at a low monetary cost. The downside is that it does tend to be less stable than some of its more popular competitors.
If you want to avoid downtime and sporadic failed incoming/ outgoing calls here are two tips for the Netvanta 7100 PBX:
- Develop a reboot process and schedule to prevent these sort of problems from happening.
- Update Netvanta 7100 firmware to the Extended Maintenance Release to stay up to date with the latest bug fixes.
Using the previous example, prior to disrupting production by rebooting the device during operating hours, it is a good idea to contact the service provider to rule out problems on their network. Once the provider has reported back and confirmed that calls are in fact being delivered to the customer equipment we can look forward to performing a reboot of the Netvanta 7100. Since we will be rebooting the device, we go ahead and update the firmware to the latest extended maintenance release (currently R11.4.5) Prior to updating the firmware, it is important to read the NetVanta 7000 Series Products AOS Release Notes for the firmware you will be updating to. It includes important information such as hardware and software requirements for networked devices and IP phones. It also includes information on bug fixes and bugs still present in the release.
Another important clue in this scenario is the fact that failed outgoing calls are all to external numbers and not internal extension numbers. As internal calls go through various SIP trunks we can suspect a problem with the PRI trunk that handles external incoming/ outgoing calls to the Netvanta 7100. In our scenario, the PRI trunk interfaces with an Adtran 908e Access Router. Incoming calls to the site are delivered by the service provider to the 908e Access Router that routes the calls over to the Netvanta 7100 PBX.
Surprisingly, after rebooting the Netvanta 7100 PBX, incoming/ outgoing calls to external numbers are still failing. We suspect the PRI trunk. As the service provider has confirmed delivery of calls to customer equipment and being that rebooting the 7100 did not resolved the problem, we now look to the other end of the PRI, the 908e Access Router. From my experience, it is rare that the 908e acts up; it is usually the 7100. This time however, rebooting the 908e Access Router resolved the issue and everyone is happy once again.
As a last note, the end user that called reporting the problem with failed incoming / outgoing calls comments that faxes are now working as well and that they had not been prior. That minor piece of information that was missed would have proved significant as fax communications for that site are handled exclusively by the 908e Access Router; we could have pinpointed the trouble device right from the start avoiding an out of town trip, hours of going over settings and debug logs, an unwarranted firmware upgrade, etc. 🙂
