Transport Layer Security Protocol (TLS) is now supported for Session Initiation Protocol (SIP) in VX. TLS is the industry standard designed to protect the privacy of information tranported over the Internet. TLS assumes that a connection-oriented transport, typically TCP is in use. VX's SIP User Agent and Server use TLS to exchange certificates. After a TLS connection is established, encrypted SIP message are exchanged. This capability adds security to SIP signalling.
The SIP TLS feature enhancement are included:
This feature provides Transport Layer Security (TLS) protocol support for Session Initiation Protocol (SIP) signaling in VX. TLS is an industry standard designed to protect the privacy of information communicated over the Internet. TLS assumes that a connection-oriented transport, typically TCP is in use. Therefore, scenarios that apply to SIP TCP generally apply to SIP TLS.
The VX SIP User Agent and Server use TLS to exchange certificates. After a TLS connection is established, it is used to exchange encrypted SIP messages. The TLS protocol allows client/server applications to detect the following security risks:
The VX command line interface is used to request, generate, view and delete certificates in the local certificate store. VXBuilder is used to specify which certificate for VX to use in the Edit System Setting dialog box.
Certificates on a VX node are used to validate/authorize itself and/or the other side in Transparent LAN service or in VXbuilder connection to the VX node.
Using VX, you can generate a self-signed certificate and create a certificate request to be signed by a Certificate Authority. Certificates can also be imported into a VX node as long as they are in Base-64 encoded X.509 format (.cer) or PKCS #7 certificate format (.p7b) VX currently exports in Base-64 encoded format (.cer) only.
In both cases the user is asked to supply the information required to complete the request.
See the VX Command Reference manual for more information these commands.
To allow connections with an untrusted root that is self-signed certificates, use the CLI command allow-untrusted-root. To allow connections with an untrusted root using VXbuilder, open the General Settings dialog box and select the Allow untrusted root certificate option.
To use certificates, in the Trunk Group configuration dialog box enable TLS or MTLS which changes the SIP transport type which in turn uses certificates to validate connections.
To validate the other side of the connection using certificates, in the Trunk Group Configuration dialog box enable remote certificate name check. Enabling Allow SIP URI in TLS allows SIP connection s with "sip" in URI.
In order to monitor call quality, VX maintains Link Quality Management (LQM) statistics for it's peer nodes. Using SNMP, the network administrator is able to find the peer table on a VX node and LQM statistics for peers on VX. This information may be used to generate comprehensive call quality information.
To enhance network management by alerting the network administrator about call route availability whenever a call route overflows a trap is sent out to the Trap Manager. When the call route becomes available another trap is sent to the Trap Manager indicating that the overflow has cleared.
VX now supports SSH connections in addition to the telnet connections for accessing the VX CLI. VX acts as a SSH server and accepts connections of secure SSH clients. This feature adds additional security to VX, protecting sensitive data.
Channel Associated Signaling (CAS), is a commonly used system for call control in TDM networks. In addition to support for CAS E&M, loop start, and R2 Signalling, VX now supports CAS R1 Signaling. This feature enables VX to directly integrate with the adjacent switches using signaling system R1 and enlarges the scope of the inter-protocol switching capability on VX.
VX can now relay Message Waiting Indication (MWI) from a Unified Messaging Server (UMS) to a PBX over NI2. The outgoing MWI relayed by VX using NI2 allows the PBX to turn on the MWI led/signal on the phone(s) connected to it. This implementation is based on recommendation for MWI Notification in RFC 3842 for SIP and Telcordia SR 4994 for NI2.
The Serial over IP feature provides support for transporting data from serial interface over an IP network. Data received on serial interfaces is encapsulated into IP packets and sent over the IP network. IP packets destined for serial interfaces are stripped of their headers and the payload is transmitted over the destination serial interface. This support is based on the IETF draft, Structure Agnostic TDM over Packet (SAToP). SAToP disregards any structure that may be present in the serial stream of data.
When using high speeds on a serial port, the CPU utilization may exceed 40%. To reduce CPU utilization, packet size configuration on the Serial over IP port may be increased.
To support this feature a two new serial interface cards have been provided for use in the VX900 node: four-port and a one-port.
The one-port serial card can run in DTE mode only and does not support terminal timing.
Serial IP is supported for unstructured data and structured (HDLC) frames. Various port speeds are available and both DCE and DTE modes can be used. Serial ports can be configured to any mode (IP over Serial, Serial over IP) and each port can be configured independent of the mode of the other ports on the card. V.35, EIA-449 and EIA-530 serial interfaces are supported. Jitter buffers are used in the egress direction of serial ports to provide jitter tolerance for unstructured SoIP.
Rates supported on the serial ports in slave mode are autorated from 300 bits per second to 8.192 Megabits per second. This means that in slave mode, the received clock frequency can be anywhere in that rate.
This results in the following speeds:
Terminal timing (TT) is provided to prevent the phase shifting of data with respect to the clock when running the line at high speeds and long distances.
If a port on a serial card is the primary clock master, and no secondary clock source is configured, if the primary clock fails, the internal oscillator on the serial card feeds the CT*Bus.
If a port on the serial card is the secondary clock master and both primary as well as secondary clocks sources fail, the the internal oscillator on the serial card feeds the CT*Bus.
Automatic switchover does not happen from the less preferred clock source to the more preferred clock source upon its availability (that is from secondary to primary).
Ports can be configured for DTE or DCE for each of the following modes:
Cable types include V.35, EIA-RS449, and EIA-RS530.
For V.35, the serial port can be configured for a maximum speed of 2.048 Mbps.
This feature adds the functionality on VX to relay the call forward information from NI2 to SIP. In NI2 it is possible to send the following types of Call forward reasons:
The call forward information about the redirecting number is typically used in the voice mail scenarios. This feature enables VX to convey the NI2 Redirect number and the call forward reason to a Voice mail server using SIP. This feature also enables conveying this information from SIP to other protocols also. The Voice mail server may in turn use this information to play a customized prompt to guide the caller in leaving a message. It is possible to call forward information from SIP to NI2 also.
The implementation is based on recommendations for diversion header in SIP as specified in draft-levy-sip-diversion-08.txt and as specified in Telcordia SR 4994 for NI2.
The new Network Logging feature provides the ability to send log entries generated by a VX node to a remote system. The remote system requires an installed syslog server to receive the log entries. This feature provides the capability of specifying the location of the syslog server by configuring the remote system's DNS name or IP address.
This feature can be enabled and disabled as needed using the Logging branch of VXbuilder application directory tree. A syslog facility and a syslog severity are associated with each log entry. The syslog facilities include:
Eight syslog severity levels are supported including:
Sixteen debug levels are also supported.
This feature adds Smart Card Authentication for VX login. With this feature any user with a Smart Card can log in to their workstation and be granted access to any VX node throughout the Domain or Active Directory.
Smart Card login is accomplished within a Windows network by exchanging cryptographic certificates with the client. This feature implements the Windows network certification operations to authenticate user access to VXbuilder and VXwatch applications. The VX administrator implements this feature using the CLI to manage domain membership. Domain management does not affect VX node configuration.
COT tests provide a way to synchronize SS7 circuits with the corresponding bearer channels between two adjacent switches. This feature supports the incoming continuity test on the VX ISUP circuit, initiated by the far end switch using IAM message or CCR. The continuity test conform to the ITU and ANSI standards. The ability to disable echo cancellation for the ISUP to SIP/H323 calls to support V.90 modems over VOIP links is also provided.
The ISUP COT test can be configured using the ISUP channel profile tables in the VXbuilder application or using the CLI to configure the channel profile.
When using ANSI, VX responds with the configured return-tone, without respect if the go-tone received from the far-end. For the continuity test to be successful, this value must be properly configured.
VX uses only the ISUP COT timer values from the first SS7 channel profile. A warning is issued if the ISUP COT timers, configured for the additional SS7 channel profiles, have different values than the one configured in the first SS7 channel profile.
This feature disables the Echo Canceller during the use of V.90 modems over VoIP links. This allows for better data exchange at higher bit rates. Peer VX nodes detect the tone and disable Echo Canceller independently.
To configure this feature, select the "Transparent" CODEC in the media class that is used.
VX now supports the message and information elements, and script extensions required for redirecting number manipulation.
When a call comes in, based on the called party number, a database query is performed using VXscript to check if the number has been ported before the call is routed. If yes, the redirecting number in the incoming setup message is updated by the new number and its attributes. If no, the call is routed as normal.
The redirecting number is transported over BSP and BSP channels are used for inter-node communication when inbound and outbound channels are in different nodes. See LINK for information about the variables used to perform this function.
This feature allows a configured list of subscribers to be registered with a SIP Registrar and supports Digest authentication. The Digest authentication is provided for the outgoing REGISTER requests and outgoing INVITE requests.
VX supports the origination and termination of SIP calls. VX also acts as a Registrar, by accepting registrations and using them to resolve destinations. VX also operates with third-party SIP proxy server for routing purposes. VX's SIP stack supports the additional headers in the SIP message (like Record route) to work with a proxy.
With this new feature VX now is capable of the following:
This feature adds the ability to dynamically reconfigure more VX configuration items without the need for a system reset for the items to take affect. The parameters that can now be dynamically reconfigured include the following:
This feature provides a list of modified parameters that require a system restart and also adds enhanced information messages that are provided to the user when a restart is needed. These new message prompts list the parameters that have been reconfigured that require that the system be restarted.
With the ISDN protocol, the called party number is normally presented in the setup message, as is the case for the AT&T 4ESS/5ESS, DMS-100, I-2, and NTT ISDN protocols. Alternatively, ETSI and QSIG ISDN protocols may employ the setup message, and subsequent information messages, to deliver the called party digits. This delivery method, called Overlap Sending, is newly supported in VX version 3.8.
The VX FTP user feature provides essential access to VX's file system thereby removing the need for access by way of the system administrator account. The primary FTP user is configured during the system setup script execution. Additional FTP users can be configured and maintained by way of the command line interface (CLI).
The STU-III protocol, one of the secure voice protocols supported in VX, contains a modem sequence that negotiates the secure voice data rate or mode. The STU specification states that Msg B shall begin 1 second after Message A. This is not possible when relaying STU with more than l second delay. This feature resolves the issue by "spoofing" or "faking" a Msg B response to the originator at the same time as sending an altered Msg B to the relay peer, effectively compensating for the 1 second limit.
The options for configuring this feature can be found in the Edit Media dialog box in the VXbuilder application. In the Secure Voice section of the dialog, select the "Secure Relay" CODEC option which allows for selection on a per call route basis. The EEC size, formerly configured in the System Config dialog box, is now located in the Secure Voice section of the Edit Media dialog box.