May 28, 2010
THIS FIELD NOTICE IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTY OF MERCHANTABILITY. YOUR USE OF THE INFORMATION ON THE FIELD NOTICE OR MATERIALS LINKED FROM THE FIELD NOTICE IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS FIELD NOTICE AT ANY TIME.
Revision Date Comment 1.0 May 28, 2010 Initial Public Release
Products Affected VXSM-SW
This software issue may affect customers using MGCP and CAS signaling feature on MGX VXSM board. Service Providers use CAS signaling feature for various call services. In rare circumstances, the software goes into a "race condition" between call process messaging and call is not getting cleared properly. The suspect circuit may appear in a hung state on the VXSM card. Once in a hung state, no future calls will succeed on the suspect circuit. This is a software issue - please do not RMA the VXSM board as the board is working properly.
The issue has been identified as a loss of CAS related signaling event, which may cause the improper deletion of the call, resulting in hung state of endpoint. New requests for calls on the same endpoint are not processed.
When VXSM receives a delete connection request from CA (Call Agent) and VXSM does not receive a related RLC CAS event, the CAS state machine for that endpoint goes into a transient delete state waiting for the RLC event. This can result in a hung or stuck condition at the CAS state machine. The RLC event is important for clearing the CAS state machine spawned during CAS call establishment.
If the call clearing is not successful and the endpoint goes into a hung state, the processing of new calls on suspect endpoint may fail, and the new calls are rejected with error code 400.
The following symptom may be observed:
- The error code of 400 being returned to Call Agent for each new connection request on that endpoint.
The software fix implemented is to have the VXSM gateway not wait for RLC event and clear the CAS state machine of the endpoint once DLCX has been completely processed. The fix for this issue is documented in CSCsx71996 (registered customers only).
Option 1: Switchover the VXSM card (Active to Standby) to clear the hung CCB.
Option 2: Upgrade MGX VXSM modules software to Release 5.5.10 (available on CCO) or Release 188.8.131.52 (to be released soon).
Note: Release 184.108.40.206 has CAS vulnerability and must be upgraded to Release 220.127.116.11 (to be released soon).
Option 3: Revise Call agent routing so that trunk CICs for first and second endpoints do not reside in same VXSM. This option does not provide a procedure to clear hung CCB, but uses next available circuit to route call.
Option 4: Change Call Agent mode from MRU to LRU. This option does not provide a procedure to clear hung CCB, but uses next available circuit to route call.
All Release 5.3, 5.4, 5.5.0 and Release 18.104.22.168
Release 5.5.10 and Release 22.214.171.124(to be released soon)
To follow the bug ID link below and see detailed bug information, you must be a registered customer and you must be logged in.
DDTS CSCsx71996 (registered customers only) CSCtg22966 (registered customers only)
For More Information
If you require further assistance, or if you have any further questions regarding this field notice, please contact the Cisco Systems Technical Assistance Center (TAC) by one of the following methods:
Receive Email Notification For New Field Notices
Cisco Notification Service—Set up a profile to receive email updates about reliability, safety, network security, and end-of-sale issues for the Cisco products you specify.