Caution The use of the UNIX
ifconfig down command on any signaling interface to test or troubleshoot network or interface failures of the Cisco BTS 10200 Softswitch Signaling Interface may lead to undesirable consequences or conditions.

Note The following billing records are created when a call is rejected due to overload conditions:· SS7 termination cause code 42· Cable signaling stop event cause code "resource unavailable"Calls rejected by the signaling adapter will not generate a billing record.

Signaling Events and Alarms

This section provides a brief overview of the signaling events and alarms for the BTS 10200 in numerical order. Table 10-1 lists all of the signaling events and alarms by severity.

Note Click the signaling message number in Table 10-1 to display information about the event or alarm.

Verify that the gateway is both configured for service and that it has been set in service.

SECONDARYACTION

Attempt to ping the gateway using the Internet Protocol (IP) address from the event report. If the ping is not successful, then diagnose the issue that prevents the address from being reached.

TERNARYACTION

Use the status media gateway (MGW) identification (ID) = xxx, where xxx is the IP address given in the event report. If the status is not in service (INS), then use the control mgw command to put it in service.

Issued when the specified SS7 link has experienced a processor outage.

PRIMARYACTION

Monitor the system for maintenance event reports associated with the signaling adapter or the underlying platform instances that support the specified SS7 link. Verify that the process and or platform are restarted and returned to service.

Issued when the specified destination point code (DPC) is not available. This is usually caused by one of the following:1) A failure in the affected DPC.2) An unavailable route between the BTS 10200 and the affected DPC.

PRIMARYACTION

Verify that an alternate routing has been assigned for traffic destined to the affected DPC.

Issued when a BLO or CGB message was received on the specified CIC if it is SS7 trunk. Issued when a SERVICE OOS message is received for Integrated Services Digital Network (ISDN) trunks. Issued when Reverse Make Busy (RBZ) signal is received for channel-associated signaling (CAS) operator trunk.

PRIMARYACTION

No action required. Can manually recover from this condition locally by controlling the effected trunks to the unequipped (UEQP) state and back to the INS state.

This could have been caused by: (1) The trunking gateway has been administratively taken to the OOS state using the CLI command in the gateway (GW). (2) The trunk endpoint is alarmed or in the OOS state.

PRIMARYACTION

(1) Fix the trunking gateway state that has been administratively taken to the INS state using the CLI command in the GW. (2) Fix the trunk endpoint alarms.

SIGNALING (72)

Integrated Services Digital Network-Calls Lost Due to D-channel Down for Period of Time (ISDN-Calls Lost Due to D-channel Down for Period of Time)

SEVERITY

WARNING

THRESHOLD

100

THROTTLE

0

DATAWORDS

Trunk Group ID-FOUR_BYTESTrunk Group Index-FOUR_BYTES

PRIMARYCAUSE

The ISDN signaling adapter has lost calls due to a D-channel being down as a result of a media gateway power loss or a loss of the connection between the private branch exchange (PBX) and the media gateway.

PRIMARYACTION

Resupply power to the media gateway and verify that the connection between the PBX and the media gateway is intact.

This is a result of either a software bug or bad message being received-a message with a valid message type but an invalid field within the message. Snoop the message from the endpoint and verify it's content or call Cisco TAC. (Contact Cisco TAC.)

The password on the BTS 10200 and/or the gatekeeper is wrong-the H323 gateway (H323GW) table may not be provisioned properly or there is a time synchronization problem between the BTS 10200 and/or gatekeeper and the Network Time Protocol (NTP) server. Ensure that both the BTS 10200 and the gatekeeper are pointing to the same NTP server.

The H323 application processes has depleted its resources. No more calls can be completed.

PRIMARYACTION

The high water mark has been reached-all new call requests are rejected until the low water mark is reached. Reprovision the water marks or check the network for overload. Also verify that alternate routes have been provisioned on the BTS 10200.

SIGNALING (113)

Note When a port on a ITP is removed from service using the shut command, multiple Signaling 113 and 114 alarms are raised (ON status). When the port is recovered by cycling the ITP power, all alarms raised are cleared (OFF status) and are removed from CURRENT_ALARM table. However, not all cleared alarms (OFF status) are displayed on the subscriber terminal. Only the first instance of the cleared alarms (OFF status) with a variation in TYPE, NUMBER, and COMPONENT-ID are displayed. Multiple instances of the cleared alarms (OFF status) where the TYPE, NUMBER, and COMPONENT-ID are identical are not displayed.

DESCRIPTION

Signaling Gateway Failure

SEVERITY

MAJOR

THRESHOLD

100

THROTTLE

0

DATAWORDS

Signaling Gateway ID-STRING [17]

PRIMARYCAUSE

All of the associated signaling gateway processes are out-of-service.

PRIMARYACTION

Determine why each of the associated SGP processes is out-of-service (see the SGP alarm definition).

SIGNALING (114)

Note When a port on a ITP is removed from service using the shut command, multiple Signaling 113 and 114 alarms are raised (ON status). When the port is recovered by cycling the ITP power, all alarms raised are cleared (OFF status) and are removed from CURRENT_ALARM table. However, not all cleared alarms (OFF status) are displayed on the subscriber terminal. Only the first instance of the cleared alarms (OFF status) with a variation in TYPE, NUMBER, and COMPONENT-ID are displayed. Multiple instances of the cleared alarms (OFF status) where the TYPE, NUMBER, and COMPONENT-ID are identical are not displayed.

DESCRIPTION

Signaling Gateway Process is Out-of-Service

SEVERITY

MAJOR

THRESHOLD

100

THROTTLE

0

DATAWORDS

Signaling Gateway-STRING [17]

PRIMARYCAUSE

All of the SCTP associations between the SGP and the CA are out-of-service.

PRIMARYACTION

See the SCTP association alarm definition to determine how to rectify the problem.

SECONDARYCAUSE

The M3UA layer is down between the CA and the SGP.

SECONDARYACTION

Use the Cisco snooper utility to determine why M3UA layer is down. Also see the log for additional information.

An ISUP message or a parameter received was not recognized or understood.

PRIMARYACTION

Check the log for more information (including confusion (CFN) diagnostic output). Capture a SS7 trace of the affected circuits. If the diagnostic data indicates that messages or parameters that must be supported are being dropped, refer the captured data to support along with a description of the call scenario.

The system configuration and the traffic load have caused the number of open connections to approach the engineered limit. This limit will need to be increased to allow for more connections. Please contact Cisco support. (Contact Cisco TAC.)

Issued when the BTS 10200 is unable to communicate with a remote SIP party (Call-Agent or Proxy) over a SIP or a SIP-T trunk.

PRIMARYACTION

Verify that the DNS resolution exists, if TSAP address of the remote entity is a domain name. Verify that the remote entity is reachable by Internet Control Message Protocol (ICMP) ping, using the Trunk TSAP address from the Event Report. If the same alarm is reported on all the softswitch trunk groups, verify that the network connection is operational.

SECONDARYCAUSE

The remote SIP party is not operational.

SECONDARYACTION

If the ping is not successful, then diagnose the issue that prevents the TSAP address from being reached. Verify that the SIP application is running on the remote host and is listening on the port specified in the TSAP address.

SIP request: All retransmission attempts for a SIP request failed for the DNS or the IP address of request uniform resource identifier (URI). SIP response: All retransmission attempts for a SIP response failed for the received socket IP address of the request and the DNS (or the IP address) listed in the header.

PRIMARYACTION

Ensure that if DNS server is up and running for the host name resolution and is provisioned properly to resolve the correct order of the IP addresses. Ensure that the previous hop network component is alive and in a healthy state for failures related to the SIP responses.

The residential gateway returned an error code in response to a command from the MGW.

PRIMARYACTION

Try controlling subscriber termination to OOS and back to INS using the BTS 10200 CLI command. If the problem persist after more calls, check the configuration in the BTS 10200 and the RGW. If the error codes returned by the MGW are harmless, it can be suppressed by adding a new entry in MGCP-RETCODE-ACTION table and by changing the EP-ACTION to RESET/NONE.

SIGNALING (161)

Session Initiation Protocol Update not Allowed for Operator Service Position System Calls (SIP Update not Allowed for OSPS Calls)

SEVERITY

WARNING

THRESHOLD

100

THROTTLE

0

DATAWORDS

Trunk Group Description-STRING [21]TSAP Address-STRING [65]

PRIMARYCAUSE

The remote switch does not allow the BTS 10200 to send SIP UPDATE messages. The UPDATE message is mandatory in CMSS and is used exclusively by the BTS 10200 for operator service calls over SIP including BLV, emergency interrupt, and 911 ringback calls.

PRIMARYACTION

Upgrade or re-provision the remote switch so it can process incoming SIP UPDATE messages.

SIGNALING (162)

Session Initiation Protocol Server Group Element Operationally Out of Service (SIP Server Group Element Operationally out of Service)

SEVERITY

CRITICAL

THRESHOLD

100

THROTTLE

0

DATAWORDS

Server Group Description-STRING [64]TSAP Address of the SIP-Element.-STRING [64]

PRIMARYCAUSE

Issued when the BTS 10200 is unable to communicate with a remote SIP party (Call-Agent or Proxy) over a SIP server group element.

PRIMARYACTION

If the TSAP address of the remote entity is a domain name, verify that the DNS resolution exists. Verify that the remote entity is reachable by ICMP ping, using the TSAP address from the Event Report. If the same alarm is reported for other TSAP addresses on several softswitch trunk groups and/or server-group elements, then verify that the network connection is operational.

SECONDARYCAUSE

The remote SIP party is not operational.

SECONDARYACTION

If the ping is not successful, then diagnose the issue that prevents the TSAP address from being reached. Verify that the SIP application is running on the remote host and listening on the port specified in the TSAP address.

SIGNALING (168)

A Session Initiation Protocol Server Group has no Child Elements Provisioned (A SIP Server Group has no Child Elements Provisioned)

SEVERITY

WARNING

THRESHOLD

100

THROTTLE

0

DATAWORDS

Server Group ID-STRING [64]

PRIMARYCAUSE

Issued when a SIP Server Group administrative in-service is provisioned but has no child elements provisioned.

PRIMARYACTION

This Server Group will be considered as if it is administrative out of service. If that is acceptable, then no action required. If the server group was expected to be workable, then place the server group back out of service, resolve the provisioning problem, and place back into service.

The BTS 10200 does not receive the Service Ack from the remote end in response to Service message to make the D-Channel active.

PRIMARYACTION

Verify that the NFAS provisioning at the PBX/media gateway is correct.

Monitoring Signaling Events

This section provides the information needed to monitor and correct signaling events. Table 10-2 lists all of the signaling events in numerical order and provides cross reference to each subsection in this section.

Test Report—Signaling (1)

The Test Report event is for testing the signaling event category. The event is informational and no further action is required.

Invalid Message Received—Signaling (4)

The Invalid Message Received event serves as a warning that an invalid message has been received. The primary cause of the event is that a signaling adapter has received an invalid message from the specified endpoint. To correct the primary cause of the event, monitor the associated signaling link to see if there is an interruption of service on the link. If there is a communication problem, restart the link. Verify that the version of the protocol used by the device at the endpoint is consistent with the version expected by the call agent. If there is a mismatch, then either the endpoint or call agent must be re-provisioned.

Database Module Function Call Failure—Signaling (6)

