VX Watch Enhancements
VXwatch has been enhanced in System release 4.7 to increase usability. These enhancements include:
VX Watch Call Duration Display
Provides the ability to see how long a call has been up in VXwatch.
The VXwatch GUI now calculates the time from when the call connects to current time and display it in a user friendly format.
The counter does not increment while the call detail pane is open.
Multiple Nodes in a single window
In VX 4.7 the ability to show multiple nodes in a single VXwatch window has been added. For certain deployments with smaller configurations having to have multiple nodes on separate windows is undesirable. This enhancement allows the user to connect to multiple nodes from a single window.
For large nodes it is recommended that multiple windows are used.
VXwatch now includes a new node button that allows the user to add another node to the same window. Each of the nodes must have the same zoom level.
Calling Name Display
VXwatch now displays the calling name of the call under the call details pane. This allows the operator to access the calling name of the call without having to look in the command line interface.
SIP Registrar Table Display
VX has the ability for SIP devices to register directly with it or cache registrations in Proxy-like mode. In previous releases the only way to see the registered devices is the command line interface.
Fully Qualified Domain Support for Ping Command
Previous VX releases would only allow the ping command to ping an IP address. This is useful for network troubleshooting but it does not allow the user to check if the configured DNS server is working correctly.
In VX 4.7 a fully qualified domain name (eg vx.net.com) can be pinged. This allows the DNS configuration as well as the destination host to be tested.
Enhanced Port Statistics
VX currently supports the following call statistics elements:
- Current calls
- Total calls
- Connected calls
- Refused calls
- Errored calls
- Connected Time
- IVR Time
- Current IVR time
Call statistics requests can be made through the VX user interface command 'show statistics'. An external SNMP management tool can also be configured to make an SNMP request to VX for call statistics.
In Release 4.7, VX has be enhanced to differentiate the ingress and egress statistics per channel and per port level. This follows the typical VX channel "call leg" model.
The previous statistics followed a per call statistic which did not allow the user to tell is the call failed on the inbound or outbound channel.
VX must also records the port level statistics aggregated on a per hour basis. Per hour statistics are available for the last rolling 24 hours. 'Ingress/Egress' call statistics can be used by customers to extract 'Inbound/Outbound' call statistics. An Ingress channel is where a call arrives and gets routed by the VX and an Egress channel is the one which places the call to an external device.
108 Test Line
A 108-type test line is an ANSI standard dialable non inverting digital data loopback test line that accepts binary signals and loops back received octets, such that position of bits within the octets doesn't change in received and looped back transmitted octet. It is capable of passing 64 kbps of clear signal and should also be capable of supporting 64 kbps restricted and 56 kbps signals.
The this feature enables VX to terminate 108-type Test line calls and allows network administrators to verify the integrity of digital data transmitted between digital exchanges and/or PBX and VX over the physical T1/E1 interfaces. The 108-type test line must give the digital looped back test data path for the network maintenance point to verify the integrity of digital data using suitable digital signal generator and comparator functions. The test calls are configured by routing the call to a "test channel". VX does not ordinate ANSI 108 Test calls
SS7 COT Tone Detection
In SS7 networks, the audio and signaling medium are separated. This requires synchronization of the SS7 circuits with the corresponding bearer channels especially during maintenance, troubleshooting and management. This is accomplished by performing the continuity test as defined by the ITU and ANSI standards. The continuity tests can be performed as a stand-alone test using the CCR message followed by the exchange of the continuity tone or at the time of call initiation by setting the NCI bit in the IAM followed by the exchange of continuity tones.
The signaling procedures for the continuity tests remains mostly uniform in all standards except for the use of LPA in ANSI, but the continuity tone exchanges in the ANSI and ITU standards are different. There are two types on continuity tones - CO1 (2010 Hz) and CO2 (1780 Hz).
Continuity tone exchange in ANSI: The initiator of the continuity test sends a go-tone on the circuit under test to the far-end switch. The far-end switch responds with a return-tone. The go-tone must be different from the return-tone in ANSI. If the go-tone is a CO1, then the return-tone is CO2 and vice-versa.
Continuity tone exchange in ITU: The initiator of the continuity test sends a go-tone on the circuit under test to the far-end switch. The far-end switch responds with a return-tone. The go-tone must be same as the return-tone in ITU. CO1 is used.
The SS7 protocol can be specified in the SS7 Signaling point configuration. The continuity return tone and the timers used for the COT test can be specified in the ISUP channel profile.
Previously VX couldn't detect the go-tone because of hardware limitations on the STI card. Therefore for the ANSI continuity test, VX doesn't detect the go tone before sending the configured return tone. it will always send the return tone immediately. The STIX card is capable of detecting the incoming go-tone. VX must be enhanced to include incoming tone detection in the ANSI continuity test. By making the VX actually detect the incoming go-tone and then respond with the configured return tone we can ensure that the ANSI continuity test is performed properly. VX accepts incoming continuity check requests initiated by CCR or IAM messages.
Because SS7 circuits have the capability of both way operation, it is possible that the two exchanges will attempt to seize the same circuit at approximately the same time. A dual seizure, or glare, is detected by an exchange if it receives an Initial Address Message for a circuit for which it has sent an Initial Address message, but before it receives an Address Complete/Answer message.
This feature allows the VX to properly handle glare resolution for ISUP circuits.
Multi Level Precedence and Preemption
Multi Level Precedence and Preemption (MLPP) is composed of two parts; Precedence and Preemption
For MLPP, precedence is a synonym for priority. It defines the relative priority between calls in a calling domain, or community of interest. The precedence is set by the calling party, at the beginning of the call, on a per call basis. Precedence levels are not changed for the duration of the call, and any subsequent calls have a new precedence level, totally independent of any other call. The precedence values are:
- Flash Override
Flash Override is the highest priority, and no calls can ever be a higher priority than this. There is actually a 6th level, and that is a phone (or user) that has no precedence capability. This instrument places calls at what is known as a default level, and is non-preemptable.
In order to make a precedence call, a user will be using a phone instrument that either has special buttons for the 5 precedence levels listed above, or the user will dial a specific prefix pre-pended to the phone number. For example, for a phone instrument that is authorized to make a flash override call, the user may dial 90 + the called party number. The 90 is used to indicate this is Flash Override call. Likewise, 91, 92, 93, and 94 would be used to indicate Flash, Immediate, Priority, and Routine, respectively.
Preemption is the seizing of used resources in order to complete another call in a congestion situation. Preemption can take on one of two forms. First, the called party could be busy with a lower priority call, and can be preempted. Second, the network resources may be congested / busy with lower priority calls. In either case, one or more of the lower precedence calls must be preempted to allow the higher precedence call. There are four characteristics of preemption:
- Any party whose connection was terminated (whether that resource is reused or not) shall receive a distinctive preemption notification.
- Any called party of an active call that is being preempted by a higher precedence call shall be required to acknowledge the preemption by going on-hook, before being connected to the new calling party.
- When there are no idle resources, preemption of the lowest of these lower precedence resources shall occur
- A call can be preempted any time after the precedence level of the call has been established and before the call clearing has begun.
The requirement for preemption is that the lowest priority call gets preempted to satisfy the connection of a higher priority call. For example, if there are 6 calls up, 1 Flash, 1 Immediate call, and 4 Routine, when a new Flash call comes in, one of the Routine calls gets bumped. The decision on which Routine call gets preempted is left up to the vendor.
MLPP Implementation in VX
This feature introduces the concept of precedence to the VX platform. It supports detecting and forwarding of precedence information with full support for preemption on nearly every protocol supported in the system. (MLPP is not supported on CAS R2 or H.323. Support for MLPP on E1s will be introduced in R4.7.1, and is also present in 4.7.4.)
In VX 4.7 MLPP supports:
- Inbound call MLPP precedence selection – via configuration, inbound setup messaging, and the call routing table.
- Maximum precedence configuration – via configuration.
- Preemption of active calls
- Notification of preemption – including tones and signaling on TDM and IP channels.
- Inoperability between different channel types (including IP to TDM) and interworking between different namespaces.
- Enforcement of authentication for MLPP (on SIP only)
VX has the ability to divert an unanswered precedence call to a configurable number based on a configurable timeout value. This will be provided through a single global configuration parameter and implemented into all channels utilizing MLPP.
If a call is placed higher than ROUTINE precedence, then a timer will be started. Should the call not be answered before the timer expires, the outbound call will clear, and the channel will be rerouted to the global destination number.
Diversion is disabled by default and may be enabled by configuring the appropriate trunk group settings.
VX MLPP supports playing voice messages for protocols that cannot indicate out of band why the call was pre-empted. A configuration for the MLPP voice table has been added as a new table, similar to the tone table, to support playing voice announcements. These announcements will be subject to the same restrictions as voice prompts provided for the VX IVR system. For TDM channels they must be provided in G.711 and the appropriate law, and for VoIP channels they must be provided in all codecs that will be used by the phones involved. These voice prompts must be customized for the location and therefore they will not be provided by NET.
An equal or higher call is in progress
Blocked Precedence Announcement (BPA)
VX cannot place the precedence call because no channels are free and no channels were available at lower precedence for preemption.
Unauthorized Precedence level attempted
Unauthorized Precedence Level Announcement (UPA)
An inbound call attempted a higher precedence than the trunk group is configured to accept.
No such service or Vacant Code
Vacant Code Announcement (VCA)
The precedence caller attempted to reach a number for which no route could be found.
Operating or equipment problems encountered
Isolated Code Announcement (ICA)
Any case that would cause VX to clear the call with an error (or for CAS, to play reorder).
Busy station not equipped for preemption
Busy Not Equipped Announcement (BNEA)
VX receives a busy indication from a device that does not honor the MLPP preemption messaging (when the trunk group suggests MLPP should be enabled).
Loss of C2 Features
Loss of C2 Announcement (LOC2)
When VX routes a call from an MLPP enabled trunk to a non-MLPP enabled trunk, it must play this recording before placing the call.
IP to TDM MLPP Support
The MLPP enhancements on VX support:
- MLPP operation on a T1 / E1 CAS connections
- MLPP operation for FXS ports
- MLPP operation for ISDN PRI as defined by ANSI T1.619 and T1.619a
- MLPP operation for ISUP SS7 as defined by ANSI T1.619 and T1.619a
- MLPP operation for SIP based on Assured Services SIP (AS-SIP)
TDM CAS Implementation
- VX is able to originate, terminate, and "pass-thru" the MLPP flash and pedestal signaling required to process preemption notifications. These signaling mechanisms are used to notify switching equipment that a particular trunk line (DS0) is going to be involved in a preemption scenario.
- T1 and E1 ports of a VX node could be a "network" or "access" connection. This includes calls that originate or terminate via any source (POTS phone, FXS phone, IP phone). For any call that originates or terminates on VX, the system keeps track of that call and participates in MLPP call scenarios.
- VX provides an inter-working function for a node that has multiple interface types utilizing MLPP functionality. For example, a call that originates on a TDM T1/E1 and terminates on a PRI has full MLPP capability. Likewise, a call that originates on an FXS port and terminates on an IP phone has full MLPP capability.
- If the port is an access side connection, it would most likely be connected to a channel bank, or some other device that aggregates individual phones. In this configuration, the T1/E1 port would not necessarily be configured for MLPP operation, but VX is able to:
- Track users and calls connected to a T1/E1 port in order to participate in MLPP call scenarios.
- Recognize precedence dialing information
- Send PNT (Preempt Notification Tone) information
- Supply precedence ringing
- Provide the appropriate signaling to/from the network for calls that original/terminate on this T1/E1 port.
FXS Port Implementation
The FXS port features required for MLPP implementation are similar to those for port side T1/E1 connections. The MLPP functionality for FXS ports consists of:
- Tracking users and calls connected to each port and participate in MLPP call scenarios.
- Recognizing precedence dialing information
- Sending PNT (Preempt Notification Tone) information
- Supplying precedence ringing
- Providing the appropriate signaling to/from the network for calls that originate/terminates on each FXS port.
ISDN PRI as Defined by T1.619 / T1.619a
The ISDN features for MLPP implementation on VX are based on ANSI T1.619/T1.619a. ANSI TI.619 is only supported on T1 PRI's running NI-2 and 5ESS ISDN protocols.
- VX is able to originate, terminate, and "pass-thru" any ISDN calls.
- VX can participate in D-channel messaging as it relates to MLPP call scenarios.
- VX tracks users and calls connected to via the PRI and participate in MLPP call scenarios.
- VX will provides inter-working between an ISDN PRI and any other supported interface on VX and provide full MLPP capability. (i.e. TDM T1/E1, FXS ports, IP phones)
MLPP over IP Transport
In Release 4.7 VX has the capability for a call to traverse an IP network and support end-to-end MLPP over that IP network.
VX supports passing MLPP over IP using:
- VX supports MLPP precedence calling and preemption of calls and phones on a distant-end VX node over BSP. The VX BSP protocol provides bandwidth savings and efficiency.
MLPP supports any-to-any connection of calls across the BSP link, and will track and record precedence levels of calls across a connection between two VX nodes. BSP supports the appropriate MLPP features to participate in all MLPP calling scenarios.
- VX includes additional support for IP phones that includes precedence information in the call setup messages. Any device that supports AS-SIP will interoperate with the VX MLPP implementation.
- VX includes the ability to map precedence information for a particular call to DSCP and VLAN values. This can be done on a call by call basis, using the call routing system.
- VX can preempt any calls of lower priority from a full trunk-group in both the IP (BSP and SIP) and TDM domains.
G.729 Expanded Support
Many applications such as RF and satellite transport work better when the IP packets are sent in a regular interval. Typical RTP does not have a fixed interval due to silence frames. This unfixed interval can lead to packets being lost over certain transports. VX now provides a fixed interval RTP packet structure every 40ms which assures strict, integral 40ms support for G.729a/b codec which is RFC 5124 and G729-A/B compliant.
The following restrictions apply:
1.) Only one RTP packet will get generated within the 40ms interval
2.) An RTP packet (1 Packet) will not span across 40ms interval boundaries
VX currently supports periodic session refresh requests using re-INVITE method. Sessions can often be dropped during the establishment phase. For example if the IP connection is dropped while the call is ringing RE-INVITE cannot be used because the first transaction is not complete.
VX 4.7 is enhanced to support periodic session refresh requests using UPDATE method. The UPDATE message can be sent before the transaction is complete to refresh or update session parameters. This allows VX to clean up dead calls that are orphaned in the call setup state.
VX supports receiving UPDATE messages for changing codec and updating other parameters.
The UPDATE method has been added to the "allows" header to advertise that it is supported.
When VX receives a session from a device that does not have UPDATE in the "allows" it uses RE-INVITE for session refresh.
Time of Day Login Restrictions
VX 4.7 has been updated so that Time of Day Login restrictions can be applied to users. Once these restrictions are applied they can login to the system during the specified time and days. This is needed in order to make the security of VX more suitable for an operations center which may have multiple operators that are only granted access during business hours.
Time of Day login restrictions is not applicable to auditor users since they are exempt from login security.
TOD login restrictions are applied to users who log in to all interfaces of VX namely VXbuilder, CLI, FTP and VXwatch.
Time of Day (TOD) Login restrictions can be applied to any user by and administrator. An administrator is a user who has level 15 access permissions. The administrator can apply/modify TOD login restrictions for any user. A non-administrator is a user with access level permissions less than level 15. Such a user is notable to apply/modify TOD login restrictions.
Logon failure to VX due to TOD login restrictions, for a particular user, arecounted as a failed login attempt to VX and lockout rules will be applied.
If login restrictions of a user expire while he is logged in to VX, then the user's session will close at expiry time with a message. Background activities like calls, debugs and sniffs continue to be generated.
In order to connect to VX the user will have to login again at the specified time and day. An alarm will be generated for telnet session via CLI 5 minutes before actual session expiry to warn the user of the impending termination of session due to TOD login restrictions.
TOD login restrictions are not applicable to PPP BRI dial-up users.
V.150.1 Device Support
A large base of fax machines, modems, and telephony devices are in existence today that utilize ITU V-series modulations. As communication networks transition from circuit-switched technologies traditionally used on digital switching network (DSN) to Internet Protocol based solutions, the needs for seamless interoperability between V-series devices on the DSN and IP devices will continue to grow. The often-used method for transporting modem signals across the IP network with a G.711 stream is unsatisfactory given the large bandwidth consumed and susceptibility to modem retrains. ITU V.150.1 resolves these issues with its definition of a standard for modem relay.
With V.150.1 support in 4.7, VX can be positioned in network as a MoIP gateway, also interoperate with V.150.1 compliant FNBDTs. Bestflow can still be used with v.150 providing the highly regarded bandwidth saving capabilities of VX.
The picture below shows typical user cases with VX playing the role of the modem relay gateway.
VX supports two modes: Modem Relay Mode (MRM) and Pass Through Mode (PTM).
In MRM, VX sites between DSN and IP network playing role of Universal Modem Relay (U-MR) gateway. The IP side protocols supported in this mode are BSP/VTP and SIP/RTP/SPRT. SPRT is Simple Packet Relay Transport protocol.
In PTM, VX sites in IP network playing proxy like role. The pass through applies between any combination BSP/VTP and SIP/RTP/SPRT. In this mode, VX can also, via SIP/RTP/SPRT, talk to V.150.1 compliant IP equipment.
VX provides following functions for a v.150 Universal modem relay:
- Support V.8, V.34, V.32 and V.32bis on TDM side
- Support SSE/SPRT on IP side
- Support ITU-T V.150.1 Audio and Modem Relay Operational Modes
- Support Universal Modem Relay (U-MR) gateway type only
- V.150.1 capability negotiation in call setup over BSP and SIP
- Support SSE/SPRT in VTP and V.150.1 protocol information in BSP
- V.150.1 interworking between BSP and SIP calls.
- Be capable of configuring related parameters and showing V.150.1 media related information.
- Interworking has been tested with following devices:
SIP Commercial Version
SIP Specialized Version
All TDM protocols have been tested against V.150.1 support except R2.
A VX node needs to be equipped with V.150.1 license in order to perform V.150.1 functions.
VX line cards will only support one of the following functions per card - V.150.1, MSRTA, or SCIP Relay.
VX supports a maximum of 48, v.150 V.34 calls per STIX card
Active Directory Support for Call Routing
This feature allows VX to query Active Directory to establish a call-route. This has the benefit of expanding the support for Active Directory and Microsoft Unified Communications in VX 4.4.4.
This feature provides the ability to have simple call routes for simpler routing to having a slightly more complex nested call routes for a more complex routing.
In previous releases VX did not support variable length digits, all digits were generated and received with a length of 160ms.
In Release 4.7 VX now supports variable length for send and receiving RFC2833 digits and vtp digits. This allows greater interoperability on digit generation and reception.
Configurable Login Parameters
When VX is deployed secure networks, strong passwords and login restrictions are required. In other networks, strong passwords may not be required. In VX 4.7 the password complexity and user authentication can be controlled, and allows full control of how long the user is logged in for, login tries and other user authentication parameters.