Skip to end of metadata
Go to start of metadata

Looking for the JITC release?

For the JITC certified release build, please see VX 4.7.4 v17 Release Notes

Table of Contents

About this Page

This document describes the release notes for the Voice Exchange (VX) Release 4.7.4, hardware modules, software features and bug-fixes.

This document also describes the known issues and limitations of the product. For details about supported features, please refer to the Key Featuresand the VX Release Information page.

Please contact your NET sales representative to receive further information about the VX family of products (jointly referred to as VX in the rest of the document)

Release Notes generated on December 9, 2010
  • Release Number: 09
  • Part Number: 036430-474A (PDF)

Product Background

NET's VX Series products are the industry's first fully integrated multi-service voice switch series with Any-to-Any gateway functionality, creating a next-generation solution for Government entities deploying VoIP with MLPP, V.150.1 / SCIP Relay, legacy PBX, and satellite / limited bandwidth requirements. With NET's 20+ years of experience in designing and building multi-service network exchange solutions, the VX SERIES Voice Session Border Control and Universal Voice Exchange is the clear choice for any military environment looking to obtain the benefits of VoIP through a versatile, integrated voice exchange solution that provides interoperability with all existing government or military systems

When running release 4.7.4, the VX Series of products are JITC certified as a Tactical Network Element with MLPP support

The VX series has the following platforms and management applications.

VX900 / SHOUT900 / VX900T

VX900 is a chassis in the VX product line. The VX900 is a 1U, 2 slot, PCI based system with 2 Ethernet 10/100 interfaces, and AC power. An optional BRI or Serial interface can also be employed using a front panel connection. The VX900T is a ruggedized version of the VX900.

VX400

VX400 is a small compact ruggedized 1U chassis. It can be configured with up to 4 FXS ports. The VX400's are fixed configuration systems. They ship with their final configuration.

VX1200

VX1200 is a chassis in the VX product line. The VX1200 is a 1U, 2 slot system with 6 Ethernet 10/100 interfaces, and AC power.

VX1800

VX1800 is the largest chassis in the VX product line. The VX1800 is a 3U, 6 slot system with 2 Ethernet 10/100/1000 interfaces and Redundant AC power supplies.

VXwatch

VXwatch is a management tool for real-time monitoring of VX alarms. VXwatch displays status and alarms for all channels and spans. Call details can also be viewed in real time. VXwatch operates on a Microsoft Windows operating system and is be used to monitor any VX node in the network. Multiple nodes can be monitored in the same window or in separate windows depending on user preference. Port and card status is reported graphically and channels are color coded to indicate their state. In addition, information on call parameters may be obtained by clicking on the active call and information on circuit parameters may be obtained by clicking on the interface. Multiple nodes are supported

VXbuilder

VXbuilder presents an intuitive, structured, configuration and provisioning interface to the network installer and provides a single configuration utility for all aspects of system operation. VXbuilder supports remote provisioning through a forms-based, point-and-click GUI that can be used to configure all node parameters and tables, including IP Interfaces, PSTN, calling routes and signaling manipulation.

VXgate

VXgate is an integral part of the VX's resilient, distributed, and bandwidth-efficient architecture. VXgate provides a gateway between the VX network and external billing systems or clearing houses, and collects call detail records (CDR) from those systems.

Scope of Document

This document describes any new hardware modules, software features and bug-fixes for release 4.7.4. Please refer to the customer documentation of the VX release 4.7 for complete details about the features supported.

 Please contact your NET Federal sales representative to receive further information about the VX family of products (jointly referred to as VX in the rest of the document

Release Contents

Hardware

Supported Hardware Modules

VX release 4.7.4 supports the following hardware:

  • VX Chassis
    • VX900AD / SHOUT900AD – Also known as the VX900AB
    • VX900T
    • VX400
    • VX1200
    • VX1800
  • VX900 / VX1800 Cards
    • STIX-1T1E1/DSP – 1 port E1/T1
    • STIX-2T1E1/DSP – 2 port E1/T1
    • STIX-4T1E1/DSP – 4 port E1/T1
    • SSI-4-SS7             – 4 port SS7
    • STIX-8FXS/DSP – 8 port FXS
    • SIPFISBRIB        - 1 port BRI WAN
    • SH-PCI-4SER-A  - 4 port Sync Serial interface
  • VX1200 Supported hardware configurations
    • VX1200-1T1/E1   – Chassis with 1 port E1/T1
    • VX1200-2T1/E1   – Chassis with 2 port E1/T1
    • VX1200-4T1/E1   – Chassis with 4 port E1/T1
    • VX1200-6T1/E1   – Chassis with 6 port E1/T1
    • VX1200-8T1/E1   – Chassis with 8 port E1/T1
    • VX1200-SDD       – Chassis 30 SIP calls licensed
  • VX1800 Supported hardware configurations
    • VX1800-4T1/E1   – Chassis with 4 port E1/T1
    • VX1800-8T1/E1   – Chassis with 8 port E1/T1
    • VX1800-12T1/E1 – Chassis with 12 port E1/T1
    • VX1800-16T1/E1 – Chassis with 16 port E1/T1
    • VX1800-20T1/E1 – Chassis with 20 port E1/T1
    • VX1800-24T1/E1 – Chassis with 24 port E1/T1
    • VX1800-SDD       – Chassis 360 SIP calls licensed

Previously supported hardware modules are still supported by their respective releases.

Software

VX release 4.7.4 is a patch release. The following list will reflect the software features introduced in R4.7, 4.7.1, 4.7.2. NOTE: R4.7.4 only introduced bug fixes and no new features.

Features in Release 4.7

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.

Glare Resolution

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

Precedence

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:

  1. Flash Override
  2. Flash
  3. Immediate
  4. Priority
  5. Routine

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

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:

  1. Any party whose connection was terminated (whether that resource is reused or not) shall receive a distinctive preemption notification.
  2. 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.
  3. When there are no idle resources, preemption of the lowest of these lower precedence resources shall occur
  4. 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)

Diversion

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.

Voice Prompts

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.

Announcement Condition

Announcement

Condition

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

  1. 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.
  2. 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.
  3. 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.
  4. 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

SIP UPDATE

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:

Device

Version

STE

2.6

OMNI

5.07

Sectera

11.01

GD vIPer

SIP Commercial Version

GD vIPer

SIP Specialized Version

Qsec2700

3.0

LGS Microcell

N/A

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.

Digit Improvement

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.

Features in Release 4.7.1

Extended Microsoft UC Features (VXe)

VX 4.7.1 enhances VX to support Microsoft's Office communication server SIP directly. In order to support direct connection the following enhancements have been made to VX.

  • Microsoft RT-Audio codec
  • Polycom G.722.1 @16K (SIREN) codec
  • Interactive Connectivity Establishment (ICE) draft 6
  • Forward error correction via Redundant RTP (RFC2198)
  • Scalable Secure RTP
  • Microsoft Quality of Experience server integration
  • Direct configuration into Office communications environment
  • Microsoft Media Relay Authentication service
  • Dynamic codec selection and network detection

Prior to these features the mediation server role is used to convert these advanced pieces of the Microsoft Office Communication server network to base SIP. 

With these enhancements VX can now talk directly to the Microsoft Office Communications Server front-end role. The audio path is directly from VX to Microsoft Office Communicator or the required end-point. This removes the need for the mediation server role in the network.

The VX 4.7.1 implementation of the Extended UC features has minor limitations that will be removed in subsequent releases. Please refer to section 3.4 for limitation details.

Redundant Audio Date in RTP Payload

This feature adds support for Redundant Audio Data in RTP payload (RFC 2198) which is negotiated using SDP for a SIP call.

Media Port Change Restriction

This feature allows the user to configure the RTP port range, which is used in SIP and H323 call. The permissible range is 16384-32767 and the first port must be an even number. An alarm is generated when a free port is not available for new call.

MRAS Support

This feature supports a PSTN call traversing through VX and destined to a client sitting outside the Enterprise Network. In this case, the audio stream through VX traverses through the TURN/STUN server. This feature provides the authentication credentials which VX uses to traverse through the TURN/STUN server. VX enables interaction with an A/V Edge Authentication Server, also known as a Media Relay Authentication Server (MRAS).

Multiple MLine SDP

This feature provides a way to transport multipart body contents in one and same SIP message.

RT Audio

The RT Audio codec support feature includes support for the SIP and BSP signaling and its negotiation in VX, including the hardware compression and decompression on the STIX card.

RFC3960 Support for SIP to SIP Calls

This feature supports RFC3960 for local ringing tone generation for SIP to SIP calls.

QoE Server Support

This feature enables VX to interact with the QoE server to report call metrics and statistics. The report is sent as an XML report embedded in a SIP SERVICE message body.

TURN Client Support

This feature enables VX to setup keyholes for the audio stream through the TURN server in order to relay its media stream through the TURN server.

SSRTP

This feature provides confidentiality, message authentication and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP); and improves performance when the same RTP payload is distributed to hundreds of recipients.

New CAS Modes and Permanent Circuits

VX 4.7.1 is enhanced to support an own number on each CAS channel. The own number will be used for the calling number for any calls from the channel.

VX is also enhanced to support different CAS types on each timeslot. This allows mixing of MRD, E&M and other CAS protocols.

This feature includes CAS Tunnel and CAS MRD Protocol.

  • CAS Tunnel implementation allows tunneling of signaling and voice from CAS lines in a VX node to CAS lines in another VX node. Thus there is a permanently open duplex path between the trunks in both the nodes.
  • CAS Manual Ring Down protocol (CAS MRD) protocol interworks with SIP. This enables VX to act as a gateway between a SIP PBX and a TDM PBX running the MRD protocol. Once the call is established, VX maintains the call in a connected state unless the call has been disconnected from the SIP PBX.

Support for VX behind a NAT