The Database Module Function Call Failure event serves as a warning that a database module function call has failed. The primary cause of the event is that a signaling adapter has detected an error while accessing a database interface. To correct the primary cause of the event, restart the associated process if the database that the adapter attempted to access is not available. If incompatible versions of the signaling adapter process and the database processes are present on the system, correct the error and restart the processes.

Socket Failure—Signaling (7)

The Socket Failure alarm (major) indicates that there is a failure in creating/binding to the UDP socket. To troubleshoot and correct the cause of the Socket Failure alarm, refer to the "Socket Failure—Signaling (7)" section.

Link: Local Processor Outage—Signaling (17)

The Link: Local Processor Outage alarm (minor) indicates that the SS7 link has experienced a local processor outage. To troubleshoot and correct the cause of the Link: Local Processor Outage alarm, refer to the "Link: Local Processor Outage—Signaling (17)" section.

Link Set Congestion—Signaling (20)

The Link Set Congestion alarm (major) indicates that the specified SS7 link set is congested. To troubleshoot and correct the cause of the Link Set Congestion alarm, refer to the "Link Set Congestion—Signaling (20)" section.

Route Set Failure—Signaling (21)

The Route Set Failure alarm (major) indicates that the specified route set has a experienced a failure. To troubleshoot and correct the cause of the Route Set Failure alarm, refer to the "Route Set Failure—Signaling (21)" section.

Route Set Congested—Signaling (22)

The Route Set Congested alarm (minor) indicates that the specified route set is congested. To troubleshoot and correct the cause of the Route Set Congested alarm, refer to the "Route Set Congested—Signaling (22)" section.

Unanswered Blocking Message—Signaling (25)

The Unanswered Blocking Message event serves as a warning that a BLO message was not answered. The primary cause of the event is that a BLO message was not acknowledged before the T13 expired for the associated CIC. To correct the primary cause of the event, verify that the SS7 signaling adapter processes is running normally. Verify that the call agent platform is active. Verify that the SS7 interface hardware is in service. Verify that the associated SS7 signaling link is available. Verify that the T13 timer is set to an appropriate level. Verify that the SS7 link is not congested.

Unanswered Unblocking Message—Signaling (26)

The Unanswered Unblocking Message event serves as a warning that an UBL message was not answered. The primary cause of the event is that a UBL message was not acknowledged before the T15 expired for the associated CIC. To correct the primary cause of the event, verify that the SS7 signaling adapter processes is running normally. Verify that the call agent platform is active. Verify that the SS7 interface hardware is in service. Verify that the associated SS7 signaling link is available. Verify that the T13 timer is set to an appropriate level. Verify that the SS7 link is not congested.

Unanswered Circuit Group Blocking Message—Signaling (27)

The Unanswered Circuit Group Blocking Message event serves as a warning that a CGB message was not answered. The primary cause of the event is that a CGB message was not acknowledged before the T19 expired for the associated CIC. To correct the primary cause of the event, verify that the SS7 signaling adapter processes is running normally. Verify that the call agent platform is active. Verify that the SS7 interface hardware is in service. Verify that the associated SS7 signaling link is available. Verify that the T13 timer is set to an appropriate level. Verify that the SS7 link is not congested.

Unanswered Circuit Group Unblocking Message—Signaling (28)

The Unanswered Circuit Group Unblocking Message event serves as a warning that a CGU message was not answered. The primary cause of the event is that a CGU message was not acknowledged before the T21 expired for the associated CIC. To correct the primary cause of the event, verify that the SS7 signaling adapter processes is running normally. Verify that the call agent platform is active. Verify that the SS7 interface hardware is in service. Verify that the associated SS7 signaling link is available. Verify that the T13 timer is set to an appropriate level. Verify that the SS7 link is not congested.

Unanswered Circuit Query Message—Signaling (29)

The Unanswered Circuit Query Message event serves as a warning that a CQM message was not answered. The primary cause of the event is that a CQM message was not acknowledged before the T28 expired for the associated CIC. To correct the primary cause of the event, verify that the SS7 signaling adapter processes is running normally. Verify that the call agent platform is active. Verify that the SS7 interface hardware is in service. Verify that the associated SS7 signaling link is available. Verify that the T13 timer is set to an appropriate level. Verify that the SS7 link is not congested.

Unanswered Circuit Validation Test Message—Signaling (30)

The Unanswered Circuit Validation Test Message event serves as a warning that a CVT message was not answered. The primary cause of the event is that a CVT message was not acknowledged before the Tcvt expired for the associated CIC. To correct the primary cause of the event, verify that the SS7 signaling adapter processes is running normally. Verify that the call agent platform is active. Verify that the SS7 interface hardware is in service. Verify that the associated SS7 signaling link is available. Verify that the T13 timer is set to an appropriate level. Verify that the SS7 link is not congested.

Unanswered Reset Circuit Message—Signaling (31)

The Unanswered Reset Circuit Message event serves as a warning that a RSC message was not answered. The primary cause of the event is that a RSC message was not acknowledged before the T17 expired for the associated CIC. To correct the primary cause of the event, verify that the SS7 signaling adapter processes is running normally. Verify that the call agent platform is active. Verify that the SS7 interface hardware is in service. Verify that the associated SS7 signaling link is available. Verify that the T13 timer is set to an appropriate level. Verify that the SS7 link is not congested.

Unanswered Group Reset Message—Signaling (32)

The Unanswered Group Reset Message event serves as a warning that a GRS message was not answered. The primary cause of the event is that a a GRS message was not acknowledged before the T23 expired for the associated CIC. To correct the primary cause of the event, Verify that the SS7 signaling adapter processes is running normally. verify that the call agent platform is active. Verify that the SS7 interface hardware is in service. Verify that the associated SS7 signaling link is available. Verify that the T13 timer is set to an appropriate level. Verify that the SS7 link is not congested.

Unanswered Release Message—Signaling (33)

The Unanswered Release Message event serves as a warning that a REL message was not answered. The primary cause of the event is that a REL message was not acknowledged before the T5 expired for the associated CIC. To correct the primary cause of the event, verify that the SS7 signaling adapter processes is running normally. Verify that the call agent platform is active. Verify that the SS7 interface hardware is in service. Verify that the associated SS7 signaling link is available. Verify that the T13 timer is set to an appropriate level. Verify that the SS7 link is not congested.

Unanswered Continuity Check Request Message—Signaling (34)

The Unanswered Continuity Check Request Message event serves as a warning that a continuity check request (CCR) message was not answered. The primary cause of the event is that a LPA message was not acknowledged before the TCCR expired for the associated CIC. To correct the primary cause of the event, verify that the SS7 signaling adapter processes is running normally. Verify that the call agent platform is active. Verify that the SS7 interface hardware is in service. Verify that the associated SS7 signaling link is available. Verify that the T13 timer is set to an appropriate level. Verify that the SS7 link is not congested.

The Continuity Testing Message Received on the Specified Circuit Identification Code event functions as an informational alert that the COT message was received on the specified CIC. The event is informational and no further action is required.

Release Complete Received in Response to Reset Circuit Message on the Specified Circuit Identification Code—Signaling (43)

The Release Complete Received in Response to Reset Circuit Message on the Specified Circuit Identification Code event functions as an informational alert that the RLC was received in response to the RSC message received on the specified CIC. The event is informational and no further action is required,

Continuity Recheck is Performed on Specified Circuit Identification Code—Signaling (44)

The Continuity Recheck is Performed on Specified Circuit Identification Code event functions as an informational alert that a continuity recheck was performed on the specified CIC. The event is informational and further action is required.

Circuit is UNEQUIPPED on Remote Side—Signaling (45)

The Circuit is UNEQUIPPED on Remote Side event functions as an informational alert the circuit is unequipped on the remote side. The primary cause of the event is that an unequipped circuit has been detected on the remote side. To correct the primary cause of the event, monitor the event reports at the network level to verify if an existing circuit was unequipped causing a status mismatch with the local end.

Specified Circuit Identification Code is Invalid for the Operation—Signaling (46)

The Specified Circuit Identification Code is Invalid for the Operation event functions as an informational alert that the specified CIC in invalid for the attempted operation. The primary cause of the event is that an invalid operation was performed on the specified CIC. To correct the primary cause of the event, verify that the SS7 provisioning tables are properly configured at the circuit level.

A General Processing Error Encountered—Signaling (49)

The A General Processing Error Encountered event functions as a informational alert that a general processing error has occurred. The primary cause of the event is that a general SS7 processing error occurred due to all resources being busy or an invalid event occurring. To correct the primary cause of the event, verify the status of the signaling adapter process and the SS7 signaling interface to verify proper operation.

Unexpected Message for the Call State is Received: Clear Call—Signaling (50)

The Unexpected Message for the Call State is Received: Clear Call event functions as an informational alert that an unexpected message for the call state has been received. The primary cause of the even is that an unexpected message was received for the current call state. To correct the primary cause of the event, verify the status of the signaling adapter process and the SS7 signaling interface to verify proper operation.

Set Trunk State as Remotely Unequipped—Signaling (51)

The Set Trunk State as Remotely Unequipped event functions as an informational alert that the trunk state is currently set as remotely unequipped. The primary cause of the event is that the specified CIC is marked at remotely unequipped due to the CQM response indicating that it is unequipped at the far end. To correct the primary cause of the event, equip the trunk circuit at the far end.

Set Trunk State as NOT Remotely Blocked—Signaling (52)

The Set Trunk State as NOT Remotely Blocked event functions as an informational alert that the trunk state has been set as not remotely blocked. The primary cause of the event is that the specified CIC is marked as not remotely blocked due to the CQM response indicating that it is not remotely blocked at the far end. The event is informational and no further action is required.

Set Trunk State as Remotely Blocked—Signaling (53)

The Set Trunk State as Remotely Blocked event functions as an informational alert that the trunk state is set as remotely blocked. The primary cause of the event is that the specified CIC is marked as remotely blocked due to the CQM response indicating that it is remotely blocked at the far end. To correct the primary cause of the event, clear the blocking situation at the far end based on network level event reports.

Circuit Validation Test Aborted—Signaling (54)

The Circuit Validation Test Aborted event functions as an informational alert that the circuit validation test has been aborted. The primary cause of the event is that the circuit specified failed a validation test due to an internal failure. To correct the primary cause of the event, verify the SS7 signaling adapter process and SS7 interface is operating normally.

Circuit Validation Successful—Signaling (55)

The Circuit Validation Successful event functions as an informational alert that the circuit validation was successful. The event is informational and no further actions is required.

Continuity Recheck Failed—Signaling (57)

The Continuity Recheck Failed event functions as an informational alert that the continuity recheck failed. The primary cause of the event is that a continuity recheck of the specified CIC failed. To correct the primary cause of the event, verify the SS7 signaling adapter process and SS7 interface is operating normally.

Continuity Recheck Successful—Signaling (58)

The Continuity Recheck Successful event functions as an informational alert that the continuity recheck of the specified CIC was successful. The event is informational and no further action is required.

The Integrated Services Digital Network STATUS Message Containing Error Indication Received event functions as a warning that an ISDN status message containing an error indication has been received. The primary cause of the event is that an ISDN status message was received containing an error indication for the specified termination. To correct the primary cause of the event, place the specified termination in service state if the specified termination is not operating normally.

Trunk Operational State Changed by Service Message—Signaling (61)

The Trunk Operational State Changed by Service Message event functions as an informational alert that the trunk operational state was changed by a service message. The primary cause of the event is that the specified trunk group operational status was changed via a service message from the specified gateway. To correct the primary cause of the event, monitor the event reports at the network level to verify that the specified gateway and terminations are operating normally.

