VTL reboot

[criticalUpdate]

Have an issue where we run Virtual tie Lines across to several locations over t1's and every time there is a hiccup in the line the NBX needs to be re-booted.

Is there a way to avoid this?

Jeff

 

[GoTellBigDaddy]

First- make sure you are on 4.1.77 or higher

Then:

** Troubleshooting **

- It is always a very good practice to set up a code in your dial plan as a loopback test so that VTL setup can be verified to be completely functional on each box separately, to diagnose problems. Click [here] for procedure to set up loopback entries in the dial plan. Basically, a code of *885 (spells *VTL) is set up in Table 1 and a corresponding route using VTL ports to your own IP address, you can dial *885+ext of any extension on the same box, to test VTL dialing within a single system. This is a must for traveling from site to site, setting up VTL, where you want to confirm each site is working before going onto the next.


Quick Tips:
"not allowed" - determine which NCP is not allowing the call - yours or the remote system - it will likely be a dial plan, devices using, or CoS issue on that system
"dead air" or "dead air then busy after 30 seconds of silence" - check dial plan on either system for min/max -
"no ip resources" - not enough addresses in the IP on the FLY address pool range
"all ports busy" - your own VTL ports are not available. Confirm they are in *0006, and that your route uses *0006 extension list. Also, if you've been testing, check the VTL stats - ports may be locked trying to connect to remote NCP with a router / network link issue
"busy signal but not all ports busy showing in LCD" - busy is coming from remote system. Investigate dial plan and digits passed to remote system as processed in Table 1 on remote system dial plan
"vtl ports hang" - network issues. DSL/Cable modems, or Frame Relay with high DE configurations often provide poor connections for VTL. Frame Relay should be configured with zero DE by design, for VoIP consistency.


+++++ Find out if the call is getting to the other NCP +++++

A common error is seeing "not allowed" in the LCD when dialing a VTL extension. This "not allowed" message may be coming from your own NCP (Class of Service restriction) or from the remote NCP, indicating that the number dialed is not allowed on the other system under current configuration between systems. Basically, if the call makes it to the other NCP, then the "not allowed" message is from the other system's dial plan. Use the VTL Statistics screen, which shows how many calls were SENT and how many calls RECEIVED, to find out if your test call is making it to the other NCP, to decide where the problem lies in routing the call.

To Do This:
1. Reset the VTL statistics on BOTH systems (sending system and receiving system)

2. Make your test call that keeps failing

3. Check the sending system's VTL stats - confirm if 1 call has been SENT or not. If it has not, your own system has the problem, and is not even attempting to send the call to the other system.

4. Check the receiving system's VTL stats - confirm if 1 call has been RECEIVED or not. If it has not, but was sent from the other side, the issue is likely routing / network / NAT /Proxy/ Firewall issues. If your test call shows 1 call RECEIVED on the system you are calling, this indicates the problem lies with that system, and troubleshooting depends on the reason why a call cannot be completed. For example, if "not allowed" and the VTL stats show the call is being received at the other system, it is a dial plan issue on that system - two likely reasons are:

** VTL's are not set as "devices using" assigned to Table 1 - Internal Extensions table
** VTL's have been erroneously assigned as "devices using" or "Devices using for CLI" to a pretranslator. As a rule, VTL ports should not be using a pretranslator

+++++ If all else fails +++++
You may have to resort to logging, or network packet tracing, in rare cases.

Use VTL loopback testing on each system, and check VTL stats to find out if call is failing on your system, due to network

Use the hidden screen in NetSet to enable logging for VTL ports, and check the NBoss log files after turning logging ON and making a test call that fails. You must call Tech Support for assistance using the hidden screen to enable logging for the version your customer is currently running.

 

[GoTellBigDaddy]

BTW:

Get the extension for the VTL you want to reset. Go to this page inside of your phone system and dump in the extension.

http://YOUR

SYSTEM IP ADDRESS/sec_cont/ops/devmgmt.htm