Netvanta 7100 Transfer to External Number Fails

It is almost Thanksgiving break and something critical has to come up to give us that healthy dose of bite-your-nails-till-they-bleed stress that we all need, right?

Grant it, a simple feature such as transferring an incoming call to an external number is probably not critical for most; but, in my line of business it is.  And now I’m out of time and working extra hard to get this issue resolved before my Thanksgiving vacation. Hmf!

So the problem is this:

Incoming calls come in over a SIP Trunk on an Adtran Netvanta 908e Total Access router and are delivered to an Adtran Netvanta 7100 via a PRI link between the two.  When it is after hours, the Netvanta 7100 PBX is setup with an Auto Attendant that greets the caller and transfers the call to an external number if the caller chooses the option from the Option Menu.  When the caller presses the menu option to be transferred there is silence on the line for several seconds and the message repeats itself.  The Auto Attendant is configured to play the recording again in the event the call fails, and fail it did.

A Debug Voice Summary on both units show the call sent out the PRI on the 7100 over to the 908e and then out the SIP Trunk to the carrier.  The debug also shows the call terminated with a “Temporary Failure” message.

As per technical support, the call was terminated by the PRI Trunk on the Netvanta 7100 so the transfer never completes.  I contacted the carrier with a call sample and the carrier stated that the calling party (customer cell phone) was the originating number and was not a VoIP number so the call fails due to authentication.  I replied back letting them know that the PBX AA is supposed to transfer callers to an outside number.  The carrier’s response was that “Perhaps, a valid VoIP Tn should be used as diversion header along with calling Tn… SIP invite message of the call sample indicated that there was no diversion header sent to carrier when the call was sent out either.”  I was not sure what that meant in English or what settings on the 7100 I should be looking at.

At that point I realized that technical support would not be resolving my issue promptly 😦  So I pulled out the Netvanta 7100 study guide and found the answer rather quickly by searching the term “diversion” and scrolled down until something interesting caught my eye.


Many SIP Service Providers will reject a call from an unknown number, that is, a number not registered to their switch
– Problems can occur when a user on the NetVanta 7000 forwards their phone to an external number
– When the user locally forwards their phone, the original calling party information will be preserved and sent in the From header of the SIP INVITE back out to the provider’s softswitch


Configure Calling Party (ANI) Match/Substitutions to allow forwarding of calls out a SIP Trunk
– Create an ANI Substitution template to match all numbers
– This will be used to replace the From header on forwarded calls along with all other calls routed out the SIP trunk

Thus, on the 908e that has the SIP Trunk to the carrier VoIP network, I navigate to Voice > Trunk Accounts and select the SIP Trunk.  Under the ANI Substitution tab, I entered the following:

Match Template: $

Substitution: The registered 10 digit VoIP phone number

And just like that problem fixed.


#908e-total-access, #ani-substitution, #diversion-header, #failed-transfer, #netvanta-7100, #sip-trunk, #transfer-call-fails, #transfer-to-external-number, #voip

Site to Site Extension Dialing Between SIP PBX and PRI PBX

Is it possible to set up site to site extension dialing between a SIP capable PBX and a PRI PBX?  At Site A we have  a Netvanta 7100 PBX which supports SIP.  At Site B we have a Toshiba CIX670 phone system that is setup with PRI.  Furthermore, Site A uses 4 digit extensions while Site B uses 3 digit extensions.

Yes, it is possible to have site to site extension dialing between a SIP capable PBX and PRI PBX.

First, there must be connectivity between both Site A and Site B; Site A should be able to ping devices on Site B and vice versa.  On a  private MPLS network this should not be a problem.

Second, there must be a SIP capable device at Site B that will process SIP calls to and from Site A on behalf of the Toshiba CIX670.  In this scenario, there is a Netvanta 908e Total Access router acting as SIP gateway that then delivers PRI to the Toshiba.