The Received Integrated Services Digital Network RESTART Message event functions as an informational alert that a ISDN restart message was received. The primary cause of the event is that an ISDN restart message was received from the specified gateway. To correct the primary cause of the event, monitor the event reports at the network level to verify that the specified gateway and terminations are operating normally.

Media Gateway/Termination Faulty—Signaling (63)

The Media Gateway/Termination Faulty alarm (major) indicates that a media gateway or termination has gone faulty due to the detection of an unknown endpoint, unknown package type, and unknown event, a hardware failure, or a general call agent error. To troubleshoot and correct the cause of the Media Gateway/Termination Faulty alarm, refer to the "Media Gateway/Termination Faulty—Signaling (63)" section.

The Media Gateway Adapter Running out of Shared Memory Pools alarm (critical) indicates that the MGCP signaling adapter was unable to allocate data store for an IPC message due to a lack of resources. To troubleshoot and correct the cause of the Media Gateway Adapter Running out of Shared Memory Pools alarm, refer to the "Media Gateway Adapter Running out of Shared Memory Pools—Signaling (64)" section.

Media Gateway Adapter Running out of Heap Memory—Signaling (65)

The Media Gateway Adapter Running out of Heap Memory alarm (critical) indicates that the MGCP signaling adapter was unable to allocate data store for an IPC message from the heap due to a lack of resources. To troubleshoot and correct the cause of the Media Gateway Adapter Running out of Heap Memory alarm, refer to the "Media Gateway Adapter Running out of Heap Memory—Signaling (65)" section.

The Integrated Services Digital Network Unable to Restore D-channel Due to Failed Communication event serves as a warning that the ISDN signaling adapter is unable to restore D-channel due to a communication failure. The primary cause of the event is that the ISDN signaling adapter is unable to restore a D-channel due to incorrect backhaul provisioning at the media gateway or call agent. To correct the primary cause of the event, ensure the provisioning of the backhaul port is correct at both the call agent and media gateway.

The Integrated Services Digital Network Unable to Establish D-channel event serves as a warning that the ISDN signaling adaptor is unable to establish D-channel. The primary cause of the event is that ISDN signaling adapter is unable to establish a D-channel due to layer 1 parameters not being provisioned correctly or improper provisioning of the network or user side. To correct the primary cause of the event, verify the correct provisioning at the media gateway.

Integrated Services Digital Network-Calls Lost Due to D-channel Down for Period of Time—Signaling (72)

The Integrated Services Digital Network-Calls Lost Due to D-channel Down for Period of Time event serves as a warning that calls were lost due to the D-channels being down for a period of time. The primary cause of the event is that ISDN signaling adapter has lost calls due to a D-channel being down as a result of a media gateway power loss or a loss of connection between the PBX and media gateway. To correct the primary cause of the event, resupply power to the media gateway and verify that the connection between the PBX and media gateway is intact.

The Integrated Services Digital Network-Unable to Send RESTART Due to RESTART Timer Expired event serves as a warning that the ISDN signaling adapter was unable to send a restart due to the restart timer being expired. The primary cause of the event is that the ISDN signaling adapter was unable to send a RESTART message due to the expiration of the RESTART timer. To correct the primary cause of the event, verify that the RESTART timer is set to an appropriate level.

Integrated Services Digital Network: Unable to Send the SERVICE Due to the SERVICE Timer Expired—Signaling (74)

The Integrated Services Digital Network: Unable to Send the SERVICE Due to the SERVICE Timer Expired event serves as a warning that the ISDN signal adapter was unable to send a service message due to the service timer being expired. The primary cause of the event is that the ISDN signaling adapter was unable to send a SERVICE message due to the expiration of the SERVICE timer. To correct the primary cause of the event, ensure that the RESTART timer is set to an appropriate level.

Timeout on Remote Instance—Signaling (76)

The Timeout on Remote Instance event functions as an informational alert that communication on a remote instance timed out. The primary cause of the event is that communication between call agent and remote instance is faulty. The event is informational and no further action is required.

The Integrated Services Digital Network D-channel Switchover for Non-Facility Associated Signaling event functions as an informational alert that an ISDN D-channel switchover has occurred non-facility associated signaling (NFAS). The primary cause of the event is that the operator manually switched the D-channels using the CLI. To verify the primary cause of the event, verify operator action. The secondary cause of the event is that the active D-channel was lost. To correct the secondary cause of the event, verify that gateway is operational and connection to PBX is good.

Trunking Gateway Unreachable—Signaling (79)

The Trunking Gateway Unreachable alarm (major) indicates that the trunking gateway is not responding to keep-alive Audit Endpoint messages. To troubleshoot and correct the cause of the Media Gateway Unreachable alarm, refer to the "Trunking Gateway Unreachable—Signaling (79)" section.

Reached Maximum Socket Limit—Signaling (84)

The Reached Maximum Socket Limit alarm (critical) indicates that the BTS 10200 system has reached the maximum socket limit. To troubleshoot and correct the cause of the Reached Maximum Socket Limit alarm, refer to the "Reached Maximum Socket Limit—Signaling (84)" section.

Initialization Failure—Signaling (85)

The Initialization Failure alarm (critical) indicates that the BTS 10200 system failed to initialize. To troubleshoot and correct the cause of the Initialization Failure alarm, refer to the "Initialization Failure—Signaling (85)" section.

Gatekeeper not Available/Reachable—Signaling (89)

The Gatekeeper not Available/Reachable alarm (major) indicates that the gatekeeper is not available or the gatekeeper is not reachable. To troubleshoot and correct the cause of the Gatekeeper not Available/Reachable alarm, refer to the "Gatekeeper not Available/Reachable—Signaling (89)" section.

Invalid Call Identifier—Signaling (92)

The Invalid Call Identifier alarm (minor) indicates that the Call ID was invalid or changed mid-call. To troubleshoot and correct the cause of the Invalid Call Identifier alarm, refer to the "Invalid Call Identifier—Signaling (92)" section.

Invalid Message from the Network—Signaling (95)

The Invalid Message from the Network alarm (minor) indicates that an unsupported or invalid message type was received from network. To troubleshoot and correct the cause of the Invalid Message from the Network alarm, refer to the "Invalid Message from the Network—Signaling (95)" section.

H323 Protocol Inconsistencies—Signaling (98)

The H323 Protocol Inconsistencies alarm (minor) indicates that the H323 endpoint and BTS 10200 are running different protocol versions. To troubleshoot and correct the cause of the H323 Protocol Inconsistencies alarm, refer to the "H323 Protocol Inconsistencies—Signaling (98)" section.

Abnormal Call Clearing—Signaling (99)

The Abnormal Call Clearing alarm (minor) indicates that an unsupported or invalid message type was received from network. To troubleshoot and correct the cause of the Abnormal Call Clearing alarm, refer to the "Abnormal Call Clearing—Signaling (99)" section.

H323 Network Congested—Signaling (102)

The H323 Network Congested alarm indicates (minor) that the H323 application process has depleted its resources and no more calls can be completed. To troubleshoot and correct the cause of the H323 Network Congested alarm, refer to the "H323 Network Congested—Signaling (102)" section.

Aggregation Unable To Establish Connection—Signaling (104)

The Aggregation Unable To Establish Connection event functions as an informational alert that the AGGR is unable to establish a connection. The primary cause of the event is that the TCP connection failed to establish. To correct the primary cause of the event, check the IP Connectivity of CA and CMTS.

Aggregation Gate Set Failed—Signaling (105)

The Aggregation Gate Set Failed event functions as an informational alert that the AGGR gate set failed. The primary cause of the event is that the gate set acknowledgement never came from the CMTS. The event is informational and no further action is required.

Invalid Routing Context Received—Signaling (115)

The Invalid Routing Context Received event serves as a warning that an invalid routing context was received. The primary cause of the event is that the routing context was configured improperly on the CA or the SG. To correct the primary cause of the event, reconfigure the routing context on the CA or the SG so that the routing context matches in both places.

The Transaction Capabilities Application Part Reaches the Provisioned Resource Limit event serves as a warning that the TCAP process has reached or reaches the provisioned resource limit. The primary cause of the event is that the TCAP process runs out of all of the pre-configured dialogue IDs or invoke IDs. To correct the primary cause of the event, increase the number pre-configured dialogue IDs or invoke IDs.

Unable to Decode Generic Transport Descriptor Message—Signaling (133)

The Unable to Decode Generic Transport Descriptor Message event functions as an informational alert that a GTD message could not be decoded. The primary cause of the event is that the GTD parser failed to decode a GTD message received from the specified endpoint. To correct the primary cause of the event, verify that the version of the GTD protocol used by the device at the remote endpoint is consistent with the version expected by the call agent. Examine the associated signaling link to see if there is any interruption of the supplementary services on the link.

Signaling System 7 Message Encoding Failure—Signaling (134)

The Signaling System 7 Message Encoding Failure event functions as an informational alert that a SS7 message encoding failed. The primary cause of the event is that there was an error in the ISUP stack or the SAI message. To correct the primary cause of the event, capture a SS7 trace of the circuit for examination by Cisco TAC.

Signaling System 7 Message Decoding Failure—Signaling (135)

The Signaling System 7 Message Decoding Failure event functions as an informational alert that the decoding of a SS7 message failed. The primary cause of the event is that an error occurred in the ISUP stack or the SAI message. To correct the primary cause of the event, capture a SS7 trace of the circuit for examination by Cisco TAC.

Signaling System 7 Message Invalid Received—Signaling (136)

The Signaling System 7 Message Invalid Received event functions as an informational alert that an invalid SS7 message was received. The primary cause of the event is that an invalid message was received from the line in the ISUP stack. To correct the primary cause of the event, verify the SSP sending the message to the CA is correctly configured. Capture a SS7 trace of the circuit for examination by Cisco TAC.

Signaling System 7 Confusion Message Received—Signaling (137)

The Signaling System 7 Confusion Message Received event functions as an informational alert that the received SS7 message was confused. The primary cause of the event is that an ISUP message or parameter received was not recognized or understood. To correct the primary cause of the event, check the log for more information (including CFN diagnostic output). Capture SS7 trace of affected circuits. If diagnostic data indicates messages/parameters that must be supported are being dropped, refer the captured data to Cisco TAC along with a description of the call scenario.

Number of Open Session Initiation Protocol Connections is Reaching Engineered Limit—Signaling (138)

The Number of Open Session Initiation Protocol Connections is Reaching Engineered Limit event functions as an informational alert that the number of open SIP connections is reaching the engineered limit. The primary cause of the event is that the call failed or a feature is not available. To correct the primary cause of the event, is to increase the engineered limit to allow for more open connections. System configuration and traffic load have caused the number of open connections to approach the engineered limit. Contact Cisco TAC for assistance in increasing in the limit.

Signaling System 7 Trunk was Found to be in Erroneous State—Signaling (139) (SS7)

The Signaling System 7 Trunk was Found to be in Erroneous State event functions as an informational alert that a SS7 trunk was found to be in an erroneous state. The primary cause of the event is that a discrepancy exists between the local and the remote trunk states. The corrective action is automatically enforced when using ANSI ISUP.

Unanswered Information Message—Signaling (140)

The Unanswered Information Message event functions as an informational alert that an INF message has not been answered. The primary cause of the event is that the far-end switch is not responding to INF message with an INR message. To correct the primary cause of the event, verify that the far-end switch can correctly respond to an INF message.

Address not Resolved by Domain Name System Server—Signaling (141)