When a user on the internal network initiates a request to the Internet, their private IP address is translated to the public IP address when the request goes through the firewall/Network Address Translation (NAT) to the Internet. This is so the destination site knows the IP address to which it should return the information. The firewall/NAT maintains a log of which endpoints requested what destinations, and when a response is received from a destination site, the firewall/NAT directs it to the endpoint that made the original request.

When the VX is on a private network and needs to establish a call to a SIP UA in the public network, the call goes through a NAT server. The NAT translates the IP address in the IP header, but generally, it is not able to translate the IP Address in the SIP and SDP Headers.

This feature enables VX's signaling and audio stream NAT traversal assuming that the VX is placed behind a NAT on the Private Network side. The VX uses the Public IP of the NAT behind which it is placed, in all SIP and SDP messages for making SIP calls to/receiving SIP calls from devices on the public internet.

One number fax

The issue with a single number solution including fax is the user experience.  The fax experience has always been the same:  place fax into machine, dial number and press GO.  In a single number solution, both phone and fax calls reach an end-user's phone; they both end up ringing the number's owner.  If the call is a fax, the user must then hang up and wait for the fax to retry.  During the retry, the phone must not be answered so that the fax can be delivered to the recipient's UM mailbox.  When the phone rings again, the recipient cannot know whether it is the fax retrying or a real person-to-person call.  The fax will continue to retry the recipient until the phone is ring-no answer, or until the recipient manually forwards the call to his UM mailbox.  The single number fax experience is confusing for both sender and recipient.

In VX 4.7.1 this enhancement provides a true single number Unified Messaging solution for voice, voicemail and fax. The One Number Fax feature enhances VX to re-route a call when a fax tone is detected. This allows the call to be re-routed from OCS to the UM server so the fax can be delivered.

The One Number Fax feature enhances VX to re-route a call when a fax tone is detected. This allows the call to be re-routed from OCS to the UM server so the fax can be delivered.

VLAN for UDP

This feature is an enhancement of the handling of UDP packets. Configuration changes include the two tables for DiffServ Mapping and 802.1p Priority are replaced with one combined table called Packet Priority Table. This table allows for up to eight (8) pre-set combinations of 802.1p and DiffServ, to be used for all inbound and outbound traffic.

RFC3960 Support for SIP to SIP Calls

RFC3960 is a technique to generate ringback for SIP calls. SIP does not have a standard way of determining inband vs. local ringback. This is further complicated with a call is forked. Forked calls can have mixed local and inband ringback. RFC3960 removes this ambiguity by monitoring the RTP stream. Local ringback is played after a 180 is received and no RTP stream exists. As soon as RTP is detected the local ringback is stopped and the audio is cut through. VX has supported RFC3960 since release 4.4.4 for ISDN to SIP calls.

SIP to SIP calls did not support RFC3960; this can cause no ringback with certain IP-PBX's. While it is always possible to configure around this and provide ringback this was often as the expense of inband ringback.

4.7.1 Implements full RFC3960 ringback generation for SIP to SIP calls.

E1 MLPP

Multi Level Precedence and Preemption support allows government, especially military, users to be able to classify the priority of a call so that a high priority call can override lesser priority calls in the event of congestion of low resources. For example, an emergency call can override a conversational call when all lines are full.

MLPP provides a documented and standardized way to coordinate this system, and interoperate with other equipment that also provides MLPP functionality.

VX 4.7.1 adds E1 MLPP to allow VX to support MLPP on both T1 and E1 circuits.

VLAN and Diffserv configuration changes

VX System Release 4.7.1 introduces enhancements to the configuration of Virtual Local Area Network (VLAN) and Diffserv priorities. The new priority table greatly simplifies the configuration of VLAN and Diffserv on the system.

Enhancement to the Timer System

This feature is an enhancement to change the system time from the CLI and also helps change the system time by the time server. This feature is used every time the system time is changed either from the time server or manually from the CLI.

Features in Release 4.7.2

Extended UC features (VXe) enhancements

VX 4.7.1 introduced the Extended UC features that allowed VX to talk communicate directly to Microsoft Office Communication server 2007 R2 without the need for the mediation server role. VX 4.7.1 behaved differently for some deployments compared to the mediation server. VX 4.7.2 closer matches the behavior of the mediation server.

Conference Caller-id

In VX 4.7.1 the Calling name of the PSTN dial-in user would be displayed in communicator for a conference call. If no calling name was possible the VX FQDN would be displayed. This was not the same the mediation server which would provide the calling number in this case.

VX 4.7.2 enhances the VX to now provide the caller-id (calling number) for incoming PSTN calls to a conference bridge that don't have a calling name. 

After upgrading the VX to 4.7.2 the VX needs to be re-inserted into AD for the conference caller-id to show up correctly.

Communicator Mobile "Call via Work"

Microsoft Communicator mobile has the function to call users from their cell phone using their Communicator "work" number. This function did not behave correctly with VX 4.7.1 using Extended UX features. VX 4.7.2 resolves this issue and Call via work in Communicator mobile works as desired.

The feature is implemented using the Delayed Media feature. The VX can accept secure INVITE without an offer SDP. VX will then make an offer SDP in reliable provisional response or if provisional response is not reliable then offer SDP will be made in the final response for INVITE message, which is 200 OK. This feature is supported when a Trunk Group is configured for Pass-through SRTP only or Terminate SRTP only.

Microsoft Communications Server 2010 Extended Gateway

VX 4.7.2 supports the upcoming Microsoft Communications Server 2010 version. VX 4.7.2 transforms VX into an extended gateway.

In order to use Microsoft Communications Server 2010 with VX the "Extended Gateway" license is required.

Microsoft Communications Server 2010 Setup Wizard

Microsoft Communication Server 2010 has slightly different settings from previous Communications server releases (TLS vs. TCP and others). To ensure smooth easy installations, VX 4.7.2 includes a new configuration wizard for Communication Server 2010 that will configure the correct ports, protocols and routing settings.

Full SIP Header pass-through

In previous releases VX supported passing through the configured headers for INVITE, 180 and 183 messages. This is supported only when the trunk group is configured in Proxy-Like mode.

In VX 4.7.2, VX has been enhanced to support passing through of headers for non-INVITE requests like BYE, CANCEL and INFO and for final responses. This functionality is independent of Proxy-Like mode. All unknown headers can be passed through. This allows supplemental features to be passed through VX when it is running as an SIP to SIP mediation device.

System Level Details

Software Version Numbers

Component

Part No.

Version

VX

036429-474SW

4.7.4v9

VXwatch

036431-474SW

4.7.4v9

VXbuilder

036438-474SW

4.7.4v9

VXgate

036439-472SW

4.7.2

VX script compiler

036727-471SW

4.7.1

Backward Compatibility

VX 4.7.4 is not tested to be backwards compatible with previous VX software releases. NET recommends upgrading all nodes in the network to 4.7.4

Compatibility of VX release 4.7.4 on the node with older versions of other versions of network components such as VXgate, VXbuilder and VXwatch is not supported. VXgate, VXwatch and VXbuilder must be upgraded to VXgate 4.7.4, VXwatch 4.7.4 and VXbuilder 4.7.4 before installing a 4.7.4 VX node in the network. This means that prior versions of VXgate, VXbuilder and VXwatch will not be able to manage VX nodes running release 4.7.4.

System release 4.7.4 of VXgate, VXbuilder and VXwatch, on the other hand, will be backward compatible with VX / SHOUT nodes prior releases of VX running on the node.

System Upgrade and Downgrade

  • Software upgrade to 4.7.4 will use the same upgrade system as in prior releases like 4.7.
  • Upgrading to 4.7.4 from releases prior to 4.3 is not supported.
  • When upgrading from 4.7.1 to 4.7.2 on systems using Extended UC features please follow the following extra steps in the upgrade.
  • Upgrade the VX node to 4.7.2
  • Install VXbuilder 4.7.2 on a server with the OCS Admin tools installed
  • On this server, run the VX with Extended UC features wizard to add the node to OCS again. This will allow the conference caller-id to function correctly.
  • Procedure on how to upgrade using flash upgrade kits is covered in the customer documentation.
  • Field replaceable parts will be handled in the same way as previous releases

Notes and Limitations

  • Extended UC Features limitations
    • VX requires the firewall be configured correctly for the OCS edge server. If all the required ports, including STUN/UDP/3478, are not open RTP over UDP will not function. Without RTP over UDP the experience of Internet based MOC clients will be greatly reduced. VX does not support the RTP over TCP so it cannot fall back to RTP over TCP if the UDP ports are blocked. RTP over TCP provides a very low user experience.
    • No compressed (SIREN) calls to / from Microsoft AVMCU. VX SIREN codec does not currently interoperate with the Microsoft AVMCU. The VX is used for dial-in conference calls and ad-hoc conferences that add PSTN users. Normally the VX is co-located with the AVMCU. For this deployment uncompressed G.711 is the best codec for these conf calls. If the VX is not co-located with AVMCU G.711 will still be used. This will cause higher bandwidth usage on the WAN. If the company has a bandwidth constrained WAN it is recommended a AVMCU is added to the location. Otherwise a mediation server should be deployed at that location to enable the SIREN calls to the AVMCU.
    • Simultaneous ring calls will not have the Inband ringback. VX 4.7.2 only supports ICEv6. ICEv6 does not support full early media. Early media is required for inband ringback on simultaneous ring calls. This behavior is the same as Microsoft Office Communications Server 2007.  
    • If a fax call is routed TDM to TDM it will fail if T.38 is in the media class. As a workaround ensure the media class applied to the TDM to TDM call route does not contain the T.38 codec.  
  • VLAN tagging is currently only supported on the VX1800, VX1200 and VX900 chassis. The SHOUT900 chassis is not supported.
  • When using the backup registrar feature, a registration challenge response may go to the wrong registrar in proxy-like mode. In case of proxy-like mode registration that gets challenged, if the backup registrar takes over before the phone sends a second REGISTER request with user/password info, the second REGISTER will go to the secondary (Backup) registrar. Similarly if the Backup registrar challenged and went down, the REGISTER with the user/password may end up going to the primary registrar. However the possibility of the former case is very low since the ping interval is generally at least 5 seconds and it will take multiple ping failures to declare the primary down.
  • VX does not initiate the COT.
  • With full syslog turned ON and doing a high number of calls, system performance will be impacted and call failures will be seen. The amount of call failures will be dependent on the call load.
  • IPSec related limitations and notes:
    • IPSec is not supported on non-ETH interfaces, including IP-over-Serial, and ISDN in this release.
    • Aggressive mode (RFC "SHOULD") for IKE phase I is not supported in this release.
    • IPSec is supported only on the VX1800, VX1200 and VX900AB/SHOUT900AB nodes.
    • Combined transport and tunnel mode on the same traffic between two peers is not supported.
  • SRTP limitations and notes:
    • SRTP is not supported on H323 calls.
    • SRTP is supported only on the VX1800, VX1200 and VX900AB/SHOUT900AB nodes.
    • The SRTP signaling implementation in this release is based on draft-ietf-mmusic-sdescriptions-07.txt and may not interoperate with some existing implementations.
  • NET STIX card related limitations and notes:
    • Netcoder codec is not supported.
    • Supported only on the VX1800, VX1200, VX900AB / SHOUT900AB and VX900AD/SHOUT900AD platforms.
    • IVR record file not supported for this card. However, IVR support does exist including audio file playback.
    • Initial configuration, if an upgrade of the STIX firmware is required, could take up to 5 minutes for card to boot up.