A SIP Trunk Account needs to be created on the Netvanta 7100 at Site A that points to the IP configured on the 908e at Site B.  A SIP Trunk Account needs to be created on the 908e TA that points to the IP address configured on the 7100 at Site A.  The port used is 5060.

A SIP Trunk Group needs to be created at Site A that includes the new SIP Trunk Account and that permits the digits you plan to use for dialing extensions at Site B. Since Site A is using 4 digit extensions, the permit template could look like 1XXX assuming 1XXX is not being used anywhere else on the system or by any other site that may be part of the VoIP network.

At Site B, a SIP Trunk Group that includes the new SIP Trunk Account needs to be created on the 908e that accepts calls to/from extensions at Site A.  For example, if Site A is using 7XXX extensions, then the SIP Trunk Group on the 908e at Site B needs to permit 7XXX.

At this point, dialing Ext. 1XXX  from Site A should be reaching the 908e on site B.  The next step is to route those calls to the PRI Trunk between the 908e and the Toshiba.  To do so, modify the PRI Trunk Group to permit 1XXX.  Doing this will route 1XXX calls coming in on the newly created SIP Trunk over to the PRI.  You can verify that calls are making it to the PRI by doing a VOICE> SUMMARY debug on the 908e.  While Debug is on, dial a 1XXX extension.  The Debug output should show dialed number 1XXX going from the new SIP Trunk over to the PRI Trunk.  If the Toshiba has not been configured to accept those calls, the call will fail with Unallocated Number message.

On the the Toshiba system, creating a DID table entry that routes incoming digits 1XXX to each of the 3 digit stations is the final step in allowing Site A to dial Site B extensions.

Allowing Site B to dial Site A extensions will require additional setup; hopefully a part II for this post will follow soon.

#adtran-netvanta, #netvanta-7100, #pri, #sip, #sip-to-pri, #site-to-site-dialing, #site-to-site-extensions, #voip

Polycom IP 650 Boot Loop

In an organization using Adtran Netvanta 7100 PBX, the system firmware on the Netvanta 7100 was updated to R11.4.2.E.  After the Netvanta 7100 firmware update, changes to Voice User Accounts could not be made unless the phone model was updated.  In this case, 2 more line keys needed to be added on a Polycom IP 650 phone.  The phone model was changed to ADTRAN/Polycom IP 650 from the drop down menu under IP Phone Configs.  The changes were then applied successfully.  However, upon rebooting the phone, changes made to the phone’s configuration were not taking place.  Reset to Default – local configuration had no effect.  Reset to Default – Device Settings placed the phone in a reboot loop.  Ultimately, reviewing the MAC ADDRESS.cfg file for that voice account and comparing it to that of a working unit, revealed that it was missing an entry.  In the MAC ADDRESS.cfg file, under CONFIG_FILES=”polycomboot.cfg, customer-sip.cfg, customer-sip-MAC ADDRESS.cfg, customer-sip-spip650.cfg, adtran-sip_40x.cfg, xxxx-MAC ADDRESS.cfg”/> it was missing SIP.cfg.  Once sip.cfg was added between quotes the phone booted normally and changes applied to the phone’s configuration were in effect.

#adtran, #boot-loop, #netvanta-7100, #polycom-ip-650, #sip-cfg, #soundpoint-ip-650, #voip

Adtran Netvanta 7100 Failed Calls Incoming / Outgoing to External Numbers

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:

  1. Develop a reboot process and schedule to prevent these sort of problems from happening.
  2. 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. 🙂


#908e-access-router-pri, #adtran-netvanta-7100, #failed-calls-to-external-numbers, #failed-incoming-calls, #failed-outgoing-calls, #netvanta-7100, #netvanta-7100-pri, #pri-trunk, #voip

Adtran Netvanta 7100 – The Number You Have Dialed is not in Service

The Number You Have Dialed is not in Service