The Address not Resolved by Domain Name System Server event serves as a warning that an address was not resolved by the DNS server. The primary cause of the event is that the TSAP address/hostname is not defined in the DNS. To correct the primary cause of the event, add an entry for TSAP address to the DNS server or fix the BTS 10200 provisioning.

Following tips may help troubleshoot NLP/DNS related issues.

•Grep for GET_HOST_BY_NAME keyword in the traces at INFO3 trace level.

The All Retransmission Attempts of Session Initiation Protocol Request or Response Failed event serves as a warning the all retransmission attempts of a SIP request or response failed. The primary cause of the event is that all retransmission attempts for a SIP request failed for a DNS or an IP address of the request URI or all retransmission attempts for a SIP response failed for the received socket IP address of the request and the DNS (or IP address). To correct the primary cause of the event, ensure that the DNS server is up and running for host name resolution and provisioned properly to resolve to correct order of IP addresses and ensure that previous hop network component is alive and in a healthy state for failures related to SIP responses.

Domain Name System Service Addresses Exhausted—Signaling (147)

The Domain Name System Service Addresses Exhausted event serves as a warning that all DNS SRV addresses are exhausted. The primary cause of the event is that the DNS SRV hostname resolution to IP address is exhausted. To correct the primary cause of the event, add an entry to the SRV in the DNS server and fix the BTS 10200 provisioning.

Subscriber Line Faulty—Signaling (151)

The Subscriber Line Faulty alarm (minor) indicates that the residential gateway returned an error code in response to a command from the MGW. To troubleshoot and correct the cause of the Subscriber Line Faulty alarm, refer to the "Subscriber Line Faulty—Signaling (151)" section.

Termination Transient Error Received—Signaling (152)

The Termination Transient Error Received event functions as an informational alert that a termination transient error was received. The primary cause of the event is that the MGCP signaling process has inter-operational errors. To correct the primary cause of the event, notify Cisco TAC.

Packet Cable Multi-Media Unsolicited Gate Delete—Signaling (155)

The Packet Cable Multi-Media Unsolicited Gate Delete event serves as an informational alert that an error condition was encountered by the CMTS. To correct the cause of the event, check the alarms and warnings from the CMTS.

The Invalid Integrated Services Digital Network Interface Identification event serves as a warning that an interface ID is not configured correctly on the ISDN gateway side. To correct the cause of the event, configure the D-channel correctly on the gateway side. The D-channel configuration on the call-agent side should match with that on the gateway side.

The Integrated Services Digital Network User Adaptation Layer can not Go Active event serves as a warning that no ACTIVE acknowledgement messages are being received from any signaling gateway. This indicates that the ISDN signaling gateway or the SCTP associations are probably down. To correct the cause of the event, investigate other alarms to see if the signaling gateways are down or to see if the SCTP associations are down. Take corrective action according to the alarm indications.

The Integrated Services Digital Network User Adaptation Layer can not Go Standby event serves as a warning that no ACTIVE acknowledgement messages are being received from any signaling gateway. This indicates that the ISDN signaling gateway or the SCTP associations are probably down. To correct the cause of the event, investigate other alarms to see if the signaling gateways are down or to see if the SCTP associations are down. Take corrective action according to the alarm indications.

Session Initiation Protocol Update not Allowed for Operator Service Position System Calls—Signaling (161)

The Session Initiation Protocol Update not Allowed for Operator Service Position System Calls event serves as a warning that the remote switch is not allowing the BTS 10200 to send SIP UPDATE messages. The UPDATE messages are mandatory in the CMSS and are used exclusively by the BTS 10200 for operator service calls over SIP including BLV, emergency interrupt, and 911 ringback calls. To correct the cause of the event, upgrade or re-provision the remote switch so it can process incoming SIP UPDATE messages.

Routing Key Inactive—Signaling (163)

The Routing Key Inactive alarm (major) indicates that INACTIVE acknowledgement messages were received from a Signaling Gateway. The SG or SCTP associations are probably down. To troubleshoot and correct the primary cause of the Routing Key Inactive alarm, refer to the "Routing Key Inactive—Signaling (163)" section.

Signaling Gateway Traffic Mode Mismatch—Signaling (164)

The Signaling Gateway Traffic Mode Mismatch alarm (major) indicates that the traffic mode does not match on the BTS 10200 and the Signaling Gateway. To troubleshoot and correct the primary cause of the Signaling Gateway Traffic Mode Mismatch alarm, refer to the "Signaling Gateway Traffic Mode Mismatch—Signaling (164)" section.

The No Session Initiation Protocol P-DCS Billing Information Header Received event serves as a warning that no SIP P-DCS billing information headers are being received. The primary cause of the event is that the originating switch is not provisioned to add the P-DCS-Billing-Info header to outgoing SIP requests and responses. To correct the primary cause of the event, provision the originating switch to add P-DCS-Billing-Info header to outgoing messages. The secondary cause of the event it that the header could have been stripped off by an intermediate proxy. To correct the secondary cause of the event, determine if the header has been stripped off by an intermediate proxy and configure the system for corrective action if so. The ternary cause of the event is that there was a SIP message encode error at the sending switch. To correct the ternary cause of the event, determine if a SIP message encode error occurred at the adjacent switch and if so, call the technical assistance center to determine a fix for the problem.

No Routing Keys are Active—Signaling (166)

The No Routing Keys are Active event serves as a warning that no routing keys are active. The primary cause of the event is that the routing keys are not controlled into ACTIVE state. To correct the primary cause of the event, control the routing keys to the ACTIVE state. The secondary cause of the event is that the ITP provisioning is incorrect. To correct the secondary cause of the event, check the ITP provisioning.

No Signaling Gateways are Active—Signaling (167)

The No Signaling Gateways are Active event serves as a warning that no signaling gateways are active. The primary cause of the event is that there is a communication problem between ITP and the BTS 10200. To correct the primary cause of the event, check the communication path between BTS 10200 and the ITP.

A Session Initiation Protocol Server Group has no Child Elements Provisioned—Signaling (168)

The A Session Initiation Protocol Server Group has no Child Elements Provisioned event is issued as a warning when a SIP Server Group administrative in-service is provisioned but has no child elements provisioned. This Server Group will be considered as if it is administrative out of service. If that is acceptable, then no action required. If the server group was expected to be workable, then place the server group back out of service, resolve the provisioning problem, and place back into service.

The Session Initiation Protocol Element Provisioned with Service Enabled is Internally Disabled event functions as an informational alert that a SIP element was provisioned with SRV enabled and is associated to at least one or more Server Groups. The SRV flag will be assumed disabled. However, to resolve this informational message, provision the SRV flag disabled on the SIP element.

Residential Gateway Endpoints are out of Service at the Gateway—Signaling (170)

No Resources Available to Launch ENUM Query—Signaling (176)

The No Resources Available to Launch ENUM Query alarm (critical) indicates that no resources are available to launch the ENUM query. The primary cause of the alarm is that there is internal or network congestion or that the server response is slow. To troubleshoot and correct the primary cause of the alarm, refer to the "No Resources Available to Launch ENUM Query—Signaling (176)" section.

The ISDN Unable to Restore D-Channel Into In-Service Active State warning event indicates that the BTS 10200 did not receive the Service Ack from the remote end in response to the Service message to make the D-Channel active. To correct the cause of the event, verify that the NFAS provisioning at the PBX/media gateway is correct.

Troubleshooting Signaling Alarms

This section provides the information needed to monitor and correct signaling alarms. Table 10-3 lists all of the signaling alarms in numerical order and provides cross reference to each subsection in this section.

Socket Failure—Signaling (7)

The Socket Failure alarm (major) indicates that there is a failure in creating/binding to the UDP socket. The primary cause of the alarm is that there is a failure in creating or binding to the UDP socket. To correct the primary cause of the alarm, verify that there is no conflict in port assignment with other processes in the system and ensure no previous instance of the same process is still running. The secondary cause of the alarm is that a software logic problem has occurred. To correct the secondary cause of the alarm, contact Cisco TAC.

Media Gateway Control Protocol

The Socket Failure alarm is issued when there is a failure in creating the UDP port used by the MGCP stacks. Some other application may already be active on the same UDP port and IP address to which the Call Agent MGCP stack is assigned. Reconfigure the MGCP stack to use a free UDP port.

Session Initiation Protocol

The Socket Failure alarm is issued when there is a failure in creating the UDP port used by the SIA process. Some other application may already be active on the same UDP port and IP address to which the SIA process is assigned. Reconfigure the SIA port to use a free port or the SIP default port 5060.

Session Initiation Protocol Message Receive Failure—Signaling (8)

The Session Initiation Protocol Message Receive Failure alarm (major) indicates that a SIP message receive has failed. The primary cause of the alarm is that Operating System level network errors have occurred or the network configuration is invalid. To correct the primary cause of the alarm, have the network administrator resolve the network errors. Contact Cisco TAC if you need assistance. Manually clear alarm. Restart this call agent instance using the platform start command.

Session Initiation Protocol

The SIP Message Receive Failure alarm is issued when SIP messages cannot be received. This could be due to port conflict (two processes attempting to use the same UDP port). Examine the "HOSTNAME" field in the alarm report to determine the IP address or domain name of the Call Agent that generated this alarm. Telnet into this Call Agent instance as a root user. In this Call Agent, configure another UDP port for the SIA process to avoid port conflict, by setting the SIA port in platform.cfg file to another port number. Call Cisco TAC if you need assistance. Restart this Call Agent instance using the platform start command.

Timeout on Internet Protocol Address—Signaling (9)

The Timeout on Internet Protocol Address alarm (major) indicates that an IP address has timed out. The alarm is issued when the OptiCall is unable to communicate with a gateway. To correct the primary cause of the alarm, verify that the gateway is both configured for service and that it has been set in service. Attempt to ping the gateway using the IP address from the Event Report. If the ping is not successful, then diagnose the issue that prevents the address from being reached. Use the Status MGW ID=xxx, where xxx is the IP address given in the Event Report. If the status is not INS, then use the control mgw command to put it in service.

Media Gateway Control Protocol

The Timeout on IP Address alarm is issued when the BTS 10200 is unable to communicate with a gateway. Verify that the gateway is both configured for service and that it has been set in service. Attempt to ping the gateway using the IP address from the Event Report. If the ping is not successful, then diagnose the issue that prevents the address from being reached. Use the Status MGW ID=xxx, where xxx is the IP address given in the Event Report. If the status is not INS, then use thecontrol mgwcommand to put it in service.

Session Initiation Protocol

The Timeout on IP Address alarm is issued when the Call Agent did not receive SIP response messages from Call Agent specified in the Event Report. The Call Agent has already taken thenecessary action to handle this situation by re-sending the SIP messages to the redundant IP address of the remote Call Agent.

The Failed to Send Complete Session Initiation Protocol Message alarm (minor) indicates that a SIP message failure has occurred. The primary cause of the alarm is that the SIP stack failed to send an SIP message due to it exceeding the maximum length of a UDP packet. To correct the primary cause of the alarm, the message should be captured on passive testing equipment and sent to Cisco TAC for evaluation if that alarm occurred during normal network operations.

The Failed to Allocate Session Initiation Protocol Control Block alarm (major) indicates that a SIP control block allocation failed. The primary cause of the alarm is that there is not enough memory to allocate a SIP Call Control Block. To correct the primary cause of the alarm, Increase the SIP CCB count specified in mem.cfg file and restart the Call Agent for the changes to take effect.

Feature Server is not Up or is not Responding to Call Agent—Signaling (12)