Performance

Performance Criteria

Silence suppression on test equipment was set to 62%.  Average call length was set to 2 minutes. Maximum number of calls that can be initiated from IVR script is 50% of total capacity of node.  From those IVR calls, the maximum number of simultaneous active IVR sessions is 20%.

This assumes the "IVR session" (the amount of time actually spent in IVR) is no longer than 30 seconds per channel per call.  Also, it is not recommended to have debugging to disk, Ethernet sniffing, or other system level impacting tools running on a node when trying to achieve these number or even in general for that matter.

Note that the performance numbers below lists typical scenarios and that actual performance may vary per specific configuration and application used by the customer. Also note that these numbers below are assuming that there is no serial card in the system and the performance goes down as the serial card throughput increases.

VX1800 Call Performance

In the table below are the performance numbers for VX1800

Setup

 

 

 

 

 

Performance

 

#

Side 1 Protocol

IVR Enabled

Side 2 Protocol

Codec

# Channels Available

Max # Calls Up

% Success Calls

1

E&M / T1

No

BSP

G.723.1/5.3k

576

576

99

2

E&M / T1

No

BSP

G.723.1/6.3k

576

576

99

3

E&M / T1

No

BSP

G.729A

576

576

99

4

E&M / T1

No

BSP

G.711

576

576

99









5

E&M / T1

No

H.323

G.723.1/5.3k

576

576

99

6

E&M / T1

No

H.323

G.723.1/6.3k

576

576

99

7

E&M / T1

No

H.323

G.729A

576

576

99

8

E&M / T1

No

H.323

G.711

576

576

99









9

E&M / T1

No

SIP

G.723.1/5.3k

576

576

99

10

E&M / T1

No

SIP

G.723.1/6.3k

576

576

99

11

E&M / T1

No

SIP

G.729A

576

576

99

12

E&M / T1

No

SIP

G.711

576

576

99









13

R2 / E1

Yes

BSP

G.723.1/5.3k

720

720

99

14

R2 / E1

Yes

BSP

G.723.1/6.3k

720

720

99

15

R2 / E1

Yes

BSP

G.729A

720

720

99

16

R2 / E1

Yes

BSP

G.711

720

720

99









17

R2 / E1

Yes

H.323

G.723.1/5.3k

720

720

99

18

R2 / E1

Yes

H.323

G.723.1/6.3k

720

720

99

19

R2 / E1

Yes

H.323

G.729A

720

720

99

20

R2 / E1

Yes

H.323

G.711

720

720

99









21

R2 / E1

Yes

SIP

G.723.1/5.3k

720

720

99

22

R2 / E1

Yes

SIP

G.723.1/6.3k

720

720

99

23

R2 / E1

Yes

SIP

G.729A

720

720

99

24

R2 / E1

Yes

SIP

G.711

720

720

99









25

ISDN/T1

Yes

BSP

G.723.1/5.3k

552

552

99

26

ISDN/T1

Yes

BSP

G.723.1/6.3k

552

552

99

27

ISDN/T1

Yes

BSP

G.729A

552

552

99

28

ISDN/T1

Yes

BSP

G.711

552

552

99









29

ISDN/T1

Yes

H.323

G.723.1/5.3k

552

552

99

30

ISDN/T1

Yes

H.323

G.723.1/6.3k

552

552

99

31

ISDN/T1

Yes

H.323

G.729A

552

552

99

32

ISDN/T1

Yes

H.323

G.711

552

552

99









33

ISDN/T1

Yes

SIP

G.723.1/5.3k

552

552

99

34

ISDN/T1

Yes

SIP

G.723.1/6.3k

552

552

99

35

ISDN/T1

Yes

SIP

G.729A

552

552

99

36

ISDN/T1

Yes

SIP

G.711

552

552

99









37

ISDN/E1

No

BSP

G.723.1/5.3k

720

720

99

38

ISDN/E1

No

BSP

G.723.1/6.3k

720

720

99

39

ISDN/E1

No

BSP

G.729A

720

720

99

40

ISDN/E1

No

BSP

G.711

720

720

99









41

ISDN/E1

No

H.323

G.723.1/5.3k

720

720

99

42

ISDN/E1

No

H.323

G.723.1/6.3k

720

720

99

43

ISDN/E1

No

H.323

G.729A

720

720

99

44

ISDN/E1

No

H.323

G.711

720

720

99









45

ISDN/E1

No

SIP

G.723.1/5.3k

720

720

99

46

ISDN/E1

No

SIP

G.723.1/6.3k

720

720

99

47

ISDN/E1

No

SIP

G.729A

720

720

99

48

ISDN/E1

No

SIP

G.711

720

720

99









49

E&M / T1

No

E&M/T1

-

552

552

99

50

E&M / T1

No

R2/E1

-

552

552

99

51

E&M / T1

Yes

ISDN/T1

-

552

552

99

52

E&M / T1

Yes

ISDN/E1

-

552

552

99









53

R2 / E1

No

R2 / E1

-

720

720

99

54

R2 / E1

Yes

ISDN/T1

-

720

720

99

55

R2 / E1

Yes

ISDN/E1

-

720

720

99









56

ISDN/T1

No

ISDN/T1

-

552

552

99

57

ISDN/T1

Yes

ISDN/E1

-

552

552

99









58

ISDN/E1

No

ISDN/E1

-

960

960

99









59

BSP

-

H.323

G.723.1/5.3k

960

400

99

60

BSP

-

H.323

G.729A

960

400

99

61

BSP

-

H.323

G.711

960

240

99









62

BSP

-

SIP

G.723.1/5.3k

N/A

720

99

63

BSP

-

SIP

G.729A

N/A

720

99

64

BSP

-

SIP

G.711

N/A

720

99









65

H.323

-

H.323

G.723.1/5.3k

N/A

720

99

66

H.323

-

H.323

G.729A

N/A

720

99

67

H.323

-

H.323

G.711

N/A

720

99









68

H.323

-

SIP

G.723.1/5.3k

N/A

720

99

69

H.323

-

SIP

G.729A

N/A

720

99

70

H.323

-

SIP

G.711

N/A

720

99









71

SIP

-

SIP

G.723.1/5.3k

N/A

720

99

72

SIP

-

SIP

G.729A

N/A

720

99

73

SIP

-

SIP

G.711

N/A

720

99









74

SS7 / T1

Yes

SIP

G.723.1/5.3k

576

576

99

75

SS7 / T1

Yes

SIP

G.723.1/6.3k

576

576

99

76

SS7 / T1

Yes

SIP

G.729A

576

576

99

77

SS7 / T1

Yes

SIP

G.711

576

576

99

VX1800 Secure call (SCIP / STU) Call Performance

The VX1800 supports up to 600 simultaneous STU calls with 120 other non-STU calls with the STIX cards and the correct licenses.

VX Capacity

VX supports the following configurations. Note that these capacity numbers may vary depending on other loads on the node, revision of the node and other parameters.  Also, these numbers will vary if one more of these features are used at the maximum supported configuration at the same time.

Feature

Maximum supported

Number of trunk groups

200

Ports

200

Channels

1500

Peers (all three protocols UDP, TCP, TLS)

800

Call route entries in all call route tables

10000

Call route tables

100

Registrar table entries

5000

Subscriber tables

2

Subscriber entries in all subscriber tables

10,000

Total effective registrants
(number of registration requests going out of VX)

5000

Device Interoperability

The VX Series of devices support a large number of SIP endpoints. The following endpoint vendors have been qualified to interoperate with VX 4.7.4. Please contact NET for more details.

  • General Dynamics
  • Cisco 79XX series
  • Polycom Soundpoint series
  • Polycom KIRK DECT
  • Grandstream
  • Mitel
  • Pingtel
  • Softfront
  • Siemens
  • SNOM
  • Yamaha
  • NEC
  • Hitachi
  • Saxaphone
  • Thompson Electronics

Resolved Defects

R4.7.4 Resolved Defects

Critical

VX-3497

Severity: Critical

Release Caused:

4.7.2

Summary:

VX-1200 CRASHED during MLPP testing

Detail:

During repeated running of a MLPP scenario, the VX -1200 CRASHED.

Likelihood:

Always

Workaround:

None.

VX-3496

Severity: Critical

Release Caused:

4.7.2

Summary:

VX 1200 - Flash Override call failed to connect after preemption scenario and BSP channel locks up

Detail:

During the running of an MLPP scenario on a VX1200, the preempting FLASH OVERRIDE call failed to connect after the preemption occurred. The BSP channel that was preempted and being reused on the VX 1200 gets stuck in a "Waiting for Route" condition. The BSP channel must be cleared by the operator in the CLI with the "reset channel" command. This failure occurs when there is a resource contention on the BSP and the TDM channels and the preemption must occur on all of them (BSP and TDM).

Likelihood:

Always

Workaround:

None.

VX-3375

Severity: Critical

Release Caused:

4.7.4

Summary:

VX crashes when uploading new config

Detail:

VX Crashes when configuration changes are uploaded. This problem occures after SS7 is enabled.

Likelihood:

Always

Workaround:

None.

VX-3530

Severity: Critical

Release Caused:

4.7.4

Summary:

UMR V.150 - L3 OMNI - unintelligible audio after secure call establishment OMNI to OMNI

Detail:

L3 OMNI secure call audio was unintelligible after secure call was established over UMR V.150. Secure call setup and tore down properly. It was noted that after the successful establishment of a secure call between two L3 OMNI SWTs the audio was unintelligible. Choppy sounds could be heard on both sides but no words could be made out. The sounds did not sound like modem retraining.

Likelihood:

Always

Workaround:

None.

Major

VX-3451

Severity: Major

Release Caused:

4.7.2

Summary:

VX should be able to generate a Certificate Request as per DoD Requirements also

Detail:

VX must be able to generate DoD PKI formatted certificate requests using the following fields:
CN=<Certificate Name>
OU=<Org Unit>
OU=<Org Unit1>
OU=<Org Unit2>
O=<Org Name>
C=<Country>

Likelihood:

Always

Workaround:

None.

VX-3459

Severity: Major

Release Caused:

4.7.2

Summary:

A VX generated Certificate Request has incorrect information in the Authority Key Identifier" attribute"

Detail:

he VX generates a PKI Certificate Request with incorrect information in it. The Authority Key Identifier attribute in the VX generated certificate request had information in the "Certificate Issuer" field.

Likelihood:

Always

Workaround:

None.

VX-3457

Severity: Major

Release Caused:

4.7.2

Summary:

Certificate requests for DoD should have a key length of 2048 bits as default.

Detail:

Certificate requests created using VX CLI commands are generated using 1024 bit key length as the default. The default needs to be set to 2048 bits. The option to use 1024 bits will remain. Also, it should NOT contain the Enhanced Key Usage Parameter

Likelihood:

Always

Workaround:

None.

VX-3458

Severity: Major

Release Caused:

4.7.2

Summary:

The DN for DoD Request needs to be in Reverse order as required by the DoD PKI.

Detail:

The default certificate request name should be request.csr for DoD requests. The order of Distinguished Name (DN) fields in the certificate request is required to be flipped. Also the default certificate request filename is expected to be "request.csr" instead of "request.cer" for DoD specific certificate requests.

Likelihood:

Always

Workaround:

None.

R4.7.2 Resolved Defects

Critical

None

Major

VX-2564

Severity: major

Release Caused:

4.7.1

Summary:

Dial-in conference users have the wrong calling number in the conference.

Detail:

When a PSTN user dials into a MS conference, the calling number of the PSTN user does not get displayed to the MOC users participating in the conference.

Likelihood:

Always

Workaround:

None.

Minor

VX-2592

Severity: minor

Release Caused:

4.7

Summary:

VXGate : Exported Queries including carriage returns may not import correctly

Detail:

SQL Queries that include carriage returns may not load from an exported configuration.

Likelihood:

High if multiple lines are in the queries

Workaround:

Don't use multiple lines.
It is possible to delete the carriage returns from the exported .reg file using a unicode-aware text editor, this should only be done on copies of the file in case of mistake.

VX-2616

Severity: minor

Release Caused:

4.7.1

Summary:

CAS Tunnel function does not work for the first call

Detail:

On CAS Tunnel, the first call is not tunneled. After couple of calls are run, it works properly.

Likelihood:

Medium

Workaround:

None.

VX-2637

Severity: minor

Release Caused:

4.7.1

Summary:

MRD channel sends Seize bits on manual channel reset and causes the circuit to ring.

Detail:

When a CAS MRD channel is reset, it sends the seize bits to the FAR end CAS. Since in MRD seize bits is the indication for call establishment, the far end device starts ringing.

Likelihood:

Always

Workaround:

None

VX-2643

Severity: minor

Release Caused:

4.7.1

Summary:

VXwatch goes into reconnect loop if you connect to a secure node with a nonexistent user

Detail:

VXwatch goes into reconnect loop if you connect to a secure node with a nonexistent user.Initiating a TLS handshake for each login attempt , even when the watch is already in authenticated state leads to the issue. Avoiding a TLS handshake when VXwatch is already in authenticated state resolves the issue.

Likelihood:

Always

Workaround:

None

VX-2755

Severity: minor

Release Caused:

4.7.2

Summary:

Support for delayed media with SRTP

Detail:

Currently VX does not support delayed media with SRTP. So calls made from CoMo via VX do not come up, as OCS makes the SRTP call without SDP.

Likelihood:

Always.

Workaround:

No workaround.

VX-2785

Severity: minor

Release Caused:

4.7.1

Summary:

MOC R2 to PSTN - No DTMF heard at the PSTN side.

Detail:

In a MOC to PSTN call, after reinvite, dtmf digits are not sent correctly to PSTN side.

Likelihood:

Medium

Workaround:

No workaround.

VX-2793

Severity: minor

Release Caused:

4.7.1

Summary:

VX sends 183 with SDP when receives PROGRESS with PI=1 on ISDN side. It should send 183 without SDP.

Detail:

VX sends 183 with SDP even after setting up the PROGRESS message with PI = 1. VX must send 183 without SDP in this case.

Likelihood:

When PROGRESS message with PI = 1 is received, 183 is sent with SDP.

Workaround:

No work around

VX-2943

Severity: minor

Release Caused:

4.7.1

Summary:

QoE report not sent by VX for the call flow PSTN -> VX -> MOC -> CWD -> exUM

Detail:

VX did not send RemoteUserAgent value in the QoE report of SERVICE message due to which OCS sent a 400 response.

Likelihood:

Always

Workaround:

None

VX-3260

Severity: minor

Release Caused:

4.7.1

Summary:

APL: First Fax call successful, All subsequent fax calls fail

Detail:

ISDN FAX calls over BSP are failing.

Likelihood:

Only first FAX call on a channel goes through. Subsequent fax calls fail.

Workaround:

No direct workaround. Resetting the channel will help.

VX-3304

Severity: minor

Release Caused:

4.7.1

Summary:

Provision to update VXe details on OCS when there is an entry existing for the same node.

Detail:

Instance of MSFT_SIPTrustedAddInServiceSetting class gets created on OCS R2 FE when VXe is added to OCS network. Gateway version in this instance is set to 1. This results in PSTN calling number not gettiing displayed on the MOC, involved in the conference.

Likelihood:

Always

Workaround:

Gateway version in VXe's instance of MSFT_SIPTrustedAddInServiceSetting class should be set to 4, on OCS R2 FE, by using any WMI administrative tool.

R4.7.1 Resolved Defects

Critical

NETab25242

Severity: critical

Release Caused:

4.4.2

Summary:

SET TIME CMD and VXgate time sync w/o restart can loose IP connectivity

Detail:

Changing the VX time using "set time" command via CLI will result in
erroneous results on VX. Sniffing/logging issues, call failures, CSN-port
mapping issues, ip-connectivity issues etc. are some of the issues that
might be seen due to the change in time.

Likelihood:

Always if the change in time is huge, may be in hours.

Workaround:

A 'Reboot' is required after the time is changed from CLI.

NETab28841

Severity: critical

Release Caused:

4.4.2

Summary:

Incorrect logic in DiskLoggerEngine can result in loggers not getting
registered

Detail:

The DiskLoggerEngine does not decrement count of registered loggers when
the logger is removed. So once the count reaches the maximum(256), it
stops registering new loggers.

Likelihood:

Less likely, since this is seen only when the number of loggers exceeds 256.

Workaround:

None

NETab28849

Severity: critical

Release Caused:

4.7

Summary:

VX App restart upon stix card coming up

Detail:

If D channel is not configured on STIX ISDN ports (even if ports are
disabled), STIX card fails to boot and causes VX application to crash.

Likelihood:

Less likely, since this occurs only if ISDN ports on STIX are configured
without any D channels

Workaround:

change any isdn ports (disabled or not) to have a D-channel

NETab29138

Severity: critical

Release Caused:

4.7

Summary:

No RTP leg after Refer from Exchange UM

Detail:

Before placing INVITE to the new destination we set remote media
IP and port to 0.
In the log:

[ 2f4\][20090728.234229.530:rb.d2] RB_Reconnect: Channel 1:15:1:1 requesting to reconnect to 0.0.0.0/0 in Tx direction
[ 2f4\][20090728.234229.530:rb.d2] RB_Reconnect: 1:15:1:1 succeeded reconnect to 0.0.0.0/0
[ 2f4\][20090728.234229.702:rb.d2] RB_Reconnect: Channel 1:15:1:1 requesting to reconnect to 0.0.0.0/0 in Tx direction
[ 2f4\][20090728.234229.702:rb.d2] RB_Reconnect: 1:15:1:1 succeeded reconnect to 0.0.0.0/0
[ 4a8\][20090728.234230.139:rb.d2] RB_Reconnect: Channel 1:15:1:1 requesting to reconnect to 10.1.1.4/6272 in Tx direction
[ 4a8\][20090728.234230.139:rb.d2] RB_Reconnect: 1:15:1:1 succeeded reconnect to 10.1.1.4/6272
[ 4a8\][20090728.234252.389:rb.d2] RB_Reconnect: Channel 1:15:1:1 requesting to reconnect to 0.0.0.0/0 in Tx direction
[ 4a8\][20090728.234252.389:rb.d2] RB_Reconnect: 1:15:1:1 succeeded reconnect to 0.0.0.0/0

