After defining the call routes, you can customize the dynamics of the VX by setting parameters, as described in the following sections:
Every VX node on the network must be configured with a single unique node identifier. This setting is similar in appearance to an IP address, and serves a similar addressing purpose, but it is expressed as a 4-part identifier with colon-character delineators - such as 1:2:3:12 - rather than the periods characteristic of dotted decimal formatting (as in IP address 22.214.171.124).
A single VX node can be assigned several IP addresses, which can make it difficult to identify especially if those IP addresses are dynamically assigned or otherwise change over time. Only one nodeID per VX node is allowed.
The nodeID also allows the unit to be identified in non-IP environments.
A VX node can be used by multiple user accounts. Each user account can be provided with a separate login to use the VX CLI or VXbuilder configuration applications. Various user account levels allow access to commands for viewing, monitoring, and changing system parameters. Level 2 access is required to download configurations from the VX node to VXbuilder: Level 15 access is required to load configurations from VXbuilder onto the VX node.
Access for each user to each level is enabled by configuring a password for the level. Multiple levels can also use an identical password.
VX supports the tracking of calls, for billing purposes, by way of the VXgate software. After loading and configuring the VXgate software on a PC dedicated only to the VXgate application, you can run Call Data Record (CDR) logging on as many VX nodes as you wish.
Besides passing calls, VX can also operate as an Interactive Voice Response (IVR) system---which is a phone tree. VX has its own language for writing scripts, in which each channel contains a configuration value to define the script function it should invoke when the channel receives an inbound call.
This applies to the inbound channel only. Depending on the nature of the script invoked, there may never be an outbound channel. In this case, VX terminates the call. Alternatively, the script can be used to make several different calls with several different outbound channels but still only the one inbound channel. In any case, the 'AAAFunc' setting on any outbound channel(s) has no effect.
Virtual Cards for SIP, H.323, and BSP
SIP, H.323, and BSP are Voice-over-IP protocols that do not require special hardware such as, for example, a T1 ISDN interface. However, these protocols must be configured at the VX node as if they do require special hardware. This approach makes the handling of the VoIP protocols identical to configuring traditional TDM protocols. Within VX, all protocols become channels---any channel can talk to any other channel.
This approach to treating all protocols in a generic fashion which means that you install virtual cards and ports into the VX node to handle VoIP protocols. They do not really exist but they are represented in the configuration as if they are physical devices.
The configuration contains a definition for a slot that is additional to what the physical chassis actually contains. This single slot must be marked as a virtual slot.
The VX node allows configuration for only one virtual slot, that can contain any number of virtual ports. A typical configuration defines one virtual port for each VoIP protocol.
VoIP protocols do not require individual channel configuration. And there is no physical limit to how many channels. It is not, however, a good idea to assign more channels than the maximum performance of the network can handle. Use this value to throttle the maximum possible resource usage.
Any time TDM channels are part of the VX node (for example, T1/E1), clocking becomes a consideration. These lines transmit digital data synchronously and continuously. The specific rate at which each bit of data is passed along is determined by a very fast clock.
Synchronization is key to these types of networks. These connections are never idle. There is a constant stream of data frames travelling across them even if the data is blank.
To understand why clocking is important, consider a T1 router device with one T1 coming in and one T1 going out. Data is continuously flowing from one T1 to the other.
If the clock on the incoming T1 was transmitting data at 1.550 Mhz and the outgoing T1 was transmitting data at 1.540 Mhz (just 1% slower), the slight difference in clock rates would mean that incoming data would eventually overrun the outgoing data. That is, the data flow on the input side is just slightly faster. The router will eventually have to drop out a frame to resynchronize the two T1's. In this case, it would have to drop one frame for every 100 frames that came in.
Internal oscillators are typically more accurate than the 1% margin in this example. Nevertheless, in a network composed of many T1 lines and chains of T1 lines, the timing differences between hops add up and result in unacceptable losses of data. The whole network quickly becomes unable to pass data at all.
The primary method used to defeat this problem is providing the same clocking pulse to all of the T1's. Other devices connected to it use its transmitted clock pulses rather than internal oscillators. In this way, an entire network could synchronize against a single oscillator. All of the data flows will line up.
VX has an internal system backplane which can provide timing for all TDM lines plugged into the unit. The user must decide whether VX is generating clock for the network or if it is receiving clock from the network.
If VX is generating the clock, then the user must select which internal oscillator to use. Each TDM card has one; any of them will work. The internal bus will be clocked from that oscillator. Typically, all of the TDM lines plugged into VX will be set to emit this same clocking for other devices to use.
If VX will be slaved to a clock generated by (or passing through) another device, it will be necessary to select a port from which to draw the clock. That received clock signal will drive the internal bus and the timing of all the other TDM ports on VX. In this case, VX may be set to have one port as slave (and drive the bus) and the rest set as master so that it distributes the received clock to other devices.
Many configurations are possible, depending on how clocking is designed to be distributed through the network as a whole.
Individual ports can be set as master or slave for clocking. Ideally, one side of each TDM connection should be master and the other slave. It is possible, though not desirable, for both sides to be master. They may drift in that case unless both sides are actually synchronizing to the same clock elsewhere.
Be careful not to set up a situation where both sides of a connection are expecting to receive clock.
VX configuration defines a primary and secondary clock source to use for the internal system backplane. The secondary clock selection only comes into play if the primary clock is unavailable. This situation can happen, for example, if VX was receiving clock for its bus from a T1 line that is disconnected.
Simple Network Paging Protocol (SNPP)
VX supports the paging of technicians through the use of an internet paging service. When alarms are generated at or above a configured degree of severity, VX will issue a page. The IP address of the paging server and recipient of the page can be configured.
VX makes extensive use of IP networking. In fact, most of the commonly used interfaces are IP-based. VX is commonly used as a gateway between IP-based telephony and TDM-based telephony.
A typical VX node has two ethernet ports. These ports can be configured with any number of IP addresses. Each local IP address is treated as if it were a separate IP interface by VX. They are given names like 'ip0' and 'ip3'.
The user should understand that 'ip0' and 'ip1' do not necessarily represent the two Ethernet ports. Both of these could be on the same port with two different IP addresses. These are IP interfaces, not Ethernet ports.
Which physical Ethernet port an IP interface is associated with is part of the configuration options for that IP interface.
In most cases, a VX only needs one IP address. But there are times when two or more are useful.
VX needs to know how to reach other VX nodes in the VX network.
Since VX nodes are uniquely identified by NodeID numbers, this table lets VX know which remote IP address to use to reach each node with which it will be communicating. ICMP peers can also be defined to enable LQM statistics for VX nodes using ICMP "pings."
A single VX node could have several different IP addresses. So, an IP address listed in this table is the one this VX node will use to contact that node when using this particular IP interface. In complex networking configurations, this can be a useful distinction.
Since VX may have several different IP interfaces, this table is used to select which local IP interface to originate IP connections from based on the remote IP address.
Be especially careful when altering this table. Access to the node can be severed by making an error which routes IP packets to the wrong place.