The Feature Server is not Up or is not Responding to Call Agent alarm (critical) indicates that the feature server is not up or is not responding to the call agent server. The primary cause of the alarm is that the feature server platform is down or is not operating properly. To correct the primary cause of the alarm, restart the applicable feature server.

Signaling System 7 Signaling Link Down—Signaling (13)

The Signaling System 7 Signaling Link Down alarm (major) indicates the SS7 signaling link is down. The primary cause of the alarm is that the SS7 trunk group may be out-of-service (OOS). To correct the primary cause of the alarm, use the control ss7-trunk-grp command to place the trunk group in service (INS). The secondary cause of the alarm is that the local Ulticom stack may be down. To correct the secondary cause of the alarm, run the Ulticom stack command again. The ternary cause of the alarm is that the SS7 link may be disconnected or faulty. To correct the ternary cause of the alarm, check the Ulticom local configuration. The subsequent cause of the alarm is that the remote SS7 signaling site may be down or incorrectly configured. To correct the subsequent cause of the alarm, check the Ulticom remote configuration.

Signal System 7 and Call Agent Fail-over Interaction

When an ISUP SS7 signaling link goes into the link failure state, an Signaling System 7 Signaling Link Down alarm (13) is activated and the call-agent will begin a 120 second timer. When the SS7 signaling link is restored, in-progress calls are cleared if they were in a transient state, if an event occurred that required the sending of an ISUP message during the link failure, or if the 120 second timer has expired.

Should the call-agent fail-over for any reason, the state of the 120 second timer or any indication of a request for an outgoing message that could not be sent will not be preserved. If the signaling links are in the failure state on the stand-by side, the 120 second timer will be re-started; however, if the links should restore prior to that the timer expiry, any stable calls will NOT be cleared.

This applies should multiple fail-overs occur prior to eventual signaling link restoration. In these situations, if a call clearing event has been missed, any calls remaining up will be cleared by the normal ISUP network recovery and message retransmission mechanisms.

Link is Remotely Inhibited—Signaling (14)

The Link is Remotely Inhibited alarm (minor) indicates that the SS7 link is inhibited at the remote end. The primary cause of the alarm is that the specified SS7 link is inhibited at the remote end. To correct the primary cause of the alarm, monitor events and alarms at the network level for any related to the specified SS7 link. Restorative actions need to be taken on the remote end.

Link is Locally Inhibited—Signaling (15)

The Link is Locally Inhibited alarm (minor) indicates that the SS7 link is inhibited at the local end. The primary cause of the alarm is that the specified SS7 link is inhibited at the local end. To correct the primary cause of the alarm, verify that the SS7 signaling adapter process is running and that the SS7 interface card(s) are in service. If a component is found to be non-operational, restore it to service.

Link is Congested—Signaling (16)

The Link is Congested alarm (minor) indicates that the SS7 link is congested. The primary cause of the alarm is that the specified SS7 link is experiencing congestion. To correct the primary cause of the alarm, monitor event reports at the network level to determine if the traffic load on the specified SS7 link is too high on the local end, or if the remote end is lagging in processing the traffic. Verify that the SS7 link has not degraded in quality. Verify that the traffic load has not become unbalanced if multiple SS7 links are used. Verify that local SS7 signaling adapter process is running normally.

Link: Local Processor Outage—Signaling (17)

The Link: Local Processor Outage alarm (minor) indicates that the SS7 link has experienced a local processor outage. The primary cause of the alarm is that the specified SS7 link has experienced a processor outage. To correct the primary cause of the alarm, monitor the system for maintenance event reports associated with the signaling adapter or underlying platform instance that support the specified SS7 link. Verify that the pocess and or platform are restarted and returned to service.

Link: Remote Processor Outage—Signaling (18)

The Link: Remote Processor Outage alarm (minor) indicates that the SS7 link has experienced a remote processor outage. The primary cause of the alarm is that the specified SS7 link has experienced a processor outage. To correct the primary cause of the alarm, monitor the network level event reports for any events associated with the processing complex used by the specified SS7 link. Verify that the SS7 link is returned to service.

Link Set Inaccessible—Signaling (19)

The Link Set Inaccessible alarm (major) indicates that the specified SS7 link in inaccessible. The primary cause of the alarm is that the specified SS7 link set is inaccessible. To correct the primary cause of alarm, return the SS7 signaling adapter and the associated call agent platform to service if the SS7 signaling adapter is not running normally and the associated call agent platform is not active.

Link Set Congestion—Signaling (20)

The Link Set Congestion alarm (major) indicates that the specified SS7 link set is congested. The primary cause of the alarm is that the specified SS7 link set is experiencing congestion. To correct the primary cause of the alarm, monitor the alarm and event reports at the network level to determine if the traffic load on the specified SS7 link set is too high on the local end, or if the remote end is lagging in processing the traffic. Verify that the SS7 link set has not degraded in quality. Verify that the traffic load has not become unbalanced if multiple SS7 link sets are used. Verify that local SS7 signaling adapter process is running normally.

Route Set Failure—Signaling (21)

The Route Set Failure alarm (major) indicates that the specified route set has a experienced a failure. The primary cause of the alarm is the specified route set has experienced a failure. To correct the primary cause of the alarm, verify that the processing complex supporting the route set is functional. Monitor event reports at the network level to determine the failing component and verify its restoral to service.

Route Set Congested—Signaling (22)

The Route Set Congested alarm (minor) indicates that the specified route set is congested. The primary of the alarm is that the specified route set is experiencing congestion. To correct the primary cause of the alarm, monitor event reports at the network level to determine if the traffic load on the specified SS7 link set is too high on the local end, or if the remote end is lagging in processing the traffic. Verify that the SS7 link set has not degraded in quality. Verify that the traffic load has not become unbalanced if multiple SS7 link sets are used. Verify that local SS7 signaling adapter process is running normally.

Destination Point Code Unavailable—Signaling (23)

The Destination Point Code Unavailable alarm (major) indicates that the specified DPC is not available. This alarm indicates that the BTS 10200 is unable to communicate with the specified DPC in the SS7 network. Determine if the issue is a communication problem between the BTS 10200 and the IP transfer point (ITP) or if it is related to communication problems between the ITP and the DPC by following these steps:

Step 1 Use the BTS 10200 CLI show alarm command to determine if there is an active Signaling Gateway Group Out of Service alarm. This will occur if communication has been lost to at least one of the SGs in the SG-Group. If so, proceed to the "Signaling Gateway Group Is Out-of-Service—Signaling (110)" section. Otherwise, proceed to Step 2.

Step 3 If you arrive at this step, there is probably communication between the BTS 10200 and ITP at the M3UA and SCCP user adapter (SUA) layers, and a communication problem exists between the ITP and the unavailable DPC. To confirm this, log on to each ITP, get into enable mode, and enter show cs7 route. The output of this command tells you if the associated DPC is accessible or not from the ITP point of view and will look similar to the following:

va-2651-82#show cs7 route

Destination Prio Linkset Name Route

---------------------- ---- ------------------- -------

229.123.2/24 INACC 1 lset1chn UNAVAIL

This output indicates that DPC 229.123.2 is unavailable from the ITP point of view.

Step 4 Determine if the problem is at the link level or at a higher level outage in the DPC by typing show cs7 linkset. If the ITP shows that the DPC is AVAIL, there is a mismatch between the ITP and BTS 10200. Please contact the Cisco TAC.

Step 5 Check whether the DPC has been removed from the BTS 10200 database. At the BTS 10200 CLI prompt, enter show call-ctrl-route or show sccp-route and see if the DPC is in any of the routes. If not, the alarm was raised before the associated routes were deleted. If this is the case, manually clear the alarm.

Step 6 If you still cannot determine the cause of the problem, contact the Cisco TAC.

Destination Point Code Congested—Signaling (24)

The Destination Point Code Congested alarm (minor) alarm indicates that the specified DPC is congested. This alarm indicates that the DPC in the SS7 network is congested, i.e., is in a state where it has received more traffic than it can handle. This should be a temporary state. If the type of network is National, which is generally the case in the United States, there will also be a level of congestion associated with the alarm.

The ITP should continually communicate with the DPC in the SS7 network to determine if congestion has abated. If this alarm does not clear or keeps reappearing after clearing, contact your SS7 service provider to determine why the DPC is congested.

The DPC Congested alarm is issued when the specified destination point code is congested. Monitor event reports at the network level to determine if the traffic load to the specified DPC is too high on the local end, or if the remote end is lagging in processing the traffic.

Trunk Locally Blocked—Signaling (36)

The Trunk Locally Blocked alarm (minor) indicates that the trunk is locally blocked. The primary cause of the alarm is that a BLO or CGB message was sent on the specified CIC. No action is required.

Trunk Remotely Blocked—Signaling (40)

The Trunk Remotely Blocked alarm (major) indicates that the trunk is remotely blocked. The primary cause of the alarm is that a BLO or CGB message was received on the specified CIC if it is SS7 trunk. Issued when SERVICE OOS message is received for ISDN trunks. Issued when Reverse Make Busy (rbz) signal is received for CAS operator trunk. No action is required. The system can be manually recovered from this condition locally by controlling the effected trunks to UEQP state and back INS.

The Auto State Change for Integrated Services Digital Network Trunk Group by Media Gateway alarm (major) indicates that specified ISDN trunk group status was changed due to a media gateway operation. The primary cause of the alarm is that the specified ISDN trunk group's status was changed due to a media gateway operation. To correct the primary cause of the alarm, monitor the event reports at the network level to determine which media gateway caused the status change of the trunk group. Verify that the gateway is reconfigured properly to support the usage of the trunk group.

Media Gateway/Termination Faulty—Signaling (63)

The Media Gateway/Termination Faulty alarm (major) indicates that a media gateway or termination has gone faulty due to the detection of an unknown endpoint, unknown package type, and unknown event, a hardware failure, or a general call agent error. The primary cause of the alarm is that a media gateway or termination has gone faulty due to the detection of an unknown endpoint, unknown package type, and unknown event (either a hardware failure or a general call agent error). To correct the primary cause of the alarm, verify the proper operation of the media gateway specified. Place the termination out-of-service and then back into service from the call agent.

The Media Gateway Adapter Running out of Shared Memory Pools alarm (critical) indicates that the MGCP signaling adapter was unable to allocate data store for an IPC message due to a lack of resources. The primary cause of the alarm is that the MGCP signaling adapter was unable to allocate data store for an IPC message due to a lack of resources. To correct the primary cause of the alarm, contact Cisco TAC technologies for assistance.

Media Gateway Adapter Running out of Heap Memory—Signaling (65)

The Media Gateway Adapter Running out of Heap Memory alarm (critical) indicates that the MGCP signaling adapter was unable to allocate data store for an IPC message from the heap due to a lack of resources. The primary cause of the alarm is that the MGCP signaling adapter was unable to allocate data store for an IPC message from the heap due to a lack of resources. To correct the primary cause of the alarm, contact Cisco TAC for assistance.

The Call Agent Internal Error (Because of Which Media Gateway Adapter has to Start Automatically) alarm (major) indicates that a call agent internal error has occurred causing the restart of the MGCP signaling adapter. The primary cause of the alarm is that a call agent internal error has occurred causing the restart of the MGCP signaling adapter. To correct the primary cause of the alarm, send the log files to Cisco TAC for analysis and corrective action.

Trunking Gateway Endpoints are out of Service at the Gateway—Signaling (68)