since the transfer fails along with restoring the new session we need
to restore the remote media IP and port.

Likelihood:

Always when transfer fails.

Workaround:

Not available when transfer is used.

Major

NETab15845

Severity: major

Release Caused:

4.1

Summary:

SRTP/SVTP request is dropped as invalid if Key life time = 0

Detail:

SRTP/SVTP request is dropped as invalid if Key life time is set to 0.

Likelihood:

Always

Workaround:

Set to non-zero value.

NETab26988

Severity: major

Release Caused:

3.0

Summary:

VX sends SETUP ACK instead of Call Proceeding even when overlap sending
is off

Detail:

When VX receives a setup message with no sending complete, with overlap
sending disabled in the channel profile, VX should send
a call proceeding.
VX sends a setup ACK regardless of whether overlap sending is
disbaled or not.
So, a new option will be needed in ISDN profile to enable/disable Overlapped
Receiving.

Likelihood:

Always.

Workaround:

No workaround.

NETab28236

Severity: major

Release Caused:

4.7

Summary:

VX sends register request.to proxy when proxy like mode isn't licensed.

Detail:

Even though proxy like mode is not licensed any REGISTER messages
are still sent to the proxy.

Likelihood:

Always.

Workaround:

None.

NETab28380

Severity: major

Release Caused:

4.7

Summary:

MLPP: ISDN Progress Message causes BPA failure

Detail:

If an ISDN progress message is received during the call setup, BPA and
certain other announcements may not play

Likelihood:

Most call paths will use PROGRESS messages, so this is reasonably likely
on many types of switches.

Workaround:

None known

NETab28414

Severity: major

Release Caused:

4.7

Summary:

UPA repeatedly played for ISUP call when no MLPP license available

Detail:

When an incoming ISUP MLPP call has no MLPP license available and voice
prompts are enabled the UPA prompt is played continuously.

Likelihood:

Always when no MLPP license is available and voice announcements are
enabled.

Workaround:

None.

NETab28437

Severity: major

Release Caused:

4.4.4

Summary:

Overlap ISDN dialing and AD lookup does not complete routing

Detail:

When an incoming overlap ISDN call finishes with just a sending complete IE
in a separate information message the AD call routing does not find
a route a rejects the call.

Likelihood:

Always when overlap ISDN ends with just a sending complete IE.

Workaround:

Use enbloc digit sending.

NETab28469

Severity: major

Release Caused:

Unknown

Summary:

Need to use Global Call Reference for Service Messages originated by VX

Detail:

If calls are in progress on a link when channels are blocked or unblocked,
the SERVICE messages may go out with a CSN other than 0.

Likelihood:

If features such as LLEM are used, this is relatively likely. Otherwise,
most channels are blocked with no call active.

Workaround:

None known

NETab28509

Severity: major

Release Caused:

4.4.4

Summary:

License limitation error while making SIP proxy call

Detail:

SIP proxy calls can fail with a license error when no license issue exists

Likelihood:

If sip proxys are in use, this becomes somewhat likely.

Workaround:

None known

NETab28585

Severity: major

Release Caused:

4.4.4

Summary:

VX registrant stops working if communication to the registrar is down

Detail:

If the link between VX (registrant) and registrar goes down, VX attempts to register for a while and then stops. It does not restart registration
once communication is re-established.

Likelihood:

This issue could be seen all the times.

Workaround:

There is no known workaround possible at this time.

NETab28810

Severity: major

Release Caused:

4.7

Summary:

ISDN: T1->BSP->E1 and vice-versa does NOT work if the switch decodes
Bearer Cap

Detail:

If a call is routed T1 ISDN->BSP on first VX node, sent to second VX node
and routed BSP->E1 ISDN, the Bearer Capability IE will not be set correctly.

Likelihood:

Less likely as this will occur only if call is routed T1 ISDN->BSP on first
VX node, sent to the second VX node and routed as BSP->E1 ISDN on second
node.

Workaround:

None

NETab28847

Severity: major

Release Caused:

4.7.1

Summary:

VX crashed while running 100 STU performance testing on a 4-port STIX
T1/E1 card

Detail:

VX crashed while running 100 STU performance testing on a 4-port STIX T1/E1 card due to logger subsystem syncronization issue.

Likelihood:

Low

Workaround:

This is random thread synchronization issue with the logger subsystem and the only work around is to turn of the logger.

NETab29168

Severity: major

Release Caused:

4.7

Summary:

Wizard should set "RFC2833 End Indications" correctly so that DTMF can
work.

Detail:

In VXbuilder wizard templates, RFC2833 End indications was set to nothing, it needs to be set to "3"

Likelihood:

Always.

Workaround:

We have to configure RFC 2833 end indications to "3", after we run the wizard.

NETab29270

Severity: major

Release Caused:

Unknown

Summary:

SIP Timer D expires eventhough ACK is received to 200 OK, VX sends BYE

Detail:

For UDP transport, when ACK is sent for transaction which has a non-2xx response class (i.e. response class 3xx-6xx), the expiry of harmless timer D to clear the transaction causes the call to be torn down.

Likelihood:

Low, happens only in cases which have the dialog open even after non-2xx response viz. proxy-like challenger mode, where INVITE is challenged with 401 Unauthorized message.

Workaround:

Use TCP instead of UDP.

NETab29357

Severity: major

Release Caused:

4.7.1

Summary:

Transfered MOC call is disconnected by VXe after 32 sec

Detail:

Transfered MOC call is disconnected by VXe after 32 sec

Likelihood:

 

Workaround:

 

VX-1738

Severity: major

Release Caused:

4.7.1

Summary:

VX1800: Crashed during IVR E1>ISDN>SIP>G711m Silence On Performance Testing

Detail:

while running the IVR call, we are able to see this issue. The fragmentation is caused by our per-thread heap system. This would definately be exacerbated by the IVR system, which starts a new thread for every call, and may induce too great a load for the system to find time to consolidate free heaps. which is causing this issue.

Likelihood:

Always

Workaround:

There is no work around.

VX-2569

Severity: major

Release Caused:

4.7.1

Summary:

One Way Audio when calling landline from Tanjay phone.

Detail:

One way audio occurs when a call is made from Tanjay phone to a PSTN. The same call works fine from a Microsoft office communicator client.

Likelihood:

Occurs only when using Tanjay phone.

Workaround:

None.

VX-2639

Severity: major

Release Caused:

4.7.1

Summary:

10th iterative transfer attempt from MOC-behind-EDGE to MOC-in-LAN (with 21ms delay) crashed the node.

Detail:

10th iterative transfer attempt from MOC-behind-EDGE to MOC-in-LAN (with 21ms delay) crashed the node.

Likelihood:

Always

Workaround:

No workaround is known

VX-2672

Severity: major

Release Caused:

4.4.2

Summary:

VX1800: Crashed without minidump after configuration changes

Detail:

The node crashes when leaving config mode if a large number of configuration changes have been made.

Likelihood:

Low.

Workaround:

Divide large sets of changes into smaller groups. Leave and re-enter config mode between groups.

VX-2735

Severity: major

Release Caused:

4.7.1

Summary:

Name presentation lost to PBX upon upgrade from 4.7 to 4.7.1

Detail:

Q.SIG calling name may not work even when the correct switch type is set.

Likelihood:

High

Workaround:

None known

VX-3005

Severity: major

Release Caused:

4.7.1

Summary:

OCS Response Group REFER not processed by VX

Detail:

In OCS R2 environment, when OCS Response Group initiates a transfer using REFER, VX was sending the resulting INVITE back to OCS which used to fail to route the call.

Likelihood:

Always

Workaround:

None

VX-3064

Severity: major

Release Caused:

4.7.1

Summary:

WAVE14: VX is formatting the SIP From Header Domain Portion Incorrectly

Detail:

VX is using the SIP Proxy field to format the From header domain. The From header domain should come from the Ethernet FQDN setting or the DNS-Suffix field.

Likelihood:

This behavior comes into picture if the callingnumber does NOT have a '@' in it AND if 'proxy' field is configured in the call route.

Workaround:

Workaround is to use a calling number translation table.

VX-3070

Severity: major

Release Caused:

4.3.4

Summary:

VX 4.7.1v127 does not handle session refresh properly problem also seen in 4.1.1v116

Detail:

When SIP session refresh is enabled, VX acting as refresher dropped SIP ReINVITE messages (subsequent to the first), this resulted in session not getting refreshed and call getting dropped.

Likelihood:

Medium, when SIP Session Refresh is enabled on VX.

Workaround:

None

VX-3072

Severity: major

Release Caused:

4.7.1

Summary:

Wave 14: For forked calls VX should lock onto the first RTP stream it recieves, not the first 183 with SDP.

Detail:

For forked calls, VX should lock on to the first early media stream that comes in and ONLY shift to the SDP of 200 OK.

Likelihood:

Always for forked calls.

Workaround:

None

Minor

NETab23416

Severity: minor

Release Caused:

4.4.1

Summary:

SIP Conformance:VX do not handle multiple Via headers correctly.

Detail:

We were NOT RFC3261 compliant in handling multiple Via headers in SIP
request/response. We SHOULD drop such SIP message silently.

Likelihood:

Always in the presence of multiple Via headers in SIP message.

Workaround:

None.

NETab25439

Severity: minor

Release Caused:

Unknown

Summary:

IA: Exempt Login Security does not exempt security settings

Detail:

Disabling login security for the user in the script after setting up a new node and creating a user using the startup script, would not disable the login security requirements.

Likelihood:

When the node is imaged and "exempt login security" is opted in start-up script. Everytime a new user is created and password/security settings of the user are modified.

