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:
- VX as a Registrar - This allows the network elements to securely register the subscribers with VX using SIP-TLS.
- VX as a Registrant - Extends the ability of VX to securely register the subscribers in the subscriber table using SIP-TLS
- Support Proxy-like mode - Enhances VX to use TLS in proxy like mode as and thus allows the secure relay of the SIP calls, when both the call legs use TLS. Additionally it allows VX to use all permutations of transports (UDP, TCP and TLS) for SIP to relay the SIP calls in the proxy like mode.
SIP Over TLS
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:
- Message tampering
- Message interception
- Message forgery
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.
- To generate a self-signed certificate, use the CLI generate certificate self-sign command.
- To generate a certificate request to be signed by a Certificate Authority, use the CLI generate certificate request command.
In both cases the user is asked to supply the information required to complete the request.
- To view certificate information associated with a particular node, use the show certificates command.
- To delete a certificate, use the delete certificate command.
- To import a certificate, use the import certificatecommand. This command reads from a file and stores the certificate from the file to the designated store. Available store names are my and root. The default is my.
- To export a certificate use the export certificate command. This command writes a certificate in the system to a file. Available store names are my and root. The default is my.
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.
LQM Statistics to SNMP
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.
Route Overflow Traps
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.
CAS R1 Signaling Support
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.
MWI Using NI2
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.
Serial over IP Support with Serial Card
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.
Allowed DTE Speeds
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.
- DCE Speeds Using CT*Bus or Internal Oscillator--When the DCE port derive their clock from the CT*Bus or internal oscillator the following speeds are supported:
- n x 2400 /(1+7*m), where 1< n < 18, 0< m< 1.
- n x 64000 / (1+7*m), where 1< n < 128, 0< m< 1
This results in the following speeds:
- 300, 600, 1200, 2400, 4800, 7200, 9600, 12000, 14400, 16800, 19200, 21600, 24000, 26400, 28800, 31200, 33600, 36000, 38400, 40800, 43200
- 8k, 16k, 24k, 32k, 40k, 48k, 56k, 64k, 128k, 192k, 256k, 320k, 384k, 448k, 512k, 576k, 640k, 704k, 768k, 832k, 896k, 960k, 1024k, 1088k, 1152k, 1216k, 1280k, 1344k, 1408k, 1472k, 1536k, 1600k, 1664k, 1728k, 1792k, 1856k, 1920k, 1984k, 2048k, 2112k, 2176k, 2240k, 2304k, 2368k, 2432k, 2496k, 2560k, 2624k, 2688k, 2752k, 2816k, 2880k, 2944k, 3008k, 3072k, 3136k, 3200k, 3264k, 3328k, 3392k, 3456k, 3520k, 3584k, 3648k, 3712k, 3776k, 3840k, 3904k, 3968k, 4032k, 4096k, 4160k, 4224k, 4288k, 4352k, 4416k, 4480k, 4544k, 4608k, 4672k, 4736k, 4800k, 4864k, 4928k, 4992k, 5056k, 5120k, 5184k, 5248k, 5312k, 5376k, 5440k, 5504k, 5568k, 5632k, 5696k, 5760k, 5824k, 5888k, 5952k, 6016k, 6080k, 6144k, 6208k, 6272k, 6336k, 6400k, 6464k, 6528k, 6592k, 6656k, 6720k, 6784k, 6848k, 6912k, 6976k, 7040k, 7104k, 7168k, 7232k, 7296k, 7360k, 7424k, 7488k, 7552k, 7616k, 7680k, 7744k, 7808k, 7872k, 7936k, 8000k, 8064k, 8128k, 8192k
- Allowed DTE Speeds when driving the H.100 Bus --When the card is in Master mode, when one of the serial ports is used to drive either of the CT*Bus clocks, the received clock must be one of the following frequencies:
- 38400, 57600, 64k, 128k, 256k, 512k, 1024k, 2048k, 4096k, 8192k
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.
- DCE-TT: Incoming data is clocked using TT and outgoing data is clocked using local clocks. In this mode it is assumed the clocks are of the same frequency.
- DTC-TT: Send Timing (ST) s used to generate the TT.
Automatic Clock Switchover
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:
- IP over Serial
- Serial over IP
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.
Redirecting Number and Reason Information
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:
- Call forward busy
- Call forward no reply
- Call forward out of order
- Call forward deflected
- Call forward unconditional
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:
- KERNEL for kernel messages
- USER for random user-level messages
- MAIL for mail system messages,
- DAEMON for system daemon messages
- AUTH for security/authorization messages
- SYSLOG for messaged generate internally by syslog
- LPR for line printer subsystem messages
- NEWS for network news subsystem messages
- UUCP for UUCP subsystem messages
- CRON for clock daemon messages
- AUTHPRIV for private security/authorization messages
- FTP for FTP daemon messages
- LOCAL0-LOCAL7 provide support for the operator to select a facility
Eight syslog severity levels are supported including:
- 0 for Emergency messages, the system is unusable
- 1 for Alert, an action must be taken immediately
- 2 for Critical, there is a critical condition
- 3 for Error, an error has occurred
- 4 for Warning, a warning condition exists
- 5 for Notice, there is a normal but significant condition
- 6 for Informational messages
- 7 for Debug level messages
Sixteen debug levels are also supported.
Smart Card Login
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.
Disabling Echo Canceller for V.90 Modems
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.
Redirecting Number Manipulation
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.
Registrant, SIP Digest Support
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:
- Sending registration requests on behalf of a list of subscribers. When VX is configured with a list of subscribers, on boot up these subscribers are registered with a Registrar. The Registrations are performed one after the other in order not to flood the network with simultaneous registration requests. If a Register fails due to a user name or password error only that subscriber is marked as unregistered and the next subscriber's registration proceeds. If subscribers are added or removed from the VX configuration, the reconfiguration triggers the registration process again.
- Calling number translations for outgoing SIP calls. Based on the subscriber list, the calling number field in the outbound SIP call and the internal address are translated into an external address. The calling number translation table should not be specified in the configuration, when a Subscriber list is used for this purpose.
- Calling Name (Display name in the From header) translation for outgoing SIP calls. Based on the Calling name translation table, translation are provided based on the internal address by looking up a Calling Name translation table.
- Called number translations for incoming SIP calls. Based on a subscriber list, the called number field in the inbound SIP call the external address is translated into an internal address.
- Respond to Digest challenges based on authentication information in the subscriber list. The outbound SIP request (REGISTER and INVITE) may be challenged by the Registrar or Proxy to provide the user name and password for authentication. The SIP RFC mandates the use of Digest authentication using MD5 algorithm. When an outbound request is challenged, VX calculates the challenge response based on the user name, password and other parameters specified in the challenge. The subscriber's user name and password are retrieved from the Subscriber list.
VX Dynamic Reconfiguration
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:
- Jitter Optimization and Jitter Minimum Delay
- IVR Scripts
- VTP Frame Packing
- Removing Virtual channels on a port
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.
VX FTP User
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).
STU-III Protocol Support
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.