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.

Call Processing Events and Alarms

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

Note Click the call processing message number in Table 4-1 to display information about the event.

The call originated from a subscriber or trunk for a called party number that has no route available.

PRIMARYACTION

The data words in the event report indicate what parameters that need to be corrected. Refer to the office records for the subscriber.

SECONDARYCAUSE

Parameter(s) in the subscriber and/or dial-plan table are missing or incorrect for the dialed number.

SECONDARYACTION

Determine whether the routing parameters (such as digit-string) were entered correctly in the subscriber and dial-plan tables.

TERNARYACTION

If the called party is a subscriber, verify that the subscriber-type is listed as subscriber in the dial-plan table.

SUBSEQUENTACTION

If the call is long distance using a presubscribed interexchange carrier (PIC), check that the PIC for this subscriber is properly provisioned in the dial-plan table. If necessary, edit these files using the change dial-plan or change subscriber commands.

Verify whether the given DN has been provisioned correctly in the reporting BTS. If there is an error in the LNP database (SCP) or other switch, then notify the appropriate administrators. Note that porting of the subscriber and DN from the donor switch to the recipient switch, and the associated updates of the Location Routing Number (LRN) in all the SCP databases, may not all occur at exactly the same time. Therefore it must be expected that some call failures may occur until the porting process has completed at all network nodes. Once the porting process is completed, if mis-routing still occurs, then the listed actions should be taken to resolve the issue.

SECONDARYCAUSE

The LNP database (SCP) has an incorrect location routing number (LRN) for the given directory number (DN).

CALLP (45)

Context in Call from Application Server not Found (Context in Call from App Server not Found)

SEVERITY

WARNING

THRESHOLD

100

THROTTLE

0

PRIMARYCAUSE

The BTS 10200 has received an INVITE from an AS which contains a context ID in the route header which is invalid. It may be that the AS has not properly returned the Route Header.

PRIMARYACTION

Get the AS to return the BTS 10200 route header correctly

SECONDARYCAUSE

It is possible that the BTS 10200 cleared the call and removed the context before the AS returned an INVITE to the BTS 10200.

SECONDARYACTION

Check timing for the calls returned to the BTS 10200 from the AS.

Monitoring Call Processing Events

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

Test Report—Call Processing (1)

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

No Route Available for Called Number—Call Processing (8)

The No Route Available for Called Number event functions as a warning that there is no route available for the number called. The primary cause for the event is that the call originates from a subscriber or trunk for a called party number that has no route available. The Orig Type (one byte), Orig Sub or trunk group (TG) ID (eight bytes), calling party number (20), and called party number (20) data words in the event report indicate what parameters that need to be corrected. Refer to office records for the subscriber. The secondary cause for the event is that parameters in the subscriber and/or dial-plan table are missing or incorrect for the number dialed. To correct any parameter error, determine whether the routing parameters (such as digit-string) were entered incorrectly in the subscriber and dial-plan tables. If the called party is a subscriber, verify that the subscriber-type is listed as a subscriber in the dial-plan table. If the call is long distance using a PIC, check that the PIC for this subscriber is properly provisioned in the dial-plan table. If necessary, edit these files using the change dial-plan or change subscriber commands.

No Route Available for Carrier Dialed—Call Processing (9)

The No Route Available for Carrier Dialed event functions as a warning that is no route available for the dialed carrier. The primary cause for the event is that no route is available for the IXC dialed. The Orig Type (one byte), Orig Sub or TG ID (eight bytes), calling party number (20), called party number (20), and carrier code dialed (20) data words in the event report indicate the parameters that need to be corrected. Refer to office records for the carrier. The secondary cause for the event is that parameters in the carrier and/or route-grp table are missing or incorrect for the carrier. Determine whether the routing parameters were entered correctly in the carrier and/or route-grp tables. If the Carrier-ID or Route-Grp-ID are not specified, or are incorrect, in the dial-plan table, enter the correct values. Use the change carrier or change route-grp command.

Network Access Server Create Connection Error—Call Processing (13)