Workaround:

No Workaround.

NETab25900

Severity: minor

Release Caused:

4.3.4

Summary:

VXBuillder throws verify warning with '++:5060' as input routing rule

Detail:

Customer activating new node and a route that works without config verify warnings on other nodes, causes a verfy warning with this node: 'Warning: Call Routing table #xxx entry x has destination port based routing and is not associated with any SIP incoming trunk group' This warning is thrown on the one node config but the same route entry in the other node config does not cause a verify warning. These routes have '++:5060' as the input rule.

Likelihood:

Among the configured routes,whenever call route table number is not the same as the SIP inbound route number we see this issue.

Workaround:

As long as the call route table number is same as the SIP inbound route number We dont see this issue for any route as config will pickup the nestmask value based on the index.

NETab26162

Severity: minor

Release Caused:

4.4.4

Summary:

900AD STIX - Shutdown crash occured post issuing CLI::restart VX
command

Detail:

This issue appears to be a crash accessing a SIP session while clearing
out sessions on VX shutdown.

Likelihood:

This issue could be seen all the times.

Workaround:

There is no known workaround possible at this time.

NETab27736

Severity: minor

Release Caused:

4.7.1

Summary:

Other protocols besides ISDN peer need to be updated to work with RFC3960

Detail:

NETab27735 (ISDN to SIP RFC 3960 compliance) makes ISDN to SIP follow RFC3960. If this option is enabled for SIP to SIP, this can cause issues because SIP does not generate local ringback normally. SIP and the other protocols need to be updated to make sure they follow RFC3960 and interwork. This has to be fixed as part of the MS UC Advanced GW work. The adv gw specification requires SIP to SIP setup to work and without this fix certain cases will not have ringback.

Likelihood:

Always.

Workaround:

None.

NETab28366

Severity: minor

Release Caused:

4.4.2

Summary:

FXS: Delayed detection event timers appear to run short

Detail:

On-hook and Off-Hook delay times in FXS may appear to run shorter than configured

Likelihood:

High if using this feature (no effect if not configured)

Workaround:

Set the on hook and off hook delay timers to be higher than the desired value by the value of the debounce timer (which should not be set to 0 in this case, as 0 is default). For instance, if you have a 60ms debounce, and you want a 200ms detection delay for off-hook, set the timer to 260ms. This guarantees that transient pulses of less than 200ms are not processed, although it is not perfect - clean transitions will require 260ms to be processed. However, this feature is usually used for line robustnes and not for response time, so the additional 60ms to get user response should not cause any issues.

NETab28396

Severity: minor

Release Caused:

4.7

Summary:

MLPP: Equal precedence calls may receive fast busy instead of BPA

Detail:

A blocked precedence call at equal precedence to existing calls may generate a fast busy tone (reorder) rather than the blocked precedence announcement.

Likelihood:

Medium

Workaround:

No workaround.

NETab28418

Severity: minor

Release Caused:

4.4.2

Summary:

VX selects last Calling Number IE when there is more than one

Detail:

VX selects the last Calling Party Number IE when there is more than one Calling Party Number IE in the incoming ISDN SETUP message.

Likelihood:

Less likely since this occurs only if multiple Calling Party Number IEs
are received in the ISDN SETUP message.

Workaround:

Do not include send multiple Calling Party Number IEs in an ISDN SETUP message sent to VX.

NETab28513

Severity: minor

Release Caused:

Unknown

Summary:

VXvue license is not freed if the node sub-window is closed in VXwatch

Detail:

VXWatch does not close the connection to a node when the sub-window is closed. Instead, all connections to all nodes are closed when the main window is closed.

Likelihood:

As the user manages a greater number of nodes, the likelihood of noticing these extra connections increases.

Workaround:

Do not close sub-windows, just leave all the connections open.

NETab28789

Severity: minor

Release Caused:

Unknown

Summary:

Inconsistent time stamp between CDR records and VX

Detail:

Daylight savings time may cause CDR timestamps to shift

Likelihood:

High

Workaround:

Disable daylight savings time on VXGate (through the Windows time system).

NETab28798

Severity: minor

Release Caused:

Unknown

Summary:

VX1200: Call failures observed during E1>CAS R2 Automation test run.

Detail:

MFR2 inband signaling had failing for a few calls when VX was running under heavy loads. This was more obvious while interworking with H323 protocol. The root cause was identified as heavy loading of one of the internal systems under these conditions. This has been fixed by changing the path digits used to ply within VX. While this fix might not resolve the issue completely, it should give a performance boost to all the external systems depending on inband signaling systems like DTMF, R1 and MFR2.

Likelihood:

This is a performance issue which will most likely be hit when the VX node reaches near its full load running CAS R2 <-> H323 calls

Workaround:

Reduce the load on the system.

NETab28832

Severity: minor

Release Caused:

4.7.1

Summary:

Need a warning if UMR/MRP sets to Allowed but no audio codec in media
class

Detail:

Audio codec is needed for UMR when the Modem Replay Preferred configuration item is set to Allowed or No. Hence trowing an warning/error will be helpful to avoid no audio issue.

Likelihood:

 

Workaround:

None

NETab28997

Severity: minor

Release Caused:

Unknown

Summary:

Name xlation to blank works differently on TG ingress vs egress

Detail:

In trying to blank the calling name, found that the operation works differently on TG ingress (works) vs. egress (broken) . It is found, the calling name is removed in the ingress trace, but is persistent in the egress TG configuration.

Likelihood:

This issue could be seen all the times.

Workaround:

There is no known workaround possible at this time.

NETab29042

Severity: minor

Release Caused:

Unknown

Summary:

VXwatch registrar table, refresh registrar table btn problem on window resize

Detail:

VXwatch registrar table form do not align the Refresh Registrar table button on resize.

Likelihood:

Always.

Workaround:

There is no work around, as resizing the window will always shows this issue

NETab29167

Severity: minor

Release Caused:

4.7.1

Summary:

Tone Table has wrong/incorrectly ordered elements for Table #1

Detail:

Tone table values upon cut and paste from another table do not align properly.

Likelihood:

Always

Workaround:

Nothing

NETab29210

Severity: minor

Release Caused:

4.4.4

Summary:

D-Channel Permanently OOS if VX restarted with D-channel disabled.

Detail:

If the D-channel is explicitly disabled in the configuration, odd VXWatch
displays and channel behavior may occur.

Likelihood:

If users use automatic channel assignment, this issue can't occur (as the D-Channel cannot be disabled in that configuration)

Workaround:

Never disable the D-channel. It will not have the desired effect.

VX-1612

Severity: minor

Release Caused:

4.3.5

Summary:

When rejecting a call with ISDN configured as network side, the status on the far side can get screwed up. This situation is complicated in an IVR DSP resource contention.

Detail:

When ISDN is rejecting calls while configured as network side, it can send an incorrect message.

Likelihood:

ISDN is usually able to accept calls, so users will probably not see this.

Workaround:

None known

VX-1624

Severity: minor

Release Caused:

4.4.4

Summary:

If a TLS problem exists with the node, VXWatch can have bizarre connection behavior

Detail:

This will appear when node has an invalid certificate. This error case happens when the Local Security Authority cannot be contacted.

Likelihood:

Low

Workaround:

Have a valid certificate in the node.

VX-1655

Severity: minor

Release Caused:

4.4.2

Summary:

Call between PSTN to MOC R2 via VX(IGW) - Multiple codecs in MOC's answer causes oneway audio.

Detail:

This issue would be observed when any SIP UA which negotiates multiple codecs in a single stream by sending more than codec in the 200 OK response of the INVITE from VX and the SIP UA switches its RTP stream between one of the negotiated codecs.
This behavior has been observed with only MOC so far.

Likelihood:

This problem would be observed when the SIP peer sends multiple codecs in the 200 OK response of the INVITE from VX and the SIP peer switches the RTP stream between one of the negotiated codecs.

Workaround:

As a temporary workaround, you could configure VX to advertise only one audio codec so that MOC uses only that codec for the call.

VX-1665

Severity: minor

Release Caused:

4.7

Summary:

MLPP: ISUP: incorrect cause value sent in Release Message during equal or higher precedence call condition

Detail:

ISUP can send the wrong cause code in some MLPP cases

Likelihood:

This only affects users using MLPP

Workaround:

None known

VX-1717

Severity: minor

Release Caused:

4.3.6

Summary:

ISDN should not fail calls over a simple warning STATUS message

Detail:

If VX receives a STATUS message as a warning, it will always fail the call.

Likelihood:

Some switches readily generate warnings over extra information being included.

Workaround:

None known

VX-1730

Severity: minor

Release Caused:

4.7.1

Summary:

CLI command is required to send a new SERVICE request

Detail:

An admin level command is needed to make VX refresh the information it obtained from MRAS.

Likelihood:

Always

Workaround:

None

VX-1732

Severity: minor

Release Caused:

4.3.5

Summary:

AD user login to VX node is successful if login is for CLI login but unsuccessful if login is for VXbuilder and for VXwatch

Detail:

The system will reject logins of the form \ from VXBuilder and VXWatch

Likelihood:

Since many users are more familiar with the older method, they will probably notice this.

Workaround:

Use the login @ to log in

VX-1877

Severity: minor

Release Caused:

4.7

Summary:

VXGate cannot use network licensing

Detail:

When attempting to use a VXGate with a VXGate license installed on the VX, the VXGate will sometimes report errors about HMAC mismatches, and will not log CDRs

Likelihood:

Since all customers with VXGate needs are being transferred to having the license installed on the VX, this will become more likely.

Workaround:

None available

VX-1882

Severity: minor

Release Caused:

4.7.1

Summary:

V.150: Provide user configurable option for V.34 Linear/Non-Linear encoder(enable/disable)

Detail:

V.34 code performs very good without bit errors when it does not do Non-Linear in digital environment and hence the configuration option provides flexibility according to deployment needs.