The Trunking Gateway Endpoints are out of Service at the Gateway alarm (major) indicates that the trunking gateway endpoints are out of service at the GW. The primary causes of the alarm are that the trunking gateway has been administratively taken the OOS using a command in GW or the Endpoint is in an alarmed or OOS state. To correct the primary cause of the alarm, bring into service the trunking gateway that has been administratively taken INS using the command in GW and fix the trunk endpoint alarms.

Call Agent is not Up or is not Responding to the Feature Server—Signaling (69)

The Call Agent is not Up or is not Responding to the Feature Server alarm (critical) indicates that a CA and FS communications message timed out. The primary cause of the alarm is that CA to FS communication has failed due to wrong system configuration; -OR- CA or FS is down. To correct the primary cause of the alarm, check the configuration related to the CA to FS communication. Also, check the FS table entries and the CA entry.

Signaling System 7 Stack not Ready—Signaling (75)

The Signaling System 7 Stack not Ready alarm (critical) indicates that the SS7 stack in not ready. The primary cause of the alarm that the SS7 stack not configured properly. To correct the primary cause of the alarm, check SS7 stack configuration. The secondary cause of the alarm is that the SS7 stack is not ready. To correct the secondary cause of the alarm, check the SS7 stack status. Do a platform start -i omni command to bring up the SS7 stack.

The Integrated Services Digital Network Single D-channel Down for Non-Facility Associated Signaling alarm (minor) indicates that one of the ISDN D-channels in the PRI is down. The primary cause of the alarm is that one of the ISDN D-channels in PRI is down. To correct the primary cause of the alarm, check the gateway power and the gateway connection to the PBX.

Trunking Gateway Unreachable—Signaling (79)

The Trunking Gateway Unreachable alarm (major) indicates that the trunking gateway is not responding to keep-alive Audit Endpoint messages. To correct the primary cause of the alarm, check the IP connectivity status between BTS call agent and the trunking gateway.

Out of Bounds, Memory/Socket Error—Signaling (80)

The Out of Bounds, Memory/Socket Error alarm (critical) indicates that a memory socket out of bounds error has occurred. The primary cause of the alarm is that the system is out of heap memory. To correct the primary cause of the alarm, contact Cisco TAC and increase RAM memory. The secondary cause of the alarm is that the system is out of IPC pool memory. To correct the secondary cause of the alarm, resize the IPC pool size in Platform Configuration file. The ternary cause of the alarm is that a socket error has occurred. An inappropriate or already bound socket may be in use. To correct the ternary cause of the alarm, check the UDP port supplied with the MGA command-line for validity and prior use.

Insufficient Heap Memory—Signaling (81)

The Insufficient Heap Memory alarm (critical) indicates that there is insufficient heap memory. The primary cause of the alarm is that the H323 signaling adapter was unable to allocate memory from the system. To correct the primary cause of the alarm, contact Cisco TAC for assistance.

Insufficient Shared Memory Pools—Signaling (82)

The Insufficient Shared Memory Pools alarm (critical) indicates that there is insufficient shared memory pools. The primary cause of the alarm is that the H323 signaling adapter was unable to allocate storage. To correct the primary cause of the alarm, contact Cisco TAC for corrective action.

Reached Maximum Socket Limit—Signaling (84)

The Reached Maximum Socket Limit alarm (critical) indicates that the BTS 10200 system has reached the maximum socket limit. The primary cause of the alarm is that the configuration setting of an H3A parameter in the platform.cfg file is wrong. To correct the primary cause of the alarm, reconfigure the platform.cfg file and restart the H3A process.

Initialization Failure—Signaling (85)

The Initialization Failure alarm (critical) indicates that the BTS 10200 system failed to initialize. The primary cause of the alarm that a process initialization failure has occurred. To correct the primary cause of the alarm, check "Reason" dataword for the failure cause and take action accordingly.

Remote H323 Gateway is not Reachable—Signaling (86)

The Remote H323 Gateway is not Reachable alarm (major) indicates that the remote H323 gateway is not reachable. The primary cause of the alarm is that a loss of communication with a remote gateway has occurred. To correct the primary cause of the alarm, perform the standard connectivity tests-both the physical checks and the IP tests. Also, ensure that the gateway is not out of service.

H323 Message Parsing Error—Signaling (87)

The H323 Message Parsing Error alarm (major) indicates that a H323 message parsing error has occurred. The primary cause of the alarm is that the system was unable to successfully parse an incoming H323 message. This alarm is a result of either a software bug or bad message being received-a message with a valid message type but an invalid field within the message. To correct the primary cause of the alarm, snoop the message from the endpoint and verify its content or contact Cisco TAC.

H323 Message Encoding Error—Signaling (88)

The H323 Message Encoding Error alarm (major) indicates that a H323 message encoding error has occurred. The primary cause of the alarm is that the system was unable to encode an H323 message for sending. The alarm is indicative a software bug. To correct the primary cause of the alarm, contact Cisco TAC.

Gatekeeper not Available/Reachable—Signaling (89)

The Gatekeeper not Available/Reachable alarm (major) indicates that the gatekeeper is not available or the gatekeeper is not reachable. The primary cause of the alarm is that the gatekeeper is not available or is unreachable. To correct the primary cause of the alarm, check the network connectivity. Check to ensure the GK is reachable by trying to ping the GK IP address. If reachable, then check to ensure that the GK is configured up.

Alternate Gatekeeper is not Responding—Signaling (90)

The Alternate Gatekeeper is not Responding alarm (major) indicates that the alternate gatekeeper is not responding. The primary cause of the alarm is that the alternate gatekeeper is not responding. To correct the primary cause of the alarm, check network connectivity. Check to ensure the alternate GK is reachable by trying to ping the alternate GK IP address. If reachable, then check to ensure that the alternate GK is configured up.

Endpoint Security Violation—Signaling (91)

The Endpoint Security Violation alarm (major) indicates that an H323 security violation has occurred. The primary cause of the alarm is that an H323 security violation has occurred. To correct the primary cause of the alarm, check to make sure the password selections on the BTS 10200 and the gatekeeper are correct. The secondary cause of the alarm is that the H323GW table may not be provisioned properly or there is a time synchronization problem between the BTS 10200 and/or the gatekeeper and the NTP server. To correct the secondary cause of the alarm, ensure that both the BTS 10200 and the gatekeeper are pointing to the same NTP server.

Invalid Call Identifier—Signaling (92)

The Invalid Call Identifier alarm (minor) indicates that the Call ID was invalid or changed mid-call. The primary cause of the alarm is that the Call ID was invalid or changed mid-call. The alarm indicates that a software problem has occurred on the BTS 10200 or on the endpoint. To correct the primary cause of the alarm, contact Cisco TAC.

Invalid Call Reference Value—Signaling (93)

The Invalid Call Reference Value alarm (minor) indicates that the Call ID was invalid or changed mid-call. The primary cause of the alarm is that the Call ID was invalid or changed mid-call. The alarm indicates that a software problem has occurred on the BTS 10200 or on the endpoint. To correct the primary cause of the alarm, contact Cisco TAC.

Invalid Conference Identifier—Signaling (94)

The Invalid Conference Identifier alarm (minor) indicates that the Call ID was invalid or changed mid-call. The primary cause of the alarm is that the Call ID was invalid or changed mid-call. The alarm indicates that a software problem has occurred on the BTS 10200 or on the endpoint. To correct the primary cause of the alarm, contact Cisco TAC.

Invalid Message from the Network—Signaling (95)

The Invalid Message from the Network alarm (minor) indicates that an unsupported or invalid message type was received from network. The primary cause of the alarm is that an unsupported or invalid message type was received from the network. To correct the primary cause of the alarm, contact Cisco TAC.

Internal Call Processing Error—Signaling (96)

The Internal Call Processing Error alarm (minor) indicates that an internal call processing error has occurred. The primary cause of the alarm is that a software error has occurred. To correct the primary cause of the alarm, contact Cisco TAC.

Insufficient Information to Complete Call—Signaling (97)

The Insufficient Information to Complete Call alarm (minor) indicates that there was insufficient information to complete a call. The primary cause of the alarm is that there was not enough initial call setup information received to establish the call. To correct the primary cause of the alarm, contact Cisco TAC.

H323 Protocol Inconsistencies—Signaling (98)

The H323 Protocol Inconsistencies alarm (minor) indicates that the H323 endpoint and BTS 10200 are running different protocol versions. The primary cause of the alarm is that the H323 endpoint and the BTS 10200 are running different protocol versions. This is only an issue where the endpoint is running a higher version of the H323 protocol than the BTS 10200. To correct the primary cause of the alarm, contact Cisco TAC.

Abnormal Call Clearing—Signaling (99)

The Abnormal Call Clearing alarm (minor) indicates that an unsupported or invalid message type was received from network. The primary cause of the alarm is that an unsupported or an invalid message type was received from network. To correct the primary cause of the alarm, contact Cisco TAC.

Codec Negotiation Failed—Signaling (100)

The Codec Negotiation Failed alarm (minor) indicates that the codec negotiation has failed. The primary cause of the alarm is that the codec negotiation failed. To correct the primary cause of the alarm, find a compatible set of codec settings for both sides, re-provision the endpoints of the call and try the call again.

Per Call Security Violation—Signaling (101)

The Per Call Security Violation alarm (minor) indicates that a call security violation has occurred. This is a future trap definition-it will not be issued in the 3.x release series.

H323 Network Congested—Signaling (102)

The H323 Network Congested alarm indicates (minor) that the H323 application process has depleted its resources and no more calls can be completed. The primary cause of this alarm is that the H323 application processes has depleted it's resources and no more calls can be completed. The high water mark has been reached and all new call requests are rejected until the low water mark is reached. To correct the primary cause of the alarm, re-provision the water marks or check the network for overload. Also verify that alternate routes have been provisioned on the BTS 10200.

Aggregation Connection Down—Signaling (103)

The Aggregation Connection Down alarm (major) indicates that the AGGR TCP connection is down. The primary cause of the alarm is that the TCP connection is down. To correct the primary cause of the alarm, check the associated cabling and perform PINGs to test the connectivity.

The Enhanced Subscriber Authentication BTS 10200 Delivery Function Connection Down alarm (minor) indicates that the ESA BTS 10200 DF connection is down. The primary cause of the alarm is that the DF server is not responding. To correct the primary cause of the alarm, check the encryption key or the IP connectivity to the DF.

The Logical Internet Protocol Addresses not Mapped Correctly alarm (critical) indicates that the logical IP addresses are not mapped correctly. The primary cause of the alarm is that the contact name in the configuration file is not configured in the DNS. To correct the primary cause of the alarm, verify that the name in the DNS matches the name in the platform.cfg and opticall.cfg files. The secondary cause of the alarm is the contact could not be resolved to an IP address on the host. To correct the secondary cause of the alarm, verify that the DNS resolves to the IP addresses reserved for process on the BTS 10200. The ternary cause of the alarm is that the IP address manager is not running. To correct the ternary cause of the alarm, verify that the IPM process is running and check for alarms from IPM. The subsequent cause of the alarm is mis-configuration during installation or manual changes made after installation. To correct the subsequent cause of the alarm, contact Cisco TAC for support.

Simplex Only Operational Mode—Signaling (108)

The Simplex Only Operational Mode alarm (major) indicates that the BTS 10200 system can only operate in the simplex mode. The primary cause of the alarm is that the -hostname parameter is specified in the platform.cfg file (instead of the -contact parameter). The BTS 10200 is configured as a SIMPLEX system.