The Network Access Server Create Connection Error event functions as an informational alert that a network access server (NAS) create connection (CRCX) pre-authentication has failed. The event is informational and no further action is required.

Network Access Server Authentication Failure—Call Processing (14)

The Network Access Server Authentication Failure event functions as an informational alert that a NAS authentication failure has occurred. The primary cause of the event is the AAA server denied the request. Check the calling and called numbers.

The Cable Modem Termination System Easily Recognizable Identification Not Found in Media Gateway Table event functions as an informational alert that the CMTS ER ID was not found in the media gateway (MGW) table. The primary cause of the event is that the CMTS/ER entry was not found in the media gateway table. To correct the cause of the event, provision the CMTS-ER index in the media gateway table.

Route Index has No Trunk Group Assigned—Call Processing (16)

The Route Index has No Trunk Group Assigned event functions as a warning that the route index has no trunk group assigned. The primary cause of the event is that a trunk group was not assigned to the given route. To correct the cause of the event, provision a trunk group for the associated route index.

Invalid Route Index Used—Call Processing (17)

The Invalid Route Index Used event functions as a warning that an invalid route index is being used. The primary cause of the event is that an invalid route index is being used. To correct the cause of the event, correct the BTS 10200 provisioning by assigning a valid route index.

Unable to Play Announcement—Call Processing (18)

The Unable to Play Announcement event functions as a warning that an announcement was not played. The primary cause of the event is that the announcement was not provisioned correctly. To correct the primary cause of the event, check the provisioning of the announcement and verify that the announcement is provisioned correctly.

Call Routed to Unprovisioned Subscriber—Call Processing (19)

The Call Routed to Unprovisioned Subscriber event functions as a warning that a call was routed to an unprovisioned subscriber. The primary cause of the event is that the subscriber account was not properly provisioned. The correct the primary cause of the event, provision the subscriber.

No Route or Trunk Group Available to Route Call—Call Processing (20)

The No Route or Trunk Group Available to Route Call event functions as a warning that there was no route or trunk group available to route a call. The primary cause of the event is that the trunk group in the route was not provisioned correctly. To correct the primary cause of the event, verify the route and trunk group provisioning.

Call Released Due to Maximum Hop Counts Exceeded—Call Processing (21)

The Call Released Due to Maximum Hop Counts Exceeded event functions as a warning that the call was released due to the maximum hop counts being exceeded. The primary cause of the event is that the number of hops between the destinations is excessive. To correct the primary cause of the event, reduce the number of hops between the destinations.

Trunk Group Index Read Failure—Call Processing (22)

The Trunk Group Index Read Failure event functions as a warning that a trunk group index read failed. The primary cause of the event is that the trunk group index could not be retrieved from the call data. To correct the primary cause of the event, check and correct the BTS 10200 trunk group and call data provisioning.

Routing Error: Termination is Not a Subscriber—Call Processing (23)

The Routing Error: Termination is Not a Subscriber event functions as a warning that the destination termination is not a subscriber. The primary cause of the event is that the destination termination is not provisioned as a subscriber. To correct the primary cause of the event, check and correct the BTS 10200 subscriber termination provisioning.

Invalid Route for Subscriber Index—Call Processing (24)

The Invalid Route for Subscriber Index event functions as a warning that an invalid route was selected for the subscriber index. The primary cause of the event is that the route is not provisioned correctly for the specified subscriber. To correct the primary cause of the event, check and correct the BTS 10200 subscriber index provisioning.

Invalid Route Group for Subscriber Routing—Call Processing (25)

The Invalid Route Group for Subscriber Routing event functions as a warning that an invalid route group for the subscriber routing was selected. The primary cause of the event is that the route group is not provisioned correctly for the specified subscriber. To correct the primary cause of the event, check and correct the BTS 10200 route group provisioning.

Invalid Trunk Group for Subscriber Routing—Call Processing (26)

The Invalid Trunk Group for Subscriber Routing event functions as a warning that an invalid trunk group for the subscriber routing was selected. The primary cause of the event is that the trunk group is not provisioned correctly for the specified subscriber. To correct the primary cause of the event, check and correct the BTS 10200 trunk group provisioning.