Likelihood:

Always.

Workaround:

If the lower rates are used the bit error is lesser and the call could withstand for a very long time(more than 3 hours) without much loss of random noise..

VX-1900

Severity: minor

Release Caused:

4.7

Summary:

System failed to reroute SIP call when glare is encountered on ISUP side for a SIP-ISUP call

Detail:

VX failed to reroute SIP call when glare is encountered on ISUP side for a SIP-ISUP call. This occurs only if alternate route for the SIP inbound trunkgroup points to a trunkgroup containing only a single channel

Likelihood:

Always if the alternate route for the SIP inbound trunkgroup points to an outbound trunkgroup containing only a single channel

Workaround:

None

VX-1964

Severity: minor

Release Caused:

4.7.1

Summary:

CLI: Multiple CAS variants should be removed from CLI command "port <1-N> type"

Detail:

With 4.7.1, for all CAS protocols the port type must be configured as CAS. The actual CAS protocol used will be based on the type of the channel profile for the channel. The changes have been made in CLI, so that only the port type CAS will be available for configuration. The actual CAS protocol selection for CAS must be done via channel profile. Also, the profile type cas-tun and cas-mrd will be available for configuration via CLI.

Likelihood:

Always.

Workaround:

No workaround. This is a new feature in VX for CAS protocols.

VX-1969

Severity: minor

Release Caused:

4.3.5

Summary:

When changing service messaging capability, stuck states do not always clear.

Detail:

When reconfiguring a T1 ISDN circuit, it is possible for the channels to end up in an OUT OF SERVICE state which will not clear.

Likelihood:

Low, as most T1 equipment supports the SERVICE message protocol.

Workaround:

Restart the VX after changing the service messaging state in the channel profile.

VX-2016

Severity: minor

Release Caused:

4.7

Summary:

Double digits heard on sending digits over STIX - H323 - STIX setup

Detail:

For a TDM to VoIP call, sometimes double digits are heard when digits are sent over H.323. This happens only in case of STIX card on TDM side and H.323 on VoIP side.

Likelihood:

medium

Workaround:

None. The problem is due to H.323 standard itself. Fix provided is a workaround only where a config item is provided to fix this issue.

VX-2095

Severity: minor

Release Caused:

4.3.4

Summary:

VXGate Can Not Create RADIUS Sockets (RADIUS does not work)

Detail:

RADIUS subsystem will not start in VXGate from 4.2 through 4.7

Likelihood:

Always if RADIUS is in use (other subsystems are not affected)

Workaround:

Upgrade software to obtain the fix.

VX-2177

Severity: minor

Release Caused:

4.4.4

Summary:

Memory Leak and Crash during SIP to ISDN to SIP Stress Test - Node out of memory in less than 25 minutes

Detail:

If a VX is logging CDRs to a VXGate, where the VXGate is using software (not HASP based) licensing, the VX can run out of memory in an extraordinarily short amount of time.

Likelihood:

As this is the new recommended configuration for VXGate licensing, it would be seen more often in deployments.

Workaround:

Disable CDR logging

VX-2325

Severity: minor

Release Caused:

4.7.1

Summary:

VXGate time server does not work if no database configured

Detail:

VXGate Time Server May not work without a database connected

Likelihood:

High on prior releases if customer is not using a database

Workaround:

Create a local Text database to give VXgate something to attach to. It does not need any queries defined.

VX-2326

Severity: minor

Release Caused:

4.4.4

Summary:

MOC to PSTN call attempt fails with authentication error if MTLS is configured on SIP trunk group

Detail:

MTLS does not work as expected, often reporting that the certificate usage is not valid.

Likelihood:

MTLS between two computers is going to encounter this 100% of the time.

Workaround:

Use TLS rather than MTLS.

VX-2560

Severity: minor

Release Caused:

4.7.1

Summary:

VX response to a long URI in INVITE is incorrect

Detail:

When VX receives an INVITE message with very long request URI, VX just drops the message. It does not respond to the message with "414 Request URI very Long" error.

Likelihood:

Always

Workaround:

None. If Request URI is long, VX does not respond with "414 Request URI very Long" error.

VX-2561

Severity: minor

Release Caused:

4.7.1

Summary:

Re-INVITE with new codec is not accepted by MOC after narrowing down answer to 1-ne codec.

Detail:

Re-INVITE with new codec is not accepted by MOC after narrowing down answer to 1-ne codec.

Likelihood:

Medium

Workaround:

No workaround is known

VX-2563

Severity: minor

Release Caused:

4.7.1

Summary:

GA #2: Redundant RTP (RFC2198)-FEC should be on in the extended UC features wizard

Detail:

Extended UC wizard needs to enable the redundant RTP.

Likelihood:

Always

Workaround:

None

VX-2565

Severity: minor

Release Caused:

4.7.1

Summary:

On failing to receive a Session-Refresh reINVITE/UPDATE, VX should bringdown the call immediately

Detail:

If VX fails to receive a session-refresh from the other end, it has to bringdown the call immediately without waiting for the BYE transaction to complete.

Likelihood:

Always

Workaround:

None

VX-2570

Severity: minor

Release Caused:

4.7.1

Summary:

MOC transfers Polycom phone to ISDN - One way audio only between Polycom and ISDN phones.

Detail:

MOC transfers Polycom phone to ISDN phone - One way audio only between Polycom and ISDN phones.

Likelihood:

Everytime MOC transfers Polycom phone to ISDN phone.

Workaround:

No workaround available!

VX-2571

Severity: minor

Release Caused:

4.7

Summary:

Overlapped Receiving cannot be dynamically reconfigured

Detail:

The Overlap Receiving field in the Channel Profile does not take effect in real-time.

Likelihood:

This field usually does not need to be changed, so the likelihood is low

Workaround:

Restart the node after changing this field

VX-2581

Severity: minor

Release Caused:

4.7.1

Summary:

Blind transfer after consultative transfer results in one way audio

Detail:

A blind transfer followed by a consultative transfer results in one way audio

Likelihood:

This happens every time a blind transfer is followed by a consultative transfer.

Workaround:

No workaround.

VX-2601

Severity: minor

Release Caused:

General

Summary:

ISDN call clearing upon receipt of STATUS message

Detail:

An ISDN progress message with "not end to end ISDN" value can be changed to "inband information" when it passes through the VX.

Likelihood:

Low chance, requires specific ISDN to ISDN call scenario

Workaround:

Use a message translation table to prevent this from happening.

VX-2662

Severity: minor

Release Caused:

4.7.1

Summary:

Call transfer is dropped if transfer if attempted after the call has been connected for a period of time.

Detail:

In OCS R2 environment, call transfer failed due to one way audio when attempted on a call which has been connected for a period of time.

Likelihood:

Always

Workaround:

None

VX-2669

Severity: minor

Release Caused:

4.7.1

Summary:

Resource-Priority header should include 'precedence-domain' value even when it is "000000"

Detail:

VX did not include "precedence-domain" value in Resource-Priority header when its value was "000000"

Likelihood:

Always

Workaround:

None

VX-2670

Severity: minor

Release Caused:

4.7.1

Summary:

For any call direction i.e. from MOC to ISDN or ISDN to MOC, if the SIP Channel is reset, no SIP service message is sent by VX, therefore no QoE report for the call

Detail:

When a sip channel involved in a call is reset using CLI "reset channel ...", the call is brought down but the QoE Report is not sent to the QoE server.

Likelihood:

This problem is observed whenever a sip channel involved in a call, is reset using CLI "reset channel ..."

Workaround:

Ensure that SIP channels which are being used in a call, are not reset manually using CLI command "reset channel ...".

VX-2673

Severity: minor

Release Caused:

4.7.1

Summary:

End-user cannot select the private key to use with an imported certificate

Detail:

If the certificate received in response to a certificate request does not automatically link to the private key created when the request was generated, there is no way to fix this situation.

Likelihood:

Fairly low, as most CAs sign the certificate with the common name and subject name set as expected.

Workaround:

None available.

VX-2674

Severity: minor

Release Caused:

4.7.1

Summary:

VX should report the NMOS score as 3.61 when G711mulaw(PCMU) and G711alaw(PCMA) codec is used for a call

Detail:

VX should report the NMOS score as 3.61 when G711mulaw(PCMU) and G711alaw(PCMA) codec is used for a call. It was reporting the NMOS score as 2.95

Likelihood:

Always

Workaround:

None

VX-2719

Severity: minor

Release Caused:

4.7.1

Summary:

SRTP renewal initiated by VX causes decryption failure

Detail:

In SRTP call, rekey request from other side can lead to one way audio.

Likelihood:

Medium

Workaround:

None.

VX-2809

Severity: minor

Release Caused:

4.7.1

Summary:

TLS does not correctly negotiate with some clients using non-VX style message sequencing

Detail:

If TCP fragmentation occurs, then the TLS session may fail to establish.

Likelihood:

As certificates grow larger with more complicated certificate chains, the odds of fragmenting a negotiation packet grow larger.

Workaround:

Ensure that all certificates in use are significantly smaller than the MTU of the network.

VX-2946

Severity: minor

Release Caused:

4.7.1

Summary:

VX rejects call with "488 Not Acceptable Here" message

Detail:

VX rejects call with "488 Not Acceptable Here" message. This happens for the calls where T38 is offered in initial INVITE for audio call.

Likelihood:

Always

Workaround:

None

VX-2964

Severity: minor

Release Caused:

4.7.1

Summary:

WAVE14: VX gateway send PRACK to Next Hop IPAddress instead of Contact Header in 183 Session Progress

Detail:

VX used to send PRACK to Outbound Proxy configured on the TG. This created problem in W14 setup, where the Outbound Proxy did NOT know how to route the PRACK request.

Likelihood:

Always in W14 setup

Workaround:

None

VX-2978

Severity: minor

Release Caused:

4.7.1

Summary:

VX crashes while making a SIP call in "Proxy Like Mode"

Detail:

We were trying to use a pointer that had already been freed.

Likelihood:

Always.

Workaround:

None

VX-2986

Severity: minor

Release Caused:

4.7.1

Summary:

Port VX-2948 to 4.7.1

Detail:

This is an issue with a Mangle Table Entry Leak. When a TCP SIP OPTIONS Peer is present which doesn't seem to be responding to the SIP-OPTIONS request from the VX, VX has already added a Mangle Table Entry while trying to open up a connection. After VX times out, VX don't seem to be deleting the Mangle Table entry in this particular case. Since Mangle Table Entry is a small structure, VX ran out of memory only after about 7 weeks.

Likelihood:

Always when SIP-OPTIONS peer in peer table is configured to use TCP transport.

Workaround:

Configure SIP-OPTION peer in peer table to use UDP transport

VX-3008

Severity: minor

Release Caused:

4.7.1

Summary:

VX believes TLS is open even though opening TCP has failed

Detail:

While trying to bringup a TLS connection, if the underlying TCP connection failed due to a firewall dropping these packets in between, VX WRONGLY used to assume the TCP connection was UP and try doing a TLS handshake on that connection.

Likelihood:

Only if a firewall block TCP connection initiated from VX for TLS

Workaround:

Disable the firewall so that the TCP connection goes through. If this can't be done, then no other workaround

VX-3025

Severity: minor

Release Caused:

4.7.1

Summary:

Wave 14:VX Sends the port as part of the DNS query when resolving the Route Table SIP Proxy field.

Detail:

The DNS resolution query was being passed the Port number in addition to the FQDN/IP. Thus the results were incorrect.

Likelihood:

Always.

Workaround:

Not appending the port against a SIP Proxy field in the route table.

VX-3032

Severity: minor

Release Caused:

4.7.1

Summary:

VX takes a long time to respond after transmit of trunkgroup config change

Detail:

On VX restart it crashes before actual shutdown.

Likelihood:

Medium. On Reconfiguring ISDN time slot or port this can happen

Workaround:

None.

VX-3048

Severity: minor

Release Caused:

4.7.1

Summary:

Calls Fail with 415 Unsupported Media Type when INVITE has an unsupported crypto 'a line' in addition to other supported crypto 'a lines'.

Detail:

When VX receives an INVITE with an unsupported "a=crypto" line, even in addition to other supported "a=crypto" lines, it rejects the INVITE with a 415 Unsupported Media response.

Likelihood:

Always.

Workaround:

The problem can only be circumvented by not sending any unsupported 'a-crypto' lines to the VX.

VX-3061

Severity: minor

Release Caused:

4.7.1

Summary:

VX does not ping to its own VLAN configured ip-interface.

Detail:

VX does not ping to its own interfaces if it is on a different VLAN.

Likelihood:

High

Workaround:

None.

VX-3062

Severity: minor

Release Caused:

4.7.1

Summary:

When using VXbuilder configuration wizard after getting to DNS input and using back button takes you all the way back to "Welcome to the Setup Wizard"

Detail:

In VXbuilder wizard, when using the back button to move to the previous screen, after getting to DNS input, moves the screen directly to the beginning "Welcome to the Setup Wizard", when it should have just moved to the previous screen.

Likelihood:

Always

Workaround:

None

VX-3063

Severity: minor

Release Caused:

4.7.1

Summary:

WAVE14:DNS Load Balancing not working properly

Detail:

For outbound sip calls, when a FQDN is specified as proxy which resolves to multiple ip-address, VX is sometimes choosing peer (ip-address) which is DOWN .

Likelihood:

Medium

Workaround:

None.

VX-3075

Severity: minor

Release Caused:

4.7.1

Summary:

WAVE14:VX does not distinguish between supported and unsupported methods while responding to SIP requests

Detail:

VX never sent a "501 Not Implemented" response to unsupported methods. It always used to send "405 method not allowed"

Likelihood:

Always

Workaround:

None

VX-3088

Severity: minor

Release Caused:

4.7.1

Summary:

Unknown BYE during SIP to SIP call with VXe

Detail:

When Re-INVITE is sent from SIP channel, and Session-Expires is configured to 0, the Session-Expires header will be set to zero. This will cause the call to be brought down due to session-expiry being too small.

Likelihood:

If Re-INVITE is sent from SIP channel, and Session-Expires is configured to 0 in SIP Trunk group.

Workaround:

Configure Session-Expires in SIP trunk group to 60

R4.7 Resolved Defects

Critical

NETab26682

Severity: critical

Release Caused:

4.4.4

Summary:

Memory leak in H323 when a AAA script is used

Detail:

A small memory leak occurs when an H323 channel enters IVR.

Likelihood:

Always.

Workaround:

None.

NETab26960

Severity: critical

Release Caused:

Unknown

Summary:

VX crashes for SS7 over bearer config with circuit group messages enabled

Detail:

When configured for SS7 over bearer and circuit group messages are
used VX crashes.

Likelihood:

Always.

Workaround:

None.

NETab26998

Severity: critical

Release Caused:

4.4.4

Summary:

ISDN: When a link comes up, channels can hang in RESETTING due to
contention

Detail:

When ISDN channels come up and both RESTART and SERVICE messages are being sent/received it is possible for some channels to not come up completely.

Likelihood:

Low.

Workaround:

Change the 'Restart on idle' option in the ISDN channel profile to
'never'. Or restart and/or block/unblock the channel manually.

Major

NETab18968

Severity: major

Release Caused:

3.7

Summary:

VX should not get IPSec policy update when it is joined to the domain

Detail:

VX accepts the Domain's Group Policy upon joining the domain, which can cause it to lose network connectivity.

Likelihood:

Low. Currently not many customers join their nodes to domains, and not all domains have IPSec policies, but the prevalence of this is likely to increase in the future.

Workaround:

Unjoin the node from the domain. Alternatively, after joining the nodes to the domain, put them in a separate container in the AD and put a less restrictive Group Policy on that container.

NETab23460

Severity: major

Release Caused:

Unknown

Summary:

SIP conformance: VX does not support Timestamp Header.

Detail:

VX does not provide support for the Timestamp field in SIP messages.

Likelihood:

Always.

Workaround:

None.

NETab23468

Severity: major

Release Caused:

Unknown

Summary:

SIP Conformance: ack for Reinvite(w/o M C branchid) does not have valid
branchID

Detail:

When responding to a reinvite request that does not have the magic
cookie in the branch ID VX responds with the wrong branch ID in the ack.

Likelihood:

Always.

Workaround:

None.

NETab24847

Severity: major

Release Caused:

Unknown

Summary:

SS7: when STIX port as prim and SS7 port as second clock, ports enter LOS

Detail:

SS7 card has difficulty to get clock from other slot.

Likelihood:

Alsways.

Workaround:

Always use SS7 card as primary clock.

NETab26077

Severity: major

Release Caused:

4.7

Summary:

VX does not propmt for restart when a channel is added to FXS STIX card

Detail:

Adding channels to an FXS STIX port does not prompt for a restart.

Likelihood:

Always.

Workaround:

Manually restart the node when adding channels to an FXS STIX port so that
the configuration changes take effect.

NETab26642

Severity: major

Release Caused:

4.4.4

Summary:

ISDN STIX - ISDN calls fail to establish on a card that recovered from a crash

Detail:

If the STIX card crashes and restarts any ISDN channels that had calls active when the card restarted will no longer be able to process calls.

Likelihood:

Always.

Workaround:

Restarting the VX system will allow the channels to be used again.

Minor

NETab24570

Severity: minor

Release Caused:

4.4.2

Summary:

CLI Issues: Clock information and Linkset information is wrong

Detail:

SS7 card is not showing clock information and it is always showing linkset as false even if the channel is up and linkset is valid.

Likelihood:

Always

Workaround:

None.

NETab25602

Severity: minor

Release Caused:

4.3.6

Summary:

Configuring Speed/Duplex on adapter does not take effect.

Detail:

Modifying the speed/duplex of an ethernet adapter may modify the wrong
adapter.

Likelihood:

Medium.

Workaround:

None.

NETab25926

Severity: minor

Release Caused:

Unknown

Summary:

Uploading a configuration while STIX firmware downloads can appear to fail

Detail:

If VXBuilder uploads a configuration change that requires a restart to VX while the STIX firmware is downloading it can appear that the restart request failed. The restart will occur however once the firmware download is complete.

Likelihood:

Always.

Workaround:

None.

NETab26261

Severity: minor

Release Caused:

Unknown

Summary:

VXbuilder: Enable/disable feild greys out when subcriber entry is right- clicked

Detail:

The entries in the subscriber table can not be enabled/disabled from the main viewing window.

Likelihood:

Always.

Workaround:

Edit each entry in order to enable/disable it.

NETab26431

Severity: minor

Release Caused:

Unknown

Summary:

Edit multiple doesn't work for slots

Detail:

When editing multiple slot entries in VXBuilder the AGC setting is set correctly.

Likelihood:

Always.

Workaround:

Check and correct each slot's value for AGC after editing multiple slots.

NETab26552

Severity: minor

Release Caused:

4.4

Summary:

'show snmp' does not list trap addresses correctly

Detail:

'show snmp' does not show trap addresses correctly

Likelihood:

Always

Workaround:

Download the configuration using VXBuilder to view configured trap addresses

NETab27410

Severity: minor

Release Caused:

Unknown

Summary:

SNMP MIB Does not Compile

Detail:

The SNMP MIB supplied with VX does not compile cleanly.

Likelihood:

Always.

Workaround:

None.

NETab27653

Severity: minor

Release Caused:

Unknown

Summary:

AAA audio files can on rare occasions result in no audio being played

Detail:

When performing IVR using the STIX card it is possible for a .wav file to not play even though all indications show it does play.

Likelihood:

Very low.

Workaround:

None.

  • No labels