Table Of Contents
General Troubleshooting
Introduction
Troubleshooting CORBA Problems
Troubleshooting Local Number Portability Problems
Resolving Local Number Portability Conflicts
Audit Requests
Report Requests
Troubleshooting Alerting Notification Problems
Command Responses
Success and Failure Responses
Termination Reason Responses
Trunk Reason Responses
Trunk Termination Reason Responses, Signaling System 7 Only
Fault Reason Responses
Protocol Troubleshooting
Troubleshooting Signaling System 7 SIGTRAN Problems
Cisco Internet Protocol Transfer Point Troubleshooting Procedures
Using BTS 10200 Command Line Interface Commands
Viewing BTS 10200 Logs
'Troubleshooting Transaction Capabilities Application Part with the Query Verification Tool
Debugging Network Related Transaction Capabilities Application Part/Signaling Connection Control Part Problems
Troubleshooting H.323 Problems
Outgoing Trunk Group is Out of Service
Outgoing H.323 Gateway is Out of Service
H.323 Gateway Fails to Register With Gatekeeper (Invalid Alias)
Outgoing H.323 Gateway Unregistered With Gatekeeper and Needs to Use Registration, Admissions, and Status
Stable Calls Are Dropped When Call Agent Switches Over
No Matching Dial Plan Found on Incoming H.323 Trunk Group
Configuration at Softswitch or Gatekeeper Has Placed Routing Into a Loop
Outgoing H.323 Calls Routed to Incorrect Endpoint When Using Registration, Admissions, and Status
Outgoing H.323 Calls Routed to Incorrect Endpoint When Using Direct Signaling
Registration, Admissions, and Status Still Used When Outgoing H.323 Call is Provisioned to Use Direct Signaling
Troubleshooting Integrated Services Digital Network Problems
How to Troubleshoot When the Integrated Services Digital Network Trunk Group Fails to Restore
Checking the Status of a Trunk Termination
Checking Media Gateway Provisioning
Additional Command Line Interface Verification
Maintenance of a Call Agent Connected to an Integrated Services Digital Network Trunk Group
File Configuration-bts.properties
Editing-bts.properties
Example Edit-bts.properties
Privacy Screening Troubleshooting
Symptom One
Solution One
Symptom Two
Solution Two
Symptom Three
Solution Three
Symptom Four
Solution Four
Call Agent Controlled Mode for RFC 2833 DTMF Relay Troubleshooting
General Troubleshooting Procedures
Basic Call Cannot Be Established
No DTMF Relay Involving H.323 Endpoints
NCS I10 and Audit Connection Troubleshooting
General Troubleshooting Information
Troubleshooting the Timeout Queue
Troubleshooting QoS
Troubleshooting Audit Connection
Multi-Lingual Support Troubleshooting
Viewing Trace Logs for Throttled Flood of MGCP Messages from Specific Endpoint
Platform Core File Alarm
Planning
Prerequisites
Restrictions and Limitations
Configuring
General Troubleshooting
Revised: December 11, 2008, OL-8723-17
Introduction
The chapter provides the general troubleshooting information needed to conduct troubleshooting on the Cisco BTS 10200 Softswitch. This chapter is divided into the following sections:
•
Troubleshooting CORBA Problems—Provides a reference to the Common Object Request Broker Architecture (CORBA) troubleshooting information in the BTS 10200 CORBA Adapter Interface Specification Programmer Guide.
•Troubleshooting Local Number Portability Problems—Provides the information to solve local number portability (LNP) problems.
•Troubleshooting Alerting Notification Problems—Explains how to troubleshoot the system when the 3PTYFS does not appear to be receiving the alerting notification and call data.
•Command Responses—Describes success and failure responses to commands, as well as values for the term-reason and trunk-reason responses.
•Protocol Troubleshooting—Provides the troubleshooting information for resolving BTS 10200 protocol problems.
•File Configuration-bts.properties—Provides instructions for editing and configuring the bts.properties file.
•Privacy Screening Troubleshooting—Provides instructions for troubleshooting privacy screening.
•Call Agent Controlled Mode for RFC 2833 DTMF Relay Troubleshooting—Describes general troubleshooting procedures related to the call agent controlled mode for RFC 2833 DTMF relay.
•NCS I10 and Audit Connection Troubleshooting—Describes the general troubleshooting procedures related to NCS I10 and the audit connection.
•Multi-Lingual Support Troubleshooting—Describes the general troubleshooting procedures related to multi-lingual support.
•Viewing Trace Logs for Throttled Flood of MGCP Messages from Specific Endpoint—Describes the general troubleshooting procedures related to viewing trace logs for a throttled flood of MGCP messages.
Caution The use of the UNIX
ifconfig down command on any signaling interface to test or troubleshoot network or interface failures of the BTS 10200 Signaling Interface may lead to undesirable consequences or conditions.
Troubleshooting CORBA Problems
To troubleshoot CORBA interface problems, refer to the BTS 10200 CORBA Adapter Interface Specification Programmer Guide, Chapter 5.
Troubleshooting Local Number Portability Problems
Problems can arise when porting a subscriber's telephone number from one service provider to another. The Network Interconnection Interoperability Forum (NIIF), a part of the Alliance for Telecommunications Industry Solutions (ATIS) organization, has published a document (ATIS/NIIF-0017) that includes detailed steps that service providers should follow when LNP problems are encountered. The document is titled Guidelines for Reporting Local Number Portability Troubles in a Multiple Service Provider Environment, and it is available at https://www.atis.org/docstore/default.aspx.
The NIIF also maintains the National LNP Contact Directory, a protected document that provides telephone numbers of 24 by 7 LNP-qualified contacts for each service provider. The directory is located at the URL given above. You can download and submit an application for a password at the same URL.
Resolving Local Number Portability Conflicts
Some conflicts can arise in the LNP processes. Figure 14-1 illustrates the causes of conflicts and the procedures that the Number Portability Administration Center (NPAC) service management system (SMS) uses to resolve them.
If either the old or new service provider did not send a notification to the NPAC SMS, the NPAC SMS notifies the service provider from which it did not receive a notification that it is expecting a notification. If the NPAC SMS receives the missing notification, and both notifications indicate agreement among the service providers, the process proceeds as normal.
The following list describes the actions that the NPAC SMS takes in different situations:
•If the NPAC SMS does not receive a concurring notification from the old service provider, the NPAC SMS logs the failure to respond and allows the new service provider to proceed with activation when the new service provider due date is reached.
•If the NPAC SMS does not receive a concurring notification from the new service provider, the NPAC SMS logs the failure to respond, cancels the request, and notifies both service providers of the cancellation.
•If the service providers disagree as to who will provide service for the telephone number, the NPAC SMS places the request in the "conflict" state and notifies both service providers of the conflict status and the Status Change Cause Code.
–The service providers then determine between them who will serve the customer using their internal business processes.
–When a resolution is reached, the NPAC SMS is notified by the new service provider and removes the request from the conflict state.
Within the first 6 hours, only the old service provider can initiate "conflict off." After 6 hours, either service provider can remove the conflict status. The new service provider can alternatively request cancellation of the Subscription Version.
Figure 14-1 Conflict Resolution Work Flow
Audit Requests
An audit function is necessary for troubleshooting customer problems and as a maintenance process to ensure Subscription Version data integrity across the entire LNP network. Audits are concerned with the process of comparing the NPAC SMS view of the LNP network's Subscription Version data with one or more of the service provider's views of its network.
The following methods help ensure data integrity across the LNP network:
•On-demand audits can be initiated by any service provider who believes a problem may exist in another service provider's network. These audits are executed through queries to the appropriate service provider's network, and corrected by means of downloads to those same networks.
•Local service providers are also responsible for comparing database extracts of Subscription data written to an File Transfer Protocol (FTP) site by the NPAC SMS with their own versions of the same Subscription data.
•The NPAC SMS selects a random sample of active Subscription Versions from its own database, then compares those samples to the representation of that same data in the various local SMS databases.
Report Requests
The NPAC SMS supports report generation for predefined and ad hoc reports. The report generation function creates output report files according to specified format definitions, and distributes reports to output devices as requested. The report distribution service supports distribution to electronic files, to local or remote printers, to e-mail addresses, and to fax machines.
Troubleshooting Alerting Notification Problems
This section explains how to troubleshoot the system when the 3PTYFS does not appear to be receiving the alerting notification and call data.
Step 1 Verify that the ID, transport service access point (TSAP) ADDR, and TYPE are properly provisioned in the FEATURE-SERVER table.
Step 2 Verify that the alerting notification feature (ALERT_NOTIFY) is provisioned properly.
Step 3 Verify one of the following two cases, as applicable:
•Verify that the ALERT_NOTIFY feature is included in the SERVICE table applicable to the specific subscriber.
•Verify that Alerting Notification is included in the SERVICE table applicable to the specific POP (the service ID identified by the office-service-id token in the POP table).
•Verify that the ALERT_NOTIFY feature is included in the default office service ID (if the feature is intended to be offered to all subscribers on the switch).
Note In the procedures included in this document, the alerting notification feature is provisioned using the feature identifier FNAME=ALERT_NOTIFY. The feature identifier can be any unique string of up to 16 ASCII characters chosen by the service provider. If you are not sure of the name used in your system for this feature, use the SHOW FEATURE command and view the system response to find the name.
Example:
SHOW FEATURE-SERVER;
SHOW FEATURE FNAME=ALERT_NOTIFY;
SHOW CA-CONFIG TYPE=DEFAULT-OFFICE-SERVICE-ID;
SHOW SERVICE ID=<the value of the default-office-service-id>
SHOW SERVICE ID=6543;
SHOW SUBSCRIBER-SERVICE-PROFILE SERVICE-ID=6543;
Step 4 If a TSAP address is used for the 3PTYFS, verify that the domain name is correctly provisioned in the DNS and resolves to the intended 3PTYFS.
Step 5 Enter the CLI command to check for Signaling alarm #12—Feature Server is not up or is not responding to Call Agent. If this alarm is raised, there is a communications problem between the BTS 10200 and the 3PTYFS.
Example:
show alarm type=signaling;
show alarm type=signaling; number=12;
The following details apply to SIGNALING alarm #12:
–For a 3PTYFS that is more than one hop away from the BTS 10200, SIGNALING alarm #12 is raised when communications between the BTS 10200 and the first-hop node go down. However, the alarm is not raised if communications on the second (or more distant) hop go down, or if the DNS value for the 3PTYFS does not resolve correctly.
–The system can take up to two minutes to detect a communications failure in the first hop toward the 3PTYFS.
Step 6 Verify that you have connectivity from the BTS 10200 to the 3PTYFS.
Step 7 Verify that the 3PTYFS is provisioned to support this feature in accordance with the applicable product documentation. The BTS 10200 does not send any provisioning or status/control commands to the 3PTYFS.
Step 8 Verify that the 3PTYFS and peripheral devices are operating properly according to the applicable product documentation.
Command Responses
This section describes success and failure responses to commands, as well as values for the term-reason and trunk-reason responses.
Note In this section, an asterisk preceding a token name means the token is mandatory. A token without an asterisk is optional.
Success and Failure Responses
The following message is returned upon the success of a command:
Configuration Command Executed.
One of the following responses can be returned upon the failure of a command:
•Administrative (ADM) found no failure.
•ADM MGW(s) cannot be found.
•ADM subscriber(s) cannot be found.
•ADM trunk group(s) cannot be found.
•ADM trunk(s) cannot be found.
•ADM no termination(s) found in MGW.
•ADM no trunk group(s) found in trunking gateway.
•ADM no trunk(s) found in trunk group.
•ADM fail while in termination table.
•ADM fail while in trunk group table.
•ADM fail while in trunk table.
•ADM fail while looking to find trunk index.
•ADM fail while getting MGW administration state.
•ADM fail while getting trunk group administration state.
•ADM fail while looking for MGW index.
•ADM administration state invalid.
•ADM failed to allocate inter-process communication (IPC) message(s).
•ADM failed to dispatch IPC message(s).
•ADM operational state invalid.
•ADM MGW(s) state change and pending.
•ADM subscriber(s) state change and pending.
•ADM trunk group(s) state change and pending.
•ADM trunk(s) state change and pending.
•ADM found subscriber category invalid.
•ADM found trunk group type invalid.
•ADM found trunk group state invalid.
•ADM found MGW admin state not ready.
•ADM found trunk group admin state not ready.
•ADM entity in desired state.
•ADM not allow trunk to reset.
•ADM not allow subscriber to reset.
•ADM change to out-of-service state required.
•ADM change to request graceful mode error.
•ADM found entity unequipped in initial state.
•ADM operation not allowed because D Channel(s) is down.
•The H.323 Gateway was not found in database management (DBM).
•ADM found unknown failure reason(s).
Termination Reason Responses
The following responses can be returned for the termination reason (term-reason) response for subscriber termination and trunk termination commands:
•All of wildcard too complicated
•Channel-associated signaling (CAS) signaling protocol error
•Codec negotiation failure
•Endpoint does not have a digit map
•Endpoint malfunctioning
•Endpoint redirected to another Call Agent
•Endpoint taken out of service
•Error in RemoteConnectionDescriptor
•Event/signal parameter error
•Facility failure
•Failure of a grouping of trunks
•Incompatible protocol version
•Insufficient bandwidth at this time
•Insufficient bandwidth
•Internal consistency in local connection options
•Internal hardware failure.
•Invalid call ID
•Invalid conn identifier
•Invalid or unsupported command parameter
•Invalid or unsupported LocalConnectionOptions
•Loss of lower connectivity
•Loss of lower layer connectivity
•Manual intervention
•Missing remote connection descriptor
•Missing remote connection descriptor
•No fault reason available
•No such event or signal
•Packetization period not supported
•Per endpoint connection limit exceeded
•Quality of service (QoS) resource reservation was lost
•Response too big
•The media gateway is down
•The media gateway is in a faulty state
•The media gateway is transitioning to another state
•The media gateway is unreachable
•The phone is already off hook
•The phone is already on hook
•The transaction could not be executed because a protocol error was detected
•The transaction could not be executed because of internal overload
•The transaction could not be executed because the command contained an unrecognized extension
•The transaction could not be executed because the endpoint is not ready
•The transaction could not be executed because the endpoint is restarting
•The transaction could not be executed because the endpoint is unknown
•The transaction could not be executed because the gateway cannot send the specified announcement.
•The transaction could not be executed because the gateway is not equipped to detect one of the requested events
•The transaction could not be executed because the gateway is not equipped to generate one of the requested signals
•The transaction could not be executed, because the endpoint does not have sufficient resources at this time
•The transaction could not be executed, because the endpoint does not have enough resources available [permanent condition]
•The transaction could not be executed, because the endpoint is [restarting]
•The transaction could not be executed, due to a transient error
•The transaction could not be executed, due to some unspecified transient error
•The transaction could not be executed, endpoint does not have enough resources available
•The transaction has been queued. An actual completion message will follow later
•The transaction is currently being executed. An actual completion message will follow later
•The transaction refers to an incorrect connection-id
•The transaction refers to an unknown call Id
•The transaction time out
•The transaction was aborted by some external action
•Unknown action or illegal combination of actions
•Unknown extensions in local connection options
•Unknown or unsupported command
•Unknown or unsupported digit map extension
•Unknown or unsupported quarantine handling
•Unknown or unsupported RestartMethod
•Unsupported or invalid mode
•Unsupported or unknown package
•Unsupported values on local connection options
Trunk Reason Responses
The following responses can be returned for the trunk reason (trunk-reason) response. One or more values can be returned, depending upon the operating conditions of the Call Agent.
•ACL_CONGESTION_LEVEL_1—automatic congestion level (ACL) congestion is at level 1.
•ACL_CONGESTION_LEVEL_2—ACL congestion is at level 2.
•ACL_CONGESTION_LEVEL_3—ACL congestion is at level 3.
•DPC_INACCESSIBLE—the DPC is not accessible.
•HARDWARE-BLOCK—trunk-termination is manually controlled OOS (controlled mode=FORCED).
•MAINT-BLOCK—trunk-termination is manually controlled OOS (controlled mode=GRACE).
•MAINT-BUSY—trunk-termination is in maintenance state; controlled to MAINT.
•MAINT-OOS—trunk-termination is manually controlled OOS. (There is no difference between this and a BLOCK.)
•NON-FAULTY—Not blocked, available for service.
•OUTGOING_RESTRICTED—the outgoing call is not allowed.
•SIGNALLING-FAULT—Cannot exchange messages with public switched telephone network (PSTN) network:
–dpc unavailable
–user part unavailable
–stcp association unavailable
–Signaling link is faulty.
–dpc congestion
•TERM-FAULT—Bearer termination is in faulty condition.
•TFC_CONGESTION_LEVEL_1—Transfer controlled (TFC) congestion is at level 1.
•TFC_CONGESTION_LEVEL_2—TFC congestion is at level 2.
•TFC_CONGESTION_LEVEL_3—TFC congestion is at level 3.
•TFC_INTL_CONGESTION
•UNKNOWN_REASON
Trunk Termination Reason Responses, Signaling System 7 Only
The following responses can be returned for the trunk terminations on SS7 trunks. One or more values can be returned, depending upon the operating conditions of the Call Agent, in addition to the reason responses listed under Trunk Reason Responses.
•ACT_LOC_INIT_RESET—Reset circuit at startup as specified by command line argument for SGA process in the platform.cfg. Remains set until reset circuit (RSC)/group reset (GRS) and release complete (RLC)/group reset acknowledge (GRA) messages are exchanged with the remote switch.
•ACT_LOC_MML_RESET—This is set when the reset command is issued from the CLI and remains set until reset is performed. Remains set until RSC/GRS and RLC/GRA messages are exchanged with the remote switch.
•ACT_LOC_QUERY—This is set when the a diagnostic command is issued from the CLI to perform a circuit query and remains set until circuit query message (CQM) and circuit query response (CQR) messages are exchanged with a remote switch.
•ACT_LOC_UPU—This is set when ITP informs that the user part is unavailable and remains set until a circuit verification response (CVR) is received or the ITP informs that the user part is available. The first incoming message will also clear this response.
•ACT_LOC_VALIDATE—This is set when the a diagnostic command is issued from the CLI to perform a circuit validation and remains set until circuit validation test (CVT) and CVR messages are exchanged with the remote switch.
•ACT_LOC_COTTEST—This is set when the a diagnostic command is issued from the CLI to perform a customer-originated trace (COT) test and remains set until SRINI TO CHECK messages are exchanged with the remote switch.
•ACT_LOC_STOP—This is set to clear a call when a term-fault is received.
•BLK_LOC_UPU—This is set when a trunk is blocked because user part is unavailable.
•DES_LOC_GRACE—Local hardware restart in progress (RSIP) graceful.
•DES_LOC_SIG—SS7—This is set when cannot exchange messages with PSTN network (a signaling fault):
–dpc unavailable
–user part unavailable
–stcp association unavailable
–Signaling link is faulty.
–dpc congestion
•SIGNALLING-FAULT-This is set to indicate that the BTS 10200 processed a DES_LOC_SIG—SS7 signaling fault.
•DES_LOC_FORCE—Local hardware failure.
•DES_LOC_MML—MMLQ—This is set when a control command is issued with mode=graceful and target-state=OOS. Also set during CQR processing.
•DES_LOC_UPU—This is set when user part is unavailable.
•JOB_PENDING—Ongoing job in progress. There is an ongoing action of message exchange with the remote switch.
•JOB_REC—Job was received by the message definition language (MDL) component and is being processed.
•OPER_ACTIVE—Trunk is available for calls.
•REMOTE_GRACE—Trunk is blocked remotely because of a CLI command on the remote switch.
•REMOTE_FORCE—Trunk is blocked remotely because of a hardware failure on the remote switch.
•RESERVE_SPARE1—Reserved for future use.
•RESERVE_SPARE2—Reserved for future use.
•TERM_GRACE—Trunk is gracefully blocked because of an RSIP from the MGW.
Fault Reason Responses
The following responses can be returned for the fault reason (fault-reason) response for a subscriber termination command. One or more values can be returned, depending upon the operating conditions of the Call Agent.
•The media gateway is down.
•The media gateway is unreachable.
•The media gateway is in a faulty state.
•The media gateway is transitioning to another state.
•The transaction could not be executed, due to a transient error.
•The transaction could not be executed because the endpoint is unknown.
•The transaction could not be executed because the endpoint is not ready.
•The transaction could not be executed, endpoint does not have enough resources available.
•The transaction could not be executed because a protocol error was detected.
•The transaction could not be executed because the command contained an unrecognized extension.
•The transaction could not be executed because the gateway is not equipped to detect one of the requested events.
•The transaction could not be executed because the gateway is not equipped to generate one of the requested signals.
•The transaction could not be executed because the gateway cannot send the specified announcement.
•Invalid conn identifier.
•Invalid call ID.
•Unsupported mode or invalid mode.
•Unsupported or unknown package.
•Endpoint does not have a digit map.
•The transaction could not be executed because the endpoint is restarting.
•Endpoint redirected to another Call Agent.
•No such event or signal.
•Unknown action or illegal combination of actions.
•Internal consistency in local connection options.
•Unknown extensions in local connection options.
•Insufficient bandwidth.
•Missing remote connection descriptor.
•Incompatible protocol version.
•Internal hardware failure.
•CAS signaling protocol error.
•Failure of a group of trunks.
•Unsupported values on local connection options.
•Response too big.
•Endpoint malfunctioning.
•Loss of lower connectivity.
•Endpoint taken out of service.
•No fault reason available.
Protocol Troubleshooting
This section provides the troubleshooting information for resolving BTS 10200 protocol problems.
Troubleshooting Signaling System 7 SIGTRAN Problems
This section describes tools and procedures for troubleshooting SIGTRAN problems on the BTS 10200 and Cisco ITP. It also describes how to clear SIGTRAN related BTS 10200 alarms. In the descriptions within, a series of steps may be required to determine the source of the problem and may include viewing other alarms, invoking command-line interface (CLI) status and control commands,viewing the BTS 10200 logs, and invoking ITP control and status requests.
For details on Cisco ITP operations, refer to the Cisco IP Transfer Point Manual at the following url:
http://www.cisco.com/univercd/cc/td/doc/product/wireless/moblwrls/itp/
This section contains the following sections:
•Cisco Internet Protocol Transfer Point Troubleshooting Procedures
•Viewing BTS 10200 Logs
•'Troubleshooting Transaction Capabilities Application Part with the Query Verification Tool
Cisco Internet Protocol Transfer Point Troubleshooting Procedures
The following procedures are useful for troubleshooting problems on the Cisco ITP. This section contains the following procedures:
•Internet Protocol Transfer Point System Messages
•Logging On to the Internet Protocol Transfer Point
•Viewing the Internet Protocol Transfer Point Configuration
•Internet Protocol Transfer Point Status Commands
•Controlling Internet Protocol Transfer Point Resources
Internet Protocol Transfer Point System Messages
The Cisco ITP displays system messages when you are logged in to the console port. Some of these messages are similar to alarms. Analyzing ITP system messages is outside the scope of this document. For details concerning ITP system messages, please see the ITP Operations Manual at:
http://www.cisco.com/univercd/cc/td/doc/product/wireless/moblwrls/itp/23sw/index.htm
Logging On to the Internet Protocol Transfer Point
Some of the troubleshooting sections in this chapter require the user to log on to the ITP. Access the ITP through the associated console server or through direct access with a console cable. You need the username and password to access the ITP.
Troubleshooting the ITP will require you to be in ITP enable mode. The enable mode is password protected. To get into enable mode, after logging in to the ITP, type enable. You will be prompted for the enable password.
Viewing the Internet Protocol Transfer Point Configuration
To view the ITP configuration, log in to the ITP and get into enable mode. Enter the command show run. The configuration will be displayed. Continue to hit the enter key until you have viewed the entire configuration, or type "q" to stop viewing the configuration.
Internet Protocol Transfer Point Status Commands
The following ITP commands are helpful for displaying the status of ITP resources:
•show cs7 as—Retrieves the application server (AS) status
•show cs7 asp—Retrieves the application service provider (ASP) status
•show cs7 linkset—Retrieves the Signaling System 7 (SS7) linkset status
•show cs7 route—Retrieves the SS7 route status
•show cs7 group state—Retrieves the signaling gateway (SG) group status
Controlling Internet Protocol Transfer Point Resources
Change the administrative state of an ITP resource as follows:
Step 1 Log on to the ITP, and get into configure mode.
Step 2 Type the first configuration line of the resource that you want to control.
Step 3 Type shut to take the resource out of service, or type no-shut to place the resource back in service.
The following example takes a linkset out of service:
va-2651-33#conf t
Enter configuration commands, one per line va-2651-33(config-cs7-ls)#
va-2651-33(config)#cs7 linkset lset1 1.1.20
va-2651-33(config-cs7-ls)#shut
*May 19 12:32:13.827: %CS7MTP3-5-ACTDEACTLINKSET: Linkset lset1 deactivation is in progress
*May 19 12:32:13.827: %CS7MTP3-5-LINKUPDOWN: Link 0 in linkset lset1 is down
To put the linkset back in service, type the following command:
va-2651-33(config-cs7-ls)#no shut
*May 19 12:33:47.704: %CS7MTP3-5-ACTDEACTLINKSET: Linkset lset1 activation is in progress
*May 19 12:33:47.704: %CS7MTP3-5-ACTDEACTLINK: Link 0 linkset lset1 activation is in progress
Using BTS 10200 Command Line Interface Commands
In the following sections, examples of BTS 10200 CLI commands are used to aid in resolving BTS 10200 alarms. The following CLI commands are helpful to display and clear alarms:
To display all the currently active alarms, enter the following command at a CLI prompt:
To display all alarms of a specific type, enter:
show alarm type=<alarm type>
To clear an alarm, enter the following command:
clear alarm id=<alarm id>
For a detailed description of the CLI commands that are used, please see the BTS 10200 Command Line Interface Reference Guide, Release 4.5, at the following universal resource locator (URL):
http://www.cisco.com/univercd/cc/td/doc/product/voice/bts10200/bts4_5/cli/index.htm
Viewing BTS 10200 Logs
Viewing BTS 10200 logs is helpful when debugging MTP3 user adaptation (M3UA) related objects of the BTS 10200. Specific string patterns are printed out by the M3UA Interface Module and are useful to determine what is occurring in the log. These strings are formatted as follows:
MIM <functional area> <network object>
Functional areas include:
•Configuration (CFG)
•STATUS
•Protocol decode unit (PDU)
•STATISTICS
•Control (CTRL)
•PLATFORM
Network objects include:
•Stream Control Transmission Protocol (SCTP)
•Signaling gateway process (SGP)
•SG
•Destination point code (DPC)
•Originating point code (OPC)
•Routing key (RKEY)
•CC_ROUTE
Search or grep the following example strings when searching the BTS 10200 logs:
•M3UA Interface Module (MIM) CFG SCTP—Display how the SCTP has been configured at startup.
•MIM PDU—Trace incoming and outgoing ISUP messages at the MIM layer.
•MIM STATUS DPC—Display how the DPC status has changed in the system.
•MIM STATUS SCTP—Display how the SCTP status has changed in the system.
•MIM PLATFORM—Determine if a platform state change has been issued to the SGA/MIM module.
•MIM CTRL SCTP—Determine if an SCTP association has been administratively taken out of service or put back in service.
'Troubleshooting Transaction Capabilities Application Part with the Query Verification Tool
The Query Verification Tool (QVT) enables a user to generate Transaction Capabilities Application Part (TCAP) queries to external databases through the CLI interface. For information about the Query Verification Tool, refer to the following URL:
http://www.cisco.com/en/US/docs/voice_ip_comm/bts/4.4/feature/module/QVTTVT.html
This section contains the following:
•Table Configuration Problems
Table Configuration Problems
The CLI query command with the table-info option displays the tables used for routing the external SS7 queries on the BTS 10200. The query command can identify the following problems:
•Missing Call Agent (CA)-CONFIG table
•Missing SLHR-PROFILE table
•Missing Service Logic Host Route (SLHR) table
•Missing DPC table
•Missing OPC table
•Missing SUBSYSTEM-PROFILE table
•Missing SUBSYSTEM table
•Missing signaling connection control part (SCCP)-network (NW) table
•Missing SCCP-ROUTE table
•Missing ROUTING-KEY table
•Missing SG group (GRP) table
•Missing SG table
•Missing SGP table
•Missing SCTP-ASSOC table
To resolve a table error, add the appropriate entry to the table specified in the command response.
Debugging Network Related Transaction Capabilities Application Part/Signaling Connection Control Part Problems
The CLI query command can provide information about network related problems. This section describes problems identified by the query command and the solutions to them.
This section contains the following:
•No Translation for an Address of Such Nature
•No Translation for this Specific Address
•Subsystem Congestion
•Subsystem Failure
•Unequipped User
•Network Failure
•Network Congestion
•Unqualified
•Error In Message Transport
•Destination Cannot Perform Reassembly
•Signaling Connection Control Part Failure
•Segmentation Not Supported
•Segmentation Failure
•Query Verification Tool Timeout
•Command Line Interface Timeout
No Translation for an Address of Such Nature
Layer
|
SCCP
|
Version
|
ITU88, ITU92, ITU96, ANSI88, ANSI92
|
Location
|
Signal transfer point (STP)
|
Cause
|
The global title translation (GTT) entry is not provisioned correctly in the STP.
|
Solution
|
Correct the GTT entry in the STP.
|
No Translation for this Specific Address
Layer
|
SCCP
|
Version
|
ITU88, ITU92, ITU96, ANSI88, ANSI92
|
Location
|
STP
|
Cause
|
The GTT entry is not provisioned correctly in the STP.
|
Solution
|
Add the GTT entry in the STP.
|
Subsystem Congestion
Layer
|
SCCP Subsystem (TCAP)
|
Version
|
ITU88, ITU92, ITU96, ANSI88, ANSI92
|
Location
|
Service control point (SCP)
|
Cause
|
The SCP subsystem is congested.
|
Solution
|
Ask the SCP Service Provider to solve the congestion problem
|
Subsystem Failure
Layer
|
SCCP Subsystem (TCAP)
|
Version
|
ITU88, ITU92, ITU96, ANSI88, ANSI92
|
Location
|
SCP
|
Cause
|
The SCP is down or the subsystem of the SCP is down.
|
Solution
|
Verify that the SCP point code is correct.
|
Unequipped User
Layer
|
SCCP Subsystem (TCAP)
|
Version
|
ITU88, ITU92, ITU96, ANSI88, ANSI92
|
Location
|
SCP
|
Cause
|
The SCCP user is not equipped
|
Solution
|
Verify that the SCP point code is correct
|
Network Failure
Layer
|
MTP3/MTP2/MTP1 or SCTP
|
Version
|
ITU88, ITU92, ITU96, ANSI88, ANSI92 for NTP3/2/1, Internet Engineering Task Force (IETF) RFC 2960 for SCTP
|
Location
|
Local, STP, or SCP
|
Cause
|
The Broadband Telephony Softswitch (BTS)-ITP sctp-association is down or the SS7 link, linkset, or route is down.
|
Solution
|
See Chapter 13, "Network Troubleshooting," section assistance in solving this problem.
|
Network Congestion
Layer
|
SCCP
|
Version
|
ITU88, ITU92, ITU96, ANSI88, ANSI92
|
Location
|
Local, STP, or SCP
|
Cause
|
The SCTP layer or the SS7 network is congested.
|
Solution
|
The service provider of the SS7 network needs to either provide higher capacity or re-engineer the traffic. SCTP layer congestion normally indicates insufficient central processing unit (CPU) power. Hardware needs to be upgraded or more BTS 10200 need to be added to offload traffic.
|
Unqualified
Layer
|
SCCP
|
Version
|
ITU88, ITU92, ITU96, ANSI88, ANSI92
|
Location
|
STP or SCP
|
Cause
|
Unknown.
|
Solution
|
Contact the support team or developer for assistance.
|
Error In Message Transport
Layer
|
SCCP
|
Version
|
ITU92
|
Location
|
STP
|
Cause
|
There was a failure in message transportation.
|
Solution
|
Contact the support team or the developer.
|
Destination Cannot Perform Reassembly
Layer
|
SCCP
|
Version
|
ITU88, ITU92, ITU96, ANSI88, ANSI92
|
Location
|
SCP
|
Cause
|
The peer side is not capable of reassembling extended unit data service (XUDTS) packets.
|
Solution
|
The ITP does not support segmentation and reassembly. Contact the Cisco Technical Assistance Center (TAC) for assistance.
|
Signaling Connection Control Part Failure
Layer
|
SCCP
|
Version
|
ITU88, ITU92, ITU96, ANSI88, ANSI92
|
Location
|
Local, STP, or SCP
|
Cause
|
The SCCP layer failed or the local TCAP signaling adapter (TSA) could not find the appropriate entry in the Subsystem table or the SCCP-nw table.
|
Solution
|
Add or properly populate the Subsystem and SCCP-nw tables. If it still does not work, restart the platform providing the service (Feature Server for AIN services (FSAIN) or Feature Server for POTS, Tandem, and Centrex services (FSPTC)).
|
Hop Counter Violation
Layer
|
SCCP
|
Version
|
ITU96, ANSI92
|
Location
|
STP
|
Cause
|
The maximum hop count is exceeded during the message routing.
|
Solution
|
Make sure the hop count value provisioned in the SCCP-NW table is not too small. Verify that the SS7 network provider does not have any route-loops.
|
Segmentation Not Supported
Layer
|
SCCP
|
Version
|
ITU96
|
Location
|
SCP
|
Cause
|
The peer side is not capable of reassembling XUDTS packets.
|
Solution
|
The ITP does not support segmentation and reassembly. Contact the Cisco TAC for assistance.
|
Segmentation Failure
Layer
|
SCCP
|
Version
|
ITU96
|
Location
|
STP
|
Cause
|
The segmentation failed.
|
Solution
|
The ITP does not support segmentation and reassembly. Contact the Cisco TAC for assistance.
|
Query Verification Tool Timeout