The Unable to Route: Blocked by Destination Subscriber Status event functions as a warning that a call route was blocked by the destination subscriber status. The primary cause of the event is that the subscriber is not in the correct state. To correct the primary cause of the event, check and correct the BTS 10200 subscriber state provisioning.

Route Name Does Not Exist—Call Processing (28)

The Route Name Does Not Exist event functions as a warning that the requested route name does not exist. The primary cause of the event is that the route is not provisioned correctly. To correct the primary cause of the event, check and correct the BTS 10200 route provisioning.

Routing Selection Failure—Call Processing (29)

The Routing Selection Failure event functions as a warning that the routing selection failed. The primary cause of the event is that the route is not provisioned correctly. To correct the primary cause of the event, check and correct the BTS 10200 route provisioning.

Customer-Originated Trace Test Failed—Call Processing (30)

The Customer-Originated Trace Test Failed event functions as a warning that the COT test failed. The primary cause of the event is that the COT test failed. To correct the primary cause of the event, contact Cisco TAC for information on how to debug the problem.

Call Authorization Failure—Call Processing (31)

The Call Authorization Failure event functions as a warning that the call authorization failed. The primary cause of the event is an provisioning error is not allowing the call to be completed. To correct the primary cause of the event, contact Cisco TAC.

Country Code Dialing Plan Error—Call Processing (32)

The Country Code Dialing Plan Error event functions as a warning that a country code dialing plan error occurred. The primary cause of the event is that the country code was not found in the dial plan. To correct the primary cause of the event, check and correct the BTS 10200 dial plan provisioning.

Invalid Call—Call Processing (33)

The Invalid Call event functions as a warning that an invalid call was attempted. The primary cause of the event is that the call could not be completed because the number entered was invalid. To correct the primary cause of the event, check and correct the BTS 10200 provisioning. Additionally, check the number dialed.

Dial Plan Information Not Found for Digits Received—Call Processing (34)

The Dial Plan Information Not Found for Digits Received event functions as a warning that the number entered could not be located in the dial plan. The primary cause of the event is that the Call could not be completed because the number entered could not be located in the dial plan. To correct the primary cause of the event, check and correct the BTS 10200 dial plan provisioning. Additionally, check the number dialed.

Dial Plan Information for Test Call Not Found—Call Processing (35)

The Dial Plan Information for Test Call Not Found event functions as a warning that the test call could not be completed. The primary cause for the event is that the test call could not be completed because the number entered could not be located in the dial plan. To correct the primary cause of the event, check and correct the BTS 10200 dial plan provisioning. Additionally, check the number tested.

Invalid or Unknown Nature of Address—Call Processing (36)

The Invalid or Unknown Nature of Address event functions as a warning that the NOA was invalid or incorrect. The primary cause of the event is that the NOA was incorrect in the dial plan. To correct the primary cause of the event, check and correct the BTS 10200 dial plan provisioning.

Call Failure—Call Processing (37)

The Call Failure event functions as a warning that the placed call failed. The primary cause of the event is that the call failed for the reasons indicated in the data words. To correct the primary cause of the event, check the data words type of call (four bytes), calling number (20), called number (20), and failure indication (20). Once the data words are checked, contact Cisco TAC to resolve the failure indicated.

Test Call Blocked Due to Congestion or Isolation—Call Processing (39)

The Test Call Blocked Due to Congestion or Isolation event functions as a warning that the test call was blocked due to congestion or isolation. The primary cause of the event is that the IAM for test call was blocked due to congestion/isolation. To correct the primary cause of the event, correct congestion or isolation problem and place test call again from remote system

The Interactive Voice Response Real Time Transport Protocol Session Fail event functions as a warning that the IVR Real Time Transport Protocol (RTP) session failed. The primary cause of the event is that the IVR server is not ready, or the connection failed. To correct the primary cause of the event, check IVR server. The related route guide ID and/or trunk group index are provided if known at the time the event report is issued

Call Failed after Local Number Portability Query with Location Routing Number of this BTS 10200 and the Directory Number—Call Processing (42)