I have a love hate relationship with our Adtran Netvanta 7100 PBX.  It is an all-in-one type of device that serves as router, POE switch, and PBX.  What makes this device so awesome is the amount of features you get at a low cost when compared to other comparable devices.  The web based graphical user interface is easy to navigate and allows me to administer just about everything.

Having said that, every now and then we receive helpdesk tickets regarding failed calls, dropped calls, ghostly rings, etc that make me what to call an exorcist.  To be fair, most complaints are due to lack of user training, settings and/ or features that were misconfigured or disabled and, occasional technical issues on the service provider side.

Not long ago we began getting helpdesk calls about callers receiving a recording after dialing the business number.  “The number you have dialed is not in service.  Please check the number and try your call again later.”  When I tried calling, the call would ring at the other end and someone would answer it; I tried this many times and it just made the problem seem all that more mysterious.  Eventually I was able to confirm that the recording was in fact coming up but not with every call.  It seemed to be more likely to pop up in the early morning hours.  Looking at the call logs, I initially thought that calls were not making it through to the Netvanta 7100 and that they were failing on the caller’s side.  But after I contacted the service provider and they traced the calls they proved me wrong and confirmed that calls were actually making it through but were getting a busy signal.

After the issue was proved to be on our side, the first thing I did was check the system time on all our Netvanta 7100 devices.  I have a manic compulsion to have the time set correctly.  Adtran engineers have already dismissed my suspicions that having the wrong date/ time set can potentially cause call problems.  Still, I revised the date/ time settings and thought for a second that had fixed it but I was wrong.

My next bet was to reboot the device as this has relieved other issues in the past.  And for this reason, I don’t believe the Adtran Netvanta 7100 to be as reliable as other PBX devices out there.  It works for us because we do not mind doing an occasional reboot.

Now this is where things started moving quick and confusion settled in.  A reboot got scheduled and everything came up fine but, afterwards the device kept on rebooting every so often on its own.  This was probably due to the system time reverting back to a previous date and time and therefore, performing the scheduled reboot yet again and again and again like an old Richie Valens record.  After I caught on to that fact, I canceled the schedule reboot and, just in case, updated the firmware from A4.xx.xx to R11.4.2.E; as you may have noticed, that is quite a big firmware upgrade and was long overdue.  Around the same time, I was monitoring the network for other non-related problems; doing so, I noticed bandwidth bottlenecks right around the time the recording was coming on for a test call I made.  I thought it possible that the bottleneck was causing the failed calls and put a bandwidth limit on all client machines.

In the end, I don’t exactly know what caused the “The number you have dialed is not in service…” message; I do know it is fixed though.


#adtran-netvanta-7100, #failed-calls, #netvanta-7100, #recording, #the-number-you-have-dialed-is-not-in-service, #voice-over-ip, #voip

ADTRAN IP 706 / 712 Phone Blank LCD Screen

Adtran IP 712

The LCD screen on two Adtran IP 712 phones recently went blank.   Other than having a blank LCD screen, the phones seem to be working fine; i.e., phone calls keep coming in and are able to be picked up.  The functionality of buttons was not tested.

The Adtran IP 712 phones are accessible through the web GUI using the following formant http://192.168.XXX.XXX/admin.  FYI, the default Username = admin and Password = password.  In our experience a Reset and Factory Reset via the web GUI did not fix the issue.  On one occasion, one of the phones booted up normally but the LCD screen went blank again several minutes later.

We were able to resolve the blank LCD screen for only one of the Adtran IP 712 phones by deleting the User Acct and Phone Config and creating them again (we are using Adtran Netvanta 7100 PBX).  The phone was able to boot up normally after that and the blank screen is fixed.

On the second phone the same fix did not work and was eventually replaced.  The root cause is still unknown but suspect corrupt firmware and/or missing phone firmware on the Netvant 7100 PBX.


#adtran-ip-706, #adtran-ip-712, #adtran-netvanta-7100, #adtranpolycom-ip-712, #blank-lcd-screen, #netvanta-7100, #voice-over-ip, #voip