The Stream Control Transmission Protocol Association Failure alarm (major) indicates that the SCTP association failed. This alarm indicates that the BTS 10200 is unable to communicate with an SGP at the SCTP protocol level. The problem may be at the M3UA or SUA layer. The primary cause of the alarm is that the Ethernet cables on the SGP are unplugged or severed. To correct the primary cause of the alarm, plug the Ethernet cables in or fix the severed connection. The secondary cause of the alarm is that the SGP is not operational. To correct the secondary cause of the alarm, check the SGP alarms to determine why it is not operating properly. To troubleshoot the M3UA or the SUA layers, use the following procedures.

Message Transfer Part 3 User Adapter Troubleshooting Procedure

Use the following steps to determine the source of the problem at the M3UA layer:

Step 1 Determine if the administrative state of the SCTP is correct.

a. Type the following command at the BTS 10200 CLI prompt:

status sctp-assoc id=<sctp-assoc-name>

If the response displays ADMIN STATE ->ADMIN_OOS, the SCTP association has been taken administratively out of service and needs to be put back in service.

b. Enter the following command to put the SCTP association in service:

e. If the state of the ASP indicates shutdown, someone has administratively taken the association out of service. Refer to the Cisco ITP User's Guide, at the following universal resource locator (URL), to put the ASP (SCTP association) back in service:

g. If the state of the ASP is inactive, the ASP is probably on the standby BTS 10200. If the ASP on the active BTS 10200 is inactive, proceed to Step 7.

Step 2 Determine if the problem is an IP address or port configuration mismatch between the ITP and the BTS 10200.

a. Determine the BTS 10200 configured values for the BTS 10200 IP addresses and port. Look for the DNS name and port number that are configured for the SGA process in /opt/OptiCall/CA146/bin/platform.cfg. Go to the specified directory and enter:

–Hit enter until the ASP configurations are displayed. A section similar to the following will appear which shows you the ITP configured values for the BTS 10200 IP addresses of the SCTP association:

cs7 asp hrn11asp 11146 2905 m3ua

remote-IP 10.0.5.136

remote-IP 10.128.1.147

The number after the ASP name "hrn11asp" is the port number that the ITP has configured for the BTS 10200 side of the SCTP association. The two remote-IP addresses are the addresses that the ITP has configured for the BTS 10200 side of the SCTP association. Make sure all of these values match the values found in Step 2A.

–Hit enter until the m3ua (or sua) configuration is displayed. In our example, we are considering the SCTP association connection between the BTS 10200 and the ITP, so we will look at the ITP m3ua configuration. An example of this is as follows:

cs7 m3ua 2905

local-IP 10.0.1.54

local-IP 10.128.1.239

–Make sure that the IP addresses and port number are the same values as found in step 2C.

Step 3 Determine if all Ethernet connections on the BTS 10200 have been disconnected or if communication has been lost to the IP router. In the platform.log, look for the following ERROR message:

"All the IP interfaces are faulty!!"

If this message is found, the Ethernet connections of the BTS 10200 have been pulled or cut. If this message is not found, proceed to Step 4.

Step 4 Determine if the problem is an IP routing issue.

a. Determine what has been provisioned in the BTS 10200 for the destination IP interfaces of the SCTP association by typing the following command:

show sctp-association id=<sctp-association-id>

Information similar to the following will appear and display the destination IP addresses:

REMOTE_TSAP_ADDR1=10.0.1.54

REMOTE_TSAP_ADDR2=10.128.1.239

b. Ping each of the destination IP addresses If one of the addresses does not respond to the ping, there is an IP routing problem that has disabled SCTP communication. Contact the Cisco TAC for assistance. If the ping commands are successful, proceed to Step 5.

c. Hit enter until the ASP configuration is displayed. A section similar to the following will display the BTS 10200 IP addresses of the SCTP association:

cs7 asp hrn11asp 11146 2905 m3ua

remote-IP 10.0.5.136

remote-IP 10.128.1.147

d. Ping each of the IP addresses. If you do not receive a response to the ping command for at least one of the BTS 10200 IP endpoint addresses, there is an IP routing problem that is causing the SCTP association to be down. Contact the Cisco TAC for assistance. Otherwise, proceed to Step 6.

Step 6 Bounce the SCTP association (take it administratively out of service and then put it in service)

b. Check if the SCTP association has come back in service by entering the following:

status sctp-assoc id=<sctp-assoc-name>;

The output will either show OPER STATE -> SCTP-ASSOC out of service or OPER STATE -> SCTP-ASSOC in service.

If the OPER STATE still shows that the SCTP association is out-of-service, proceed to Step 7.

Step 7 Bounce the SCTP association from the ITP side by performing the following steps:

a. Log on to the ITP and get into enable mode.

b. Get into configure mode by typing configure terminal.

c. Type t he following commands to bounce the SCTP association back in service:

va-2651-82(config)#cs7 asp hrn11asp

va-2651-82(config-cs7-asp)#shut

va-2651-82(config-cs7-asp)#no shut

va-2651-82(config-cs7-asp)#end

d. Determine if the SCTP association has come back in service by typing the following BTS 10200 CLI command:

status sctp-assoc id=<sctp-assoc-name>;

The output will display either OPER STATE -> SCTP-ASSOC out of service or OPER STATE -> SCTP-ASSOC in service.

If the OPER STATE still shows that the SCTP association is out-of-service, there is probably an SCTP communication issue that must be debugged at the SCTP protocol level. Contact the Cisco TAC for assistance.

Signaling Gateway Group Is Out-of-Service—Signaling (110)

The Signaling Gateway Group is Out-of-Service alarm (major) indicates that the signaling gateway group is out-of-service. The primary cause of the alarm is that all the SCTP associations between the CA and the SGs are out-of-service. To correct the primary cause of the alarms, make sure that all Ethernet connections on the CA and SGs are plugged in. Also make sure all associated IP routers are operational. The secondary cause of the alarm is that the M3UA layer is down between the CA and SGs. To correct the secondary cause of the alarm, use a snooper application to determine why the M3UA layer is down.

This alarm indicates that after communication to the SG group was established, it was lost. This indicates that communication to associated SGs is down, which also indicates that communication to all SGPs is down. See the "Signaling Gateway Failure—Signaling (113)" section to determine why the associated SGs are down.

The Stream Control Transmission Protocol Association Degraded (One of Two Internet Protocol Connections Down) alarm (major) indicates that the SCTP association is degraded. The primary cause of the alarm is that a single Ethernet connection on CA or SGP is unplugged or severed. To correct the primary cause of the alarm, plug in all Ethernet connections or repair if severed. The secondary cause of the alarm is a SCTP communication problem-or protocol timeout. To correct the secondary cause of the alarm, use a snooper application to determine why the SCTP association is degraded.

The Stream Control Transmission Protocol Association Configuration Error alarm (minor) indicates that a SCTP association configuration error has occurred. The primary cause of the alarm is that the destination IP address is invalid. To correct the primary cause of the alarm, input a new destination IP address, see the log for additional details. The secondary cause of the alarm is that the local IP address is invalid. To correct the secondary cause of the alarm, input new local IP address information. The ternary cause of the alarm is that the IP Routing Table is not configured properly. To correct the ternary cause of the alarm, have the system administrator configure IP routing table.

Message Transfer Part 3 User Adapter Troubleshooting Procedure

This alarm indicates that there is a provisioning error keeping the BTS 10200 from properly configuring the SCTP association. Perform the following steps to resolve the problem:

Step 1 To get more information about this alarm, look at the platform.log for error messages containing the string "Multipurpose Internet Mail (MIM) configuration (CFG)."

Signaling Gateway Failure—Signaling (113)

Note When a port on a ITP is removed from service using the shut command, multiple Signaling 113 and 114 alarms are raised (ON status). When the port is recovered by cycling the ITP power, all alarms raised are cleared (OFF status) and are removed from CURRENT_ALARM table. However, not all cleared alarms (OFF status) are displayed on the subscriber terminal. Only the first instance of the cleared alarms (OFF status) with a variation in TYPE, NUMBER, and COMPONENT-ID are displayed. Multiple instances of the cleared alarms (OFF status) where the TYPE, NUMBER, and COMPONENT-ID are identical are not displayed.

The Signaling Gateway Failure alarm (major) indicates that all associated signaling gateway processes are out-of-service. The primary cause of the alarm is that all associated Signaling Gateway Processes are out-of-service. To correct the primary cause of the alarm, determine why each associated Signaling Gateway Process is out-of-service (see SGP alarm definition).

Signaling Gateway Process Is Out-of-Service—Signaling (114)

Note When a port on a ITP is removed from service using the shut command, multiple Signaling 113 and 114 alarms are raised (ON status). When the port is recovered by cycling the ITP power, all alarms raised are cleared (OFF status) and are removed from CURRENT_ALARM table. However, not all cleared alarms (OFF status) are displayed on the subscriber terminal. Only the first instance of the cleared alarms (OFF status) with a variation in TYPE, NUMBER, and COMPONENT-ID are displayed. Multiple instances of the cleared alarms (OFF status) where the TYPE, NUMBER, and COMPONENT-ID are identical are not displayed.

The Signaling Gateway Process is Out-of-Service alarm (major) indicates that all SCTP associations between the SGP and the CA are out-of-service. The primary cause of the alarm is that all SCTP associations between the SGP and the CA are out-of-service. To correct the primary cause of the alarm, see the SCTP Association Alarm definition to determine how to rectify the problem. The secondary cause of the alarm is that the M3UA layer is down between the CA and the SGP. To correct the secondary cause of the alarm, use a snooper utility to determine why M3UA layer is down. Also see the log for additional information.

Destination Point Code User Part Unavailable—Signaling (116)

The Destination Point Code User Part Unavailable alarm (major) indicates that a layer 4 user part, such as ISUP, is unavailable at the DPC in the SS7 network. The primary cause of the alarm is that the SGP sent a DUPU M3UA message to the CA indicating that an user part is unavailable on at a DPC. To correct the primary cause of the alarm, contact the SS7 network administrator to report the user part unavailable problem related to the DPC so communication can be restored.

The Circuit Validation Test Message Received for an Unequipped Circuit Identification Code alarm (minor) indicates that a CVT message was received for an unequipped CIC. The primary cause of the alarm is that the CIC is not provisioned. To correct the primary cause of the alarm, provision the CIC.

The Circuit Verification Response Received with Failed Indication alarm (minor) indicates that a CVR message was received with a failure indication. The primary cause of the alarm is that a CIC mismatch has occurred. To correct the primary cause of the alarm, perform an internal test such as checking that the CIC is assigned to a circuit between the sending and the receiving switch.

Signaling System 7 Adapter Process Faulty—Signaling (119)

The Signaling System 7 Adapter Process Faulty alarm (critical) indicates that a S7A process is faulty. The primary cause of the alarm is that an OMNI or a S7A exception has occurred. To correct the primary cause of the alarm, check OMNI process. The S7A process will restart itself if the S7A maximum restart threshold has not been exceeded.

The Signaling System 7 Module/Signaling System 7 Adapter Faulty alarm (critical) indicates that the S7M/S7A processes are faulty. The primary cause of the alarm is that an OMNI failure has occurred. To correct the primary cause of the alarm, check the OMNI status. An automatic failover will occur in a duplex configuration.

The Message Transfer Part 3 User Adapter Cannot Go Standby alarm (major) indicates that the M3UA process cannot go into standby mode. The primary cause of the alarm is that no INACTIVE ACK messages are being received from any Signaling Gateway. The SG or SCTP associations are probably down. To correct the primary cause of the alarm, investigate other alarms to see if SGs are down or if SCTP associations are down. Take corrective action according to those alarms.

Message Transfer Part 3 User Adapter Cannot Go Active—Signaling (122)

The Message Transfer Part 3 User Adapter Cannot Go Active alarm (major) indicates that the M3UA process cannot go into active mode. The primary cause of the alarm is that no ACTIVE ACK messages are being received from any Signaling Gateway. The SG or SCTP associations are probably down. To correct the primary cause of the alarm, investigate other alarms to see if SGs are down or if the SCTP associations are down. Take corrective action according to those alarms.

Remote Subsystem is Out Of Service—Signaling (124)

The Remote Subsystem is out of Service alarm (minor) indicates that the remote subsystem is out-of-service. The primary cause of the alarm is that the link lost connection or the remote subsystem is out-of-service. This alarm indicates the remote subsystem is out-of-service. To correct the primary cause of the alarm, contact your service control point (SCP) service provider for assistance.

Note This alarm can occur when there is an SS7 outage affecting a non-adjacent remote destination point code (DPC) where the global title translation (GTT) database resides. The SS7 SCP subsystems in the BTS 10200 show the allowed status but the related DPC shows unavailable.

Signaling Connection Control Part Routing Error—Signaling (125)

The Signaling Connection Control Part Routing Error alarm (major) indicates that the SCCP route was invalid or not available. The primary cause of the alarm is that the SCCP route is invalid or is not available. To correct the primary cause of the alarm, provision the right SCCP route.

Signaling Connection Control Part Binding Failure—Signaling (126)

The Signaling Connection Control Part Binding Failure alarm (major) indicates that the SCCP binding failed. The primary cause of the SCCP Binding Failure alarm is that the Trillium stack binding failed. To correct the primary cause of the alarm, re-initialize the TSA process or remove the subsystem from the EMS table and add it again.

The Transaction Capabilities Application Part Binding Failure alarm (major) indicates that the TCAP binding failed. This alarm is raised when the TCAP layer does not have enough service access point (SAP) to bind for the subsystem. Currently only 16 subsystems are allowed on the same platform. Check the Subsystem table to see if you have more than 16 subsystems on the same platform, Feature Server for POTS, Tandem, and Centrex services (FSPTC) or Feature Server for AIN services (FSAIN). The primary cause of the TCAP Binding Failure alarm is that the Trillium stack binding failed. To correct the primary cause of the alarm, re-initialize the TSA process or remove the subsystem from the EMS table and add it again.

The Session Initiation Protocol Trunk Operationally Out-of-Service alarm (critical) indicates that the SIP trunk is operationally out-of-service. The primary cause of the alarm is that the BTS 10200 is unable to communicate with a remote SIP party (Call-Agent or Proxy) over a SIP or SIP-T trunk. To correct the primary cause of the alarm, verify that the DNS resolution exists, if TSAP address of the remote entity is a domain name. Verify the remote entity is reachable by ICMP ping, using the Trunk TSAP address from the alarm event report. If the same alarm is reported on all the softswitch trunk groups, then verify that the network connection is operational. If the ping is not successful, then diagnose the issue that prevents the TSAP address from being reached. Verify the SIP application is running on the remote host and listening on the port specified in the TSAP address.

The Internet Protocol Interface Link to the Signaling System 7 Signaling Gateway is Down alarm (minor) indicates that an IP interface link to the SS7 signaling gateway is down. The primary cause of the alarm is an interface hardware problem. To correct the primary cause of the alarm, check the link interfaces.

The All Internet Protocol Interface Links to Signaling System 7 Signaling Gateway are Down alarm (critical) indicates that all IP interface links to the SS7 signaling gateway are down. The primary cause of the alarm is an interface hardware problem. To correct the primary cause of the alarm, check the link interfaces.

One Internet Protocol Interface to Signaling System 7 Signaling Gateway is Down—Signaling (145)

The One Internet Protocol Interface to Signaling System 7 Signaling Gateway is Down alarm (minor) indicates that one IP interface link to the SS7 signaling gateway is down. The primary cause of the alarm is an interface hardware problem. To correct the primary cause of the alarm, check the link interfaces.

The Stream Control Transmission Protocol Association Congested alarm (minor) indicates that the SCTP association is congested. The primary cause of the alarm is that the network is congested. To correct the primary cause of the alarm, clean off the network congestion caused by routing or switching issues. The secondary cause of the alarm is that the CPU is throttled. To correct the secondary cause of the alarm, upgrade to a more powerful platform or offload some traffic.

Subscriber Line Faulty—Signaling (151)

The Subscriber Line Faulty alarm (minor) indicates that the residential gateway returned an error code in response to a command from the MGW. To correct the primary cause of the alarm, try controlling subscriber termination to OOS and back into INS using the BTS 10200 CLI command. If the problem persist after more calls, check the configuration in the BTS 10200 and the RGW. If the error codes returned by MGW are harmless, it can be suppressed by adding a new entry in the MGCP-RETCODE-ACTION table and change EP-ACTION to RESET/NONE.

Note The following additional troubleshooting information is applicable to Release 5.0 MR2 and above.

If the VXSM is OOS at the GW side, a 501 error message for CRCX/AUEP may be transmitted. This generally occurs if there is resource state mismatch between the BTS 10200 (ACTV IDLE) and the VXSM (DOWN). For additional information on the 501 error message, refer to Appendix A, "Recoverable and Nonrecoverable Error Codes."

When the mismatch occurs the default behavior is UPDATE for both the create connection (CRCX) and audit endpoint (AUEP) messages as follows:

If a 501 response is received for the CRCX message on execution of the EP-ACTION=UPDATE for CRCX, the BTS 10200 will start auditing the endpoint by sending an AuditEndpoint message requesting restart-method (rm parameter reported in the RSIP message, which indicates the service state at the GW). If the restart-method information reported in AUEP message is different from the BTS 10200 termination state, the termination state will be updated accordingly (if rm=forced, DOWN is set in termination oper-status; if rm=restart DOWN is cleared in termination oper-status).

If a 501 response is received for the AUEP message on execution of the EP-ACTION=UPDATE for AUEP, the BTS will unconditionally mark the termination as DOWN.

To clear DOWN from the termination oper-status, you either need to control the trunk/subscriber-termination OOS/INS mode=forced; or trigger RSIP rm=restart from the GW.

Emergency Trunks Become Locally Blocked—Signaling (153)

The Emergency Trunks Become Locally Blocked alarm (critical) is issued when an emergency trunk (CAS, SS7, or ISDN) becomes locally blocked. No further action is required.

Emergency Trunks Become Remotely Blocked—Signaling (154)

The Emergency Trunks Become Remotely Blocked alarm (critical) is issued when when an emergency trunk (CAS, SS7, or ISDN) becomes remotely blocked. No further action is required.

The Integrated Services Digital Network Signaling Gateway Down alarm (major) is issued when the BTS 10200 cannot communicate to the ISDN gateway. The primary cause of the alarm is that the BTS 10200 cannot communicate to the ISDN gateway due to a failure in the gateway. Additionally, the SCTP association may also be down. To correct the primary cause of the alarm, verify the whether or not the SCTP association is down and restore the SCTP association. The secondary cause of the alarm is that the IUA layer may be down in the gateway. If the IUA layer is down, it will be automatically recovered no further action is required.

The Integrated Services Digital Network Signaling Gateway Inactive alarm (major) indicates that a shutdown command has been executed in the application server on the ISDN gateway side. No action needed. The application server will be automatically recovered.

The Session Initiation Protocol Server Group Element Operationally Out of Service alarm (critical) is issued when the BTS 10200 is unable to communicate with a remote SIP party. The primary cause of the alarm is that the BTS 10200 is unable to communicate with a remote SIP party (call-agent or proxy) over a SIP server group element. To correct the primary cause of the alarm, verify DNS resolution exists if TSAP address of the remote entity is a domain name. Verify the remote entity is reachable by ICMP ping, using the TSAP address from the Event Report. If the same alarm is reported for other TSAP addresses on several softswitch trunk groups and/or server-group elements, then verify that the network connection is operational. The secondary cause of the alarm is that the remote SIP party is not operational. To correct the secondary cause of the alarm, diagnose the issue that prevents the TSAP address from being reached if a ping is not successful. Verify that the SIP application is running on the remote host and listening on the port specified in the TSAP address.

Routing Key Inactive—Signaling (163)

The Routing Key Inactive alarm (major) indicates that INACTIVE acknowledgement messages were received from a Signaling Gateway. The SG or SCTP associations are probably down. To troubleshoot and correct the primary cause of the Routing Key Inactive alarm, investigate other alarms to see if SGs are down or the SCTP associations are down. Take corrective action according to those alarms. Also check the AS status for the routing context on ITP.

Signaling Gateway Traffic Mode Mismatch—Signaling (164)

The Signaling Gateway Traffic Mode Mismatch alarm (major) indicates that the traffic mode does not match on the BTS 10200 and the Signaling Gateway. To troubleshoot and correct the primary cause of the Signaling Gateway Traffic Mode Mismatch alarm, verify the AS traffic-mode configuration in the Signaling Gateway. Check that the SG internal redundancy mode for the traffic-mode setting has been set correctly in the BTS 10200.

Residential Gateway Endpoints are out of Service at the Gateway—Signaling (170)

The Residential Gateway Endpoints are out of Service at the Gateway alarm (minor) indicates that the residential gateway has been administratively taken OOS using the command at the gateway. To troubleshoot and correct the primary cause of the Residential Gateway Endpoints are out of Service at the Gateway alarm, bring the residential gateway administratively into INS using the command at the gateway.

Residential Gateway Unreachable—Signaling (171)

The Residential Gateway Unreachable alarm (minor) indicates that a MGCP signaling interop error has occurred with the residential media gateway. To troubleshoot and correct the primary cause of the Residential Gateway Unreachable alarm, check the IP connectivity status between the BTS 10200 call agent and the trunking gateway if the residential gateway is not physically connected, but controlled INS at the BTS 10200.

The Multimedia Terminal Adapter Effective-Aggr-Id Becomes Unavailable Due to Its IP Address alarm (major) indicates that the MTA has been moved to new subnet which is not provisioned, or provisioned with the aggr-id=NULL. To troubleshoot and correct the primary cause of the Multimedia Terminal Adapter Effective-Aggr-Id Becomes Unavailable Due to Its IP Address alarm, provision the subnet aggr-id for the MTA.

The ENUM Server Domain Cannot be Resolved Into Any IP Address alarm (critical) indicates that a misconfiguration has occurred in the DNS configuration. To troubleshoot and correct the cause of the alarm, fix the DNS configuration according the documentation.

ENUM Server Unavailable—Signaling (174)

The ENUM Server Unavailable alarm (critical) indicates that a network or server problem has occurred. To troubleshoot and correct the cause of the alarm, fix the network or server problem.

ENUM Server Farm Unavailable—Signaling (175)

The ENUM Server Farm Unavailable alarm (critical) indicates that a network or server problem has occurred. To troubleshoot and correct the cause of the alarm, fix the network or server problem.

No Resources Available to Launch ENUM Query—Signaling (176)

The No Resources Available to Launch ENUM Query alarm (critical) indicates that no resources are available to launch the ENUM query. The primary cause of the alarm is that there is internal or network congestion or that the server response is slow. To troubleshoot and correct the primary cause of the alarm, fix the network congestion or improve the server response.