The Call Failed after Local Number Portability Query with Location Routing Number of this BTS 10200 and the Directory Number event serves as an information alert that the provisioning of ported-in subscriber has not been completed. To correct the primary cause of the event, verify whether the given DN has been provisioned correctly in the reporting BTS 10200. If there is an error in the LNP database (SCP) or other switch, then notify the appropriate administrators. Note that porting of the subscriber and DN from the donor switch to the recipient switch, and associated updates of the Location Routing Number (LRN) in all the SCP databases, may not all occur at exactly the same time. Therefore it must be expected that some call failures may occur until the porting process has completed at all network nodes. Once the porting process is expected to be completed, if mis-routing still occurs, then the above actions should be taken to resolve the issue. The secondary cause of the event is that the LNP database (SCP) has an incorrect LRN for the given DN.

The Call Processing Session Initiation Protocol Trigger Provisioning Error event serves as warning that a provisioning data discrepancy between the Application Server and the BTS 10200 has occurred. To correct the cause of the event, modify the provisioning data either in the BTS 10200 or the Application Server.

The Call Processing No Session Initiation Protocol Trigger Context Found event serves as a warning that an invalid "service_ref" in the SIP INVITE message coming from the Application Server has occurred. To correct the cause of the event, report the BTS 10200 and the Application Server with the received "service_ref" string to Cisco TAC.

Context in call from Application Server not Found—Call Processing (45)

The Context in call from Application Server not Found event serves as a warning that an BTS 10200 has received an INVITE from an application server which contains a context ID in the route header which is invalid. It may be that the Application Server has not properly returned the route header. Additionally, it is possible that the BTS 10200 has cleared the call and removed the context before the application server returned an INVITE message to the BTS 10200. To correct the cause of the event, get the application server to correctly return the BTS 10200 route header back to the BTS 10200 and check timing for the calls returned to the BTS 10200 from the application server.

Troubleshooting Call Processing Alarms

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

Feature Server One Link Down—Call Processing (11)

The Feature Server One Link Down alarm (minor) indicates that one link to the feature server is down. The primary cause of the alarm is that the link interface hardware is broken. To correct the primary cause of the alarm, check the link interface hardware and, if necessary, reconnect or replace. The secondary cause of the alarm is the that the link interface state is operationally down. To correct the secondary cause of the alarm, check the operational state of the link.

To check the operational state of the interface link and the physical condition of the interface link, proceed as follows:

Step 1 Check status of the interface using one of the methods below (If the kstat command in Example 1 does not provide an output, try the ndd commands in example 2.):

Example 1:

mssol-ca0-a# kstat hme:0:hme0:link_up

module: hme instance: 0

name: hme0 class: net

link_up 1

mssol-ca0-a# kstat qfe:0:qfe0:link*

module: qfe instance: 0

name: qfe0 class: net

link_duplex 2

link_up 1

mssol-ca0-a# kstat qfe:0:qfe0:ifspe*

module: qfe instance: 0

name: qfe0 class: net

ifspeed 100000000

Example 2:

# ndd -set /dev/eri instance 0

# ndd -get /dev/eri link_status

1

# ndd -get /dev/eri link_mode

1

# ndd -get /dev/eri link_speed

1

Step 2 Verify the following settings:

•Duplex should be 1 (full duplex)

•Link_up or link_status should be 1 (operational)

•Link mode should be 1 (no auto negotiation).

Step 3 Verify call agent and switch interfaces are both set to full duplex no auto negotiation.

Step 4 Verify link speed is hard-coded to the same value on both ends.

Step 5 Check for any errors pertaining to the interface in /var/adm/messages* file.

Step 6 Check operational status of ethernet interface(s) on switch side as follows:

admin up / line protocol up

Step 7 Check statistics for ethernet interface(s) on the call agent side while looking for any abnormal queue/input/output errors/collisions. For example, to check stats on bge0 interface:

# netstat -i -I bge0

Ipkts Ierrs Opkts Oerrs Collis Queue

Note The packets queued (Queue) that cannot be transmitted should be 0. If not, it is possible that a cable or ethernet interface is defective.

Note The input errors (Ierrs) and the output errors (Oerrs) should be close to 0. High input errors could indicate that the network is saturated, host overload, or physical network problem. High output errors could indicate a saturated local network or a bad physical connection.

Step 9 Paste the output of "show interfaces" to the Cisco output interpreter for further analysis of the interfaces.

https://www.cisco.com/cgi-bin/Support/OutputInterpreter/home.pl

Step 10 Check the physical cable, the cable connectors, and the cable connections.

Feature Server Both Links Down—Call Processing (12)

The Feature Server Both Links Down alarm (critical) indicates that both links to the feature server are down. The primary cause of the alarm is that the link interface hardware is broken. To correct the primary cause of the alarm, check the link interface hardware and, if necessary, reconnect or replace. The secondary cause of the alarm is the that the link interface state is operationally down. To correct the secondary cause of the alarm, check the operational state of the link.

To check the operational state of the interface links and the physical condition of the interface links, proceed as follows:

Step 1 Check status of the interfaces using one of the methods below (If the kstat command in Example 1 does not provide an output, try the ndd commands in example 2.):

Example 1:

mssol-ca0-a# kstat hme:0:hme0:link_up

module: hme instance: 0

name: hme0 class: net

link_up 1

mssol-ca0-a# kstat qfe:0:qfe0:link*

module: qfe instance: 0

name: qfe0 class: net

link_duplex 2

link_up 1

mssol-ca0-a# kstat qfe:0:qfe0:ifspe*

module: qfe instance: 0

name: qfe0 class: net

ifspeed 100000000

Example 2:

# ndd -set /dev/eri instance 0

# ndd -get /dev/eri link_status

1

# ndd -get /dev/eri link_mode

1

# ndd -get /dev/eri link_speed

1

Step 2 Verify the following settings:

•Duplex should be 1 (full duplex)

•Link_up or link_status should be 1 (operational)

•Link mode should be 1 (no auto negotiation).

Step 3 Verify call agent and switch interfaces are both set to full duplex no auto negotiation.

Step 4 Verify link speed is hard-coded to the same value on both ends.

Step 5 Check for any errors pertaining to the interface in /var/adm/messages* file.

Step 6 Check operational status of ethernet interface(s) on switch side as follows:

admin up / line protocol up

Step 7 Check statistics for ethernet interface(s) on the call agent side while looking for any abnormal queue/input/output errors/collisions. For example, to check stats on bge0 interface:

# netstat -i -I bge0

Ipkts Ierrs Opkts Oerrs Collis Queue

Note The packets queued (Queue) that cannot be transmitted should be 0. If not, it is possible that a cable or ethernet interface is defective.

Note The input errors (Ierrs) and the output errors (Oerrs) should be close to 0. High input errors could indicate that the network is saturated, host overload, or physical network problem. High output errors could indicate a saturated local network or a bad physical connection.

Step 9 Paste the output of "show interfaces" to the Cisco output interpreter for further analysis of the interfaces.

https://www.cisco.com/cgi-bin/Support/OutputInterpreter/home.pl

Step 10 Check the physical cable, the cable connectors, and the cable connections.

Release Cause 25 Exchange Routing Error Received—Call Processing (38)

The Release Cause 25 Exchange Routing Error Received alarm (minor) indicates that a release with cause number 25 occurred because an exchange routing error was received. The primary cause of the alarm is that a REL message with cause number 25 was received. To correct the primary cause of the alarm, log and map the cause. Refer to "Call Authorization Failure—Call Processing (31)" section for additional troubleshooting information.

INVITE Message From Unauthorized Call Agent—Call Processing (41)

The INVITE Message From Unauthorized Call Agent alarm (minor) indicates that a INVITE message was received from an unauthorized CA. The primary cause of the alarm is that the Call-Agent Table is not configured properly. To correct the primary cause of the alarm, reconfigure the Call-Agent table to have the authorized CA listed. The secondary cause of the alarm is that a potential intrusion occurred if the Network-ID mismatch is from the local-network. To correct the secondary cause of the alarm, configure the network to block this unauthorized Network-ID.