Troubleshooting Guide
Chapter 15 - Diagnostic Tests
Downloads: This chapterpdf (PDF - 604.0KB) The complete bookPDF (PDF - 7.16MB) | Feedback

Diagnostic Tests

Table Of Contents

Diagnostic Tests

Introduction

Media Gateway Tests

Subscriber Termination Tests

Signaling System 7 Trunk Termination Tests

Integrated Services Digital Network Trunk Termination Tests

Channel-Associated Signaling Trunk Termination Tests

Announcement Trunk Termination Tests

Troubleshooting Using Snoop

Query Verification Tool and Translation Verification Tool

Tool Requirements

Query Verification Tool

Overview

Command Format

Response Format

Query Errors

Query Verification Tool Measurements

Translation Verification Tool

Overview

Command Format

Response Format

Translation Verification Tool Measurements

Using Query Verification Tool and Translation Verification Tool Together

Network Loopback Test for Network-based Call Signaling/Media Gateway Control Protocol Endpoints

Overview

Restrictions

Installing

Configuring

Configuration Examples

Using/Operating the Network Loopback Test for Network-based Call Signaling/Media Gateway Control Protocol Endpoints

Dedicated Test Trunk Group

Shared Test Trunk Group

Configuring the Originating Trunk Group

Session Initiation Protocol Subscriber Registration Status Check

System Health Report


Diagnostic Tests


Revised: October 23, 2008, OL-11335-06

Introduction

This chapter describes diagnostic tests that can be performed on media gateways, subscriber terminations, and trunk terminations. All media gateways, subscriber and trunk terminations must be in the MAINT state for testing. The following tests are described in this section:

Media Gateway Tests

Subscriber Termination Tests

Signaling System 7 Trunk Termination Tests

Integrated Services Digital Network Trunk Termination Tests

Channel-Associated Signaling Trunk Termination Tests

Announcement Trunk Termination Tests

Troubleshooting Using Snoop

Query Verification Tool and Translation Verification Tool

Network Loopback Test for Network-based Call Signaling/Media Gateway Control Protocol Endpoints

Session Initiation Protocol Subscriber Registration Status Check

System Health Report


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.

Media Gateway Tests

This section describes the tests that can be performed on media gateways. A gateway must be in the MAINT state.


Step 1 Force the media gateway into MAINT state:

control mgw id=c2421.65; mode=forced; target-state=maint;

Reply Example:

Reply : Success: CLI change successful

MGW ID -> c2421.65
INITIAL STATE -> ADMIN_INS
REQUEST STATE -> ADMIN_MAINT
RESULT STATE -> ADMIN_MAINT
FAIL REASON -> ADM found no failure
REASON -> ADM executed successful
RESULT -> ADM configure result in success

Step 2 Display the Test Menu.

diag mgw

Reply Example:

Reply: Diagnostic MGW Menu.
===
(1) MGW Network Connectivity Test
(2) MGW MGCP Connectivity Test
(3) ALL 

Note Test #1 tests if there is a path to the device (ping).
Test #2 tests if Media Gateway Control Protocol (MGCP) has access to the device.
Test #3 performs tests 1 and 2.


Step 3 To perform a specific test, use the following examples as a guide.

diag mgw id=ubr-03; test=1;

Reply Example:

MEDIA GATEWAY LINE DIAGNOSTIC TEST EXECUTED -> diag mgw
ID -> ubr-03
TEST-TYPE -> ADM-MGW-NETW-CONNECTIVITY-TEST
TEST-DURATION -> 0
RESULT -> TEST-SUCCESS
REASON -> PASSED
Reply: Diagnostic command executed.

diag mgw id=ubr-03; test=2;

Reply Example:

MEDIA GATEWAY LINE DIAGNOSTIC TEST EXECUTED -> diag mgw
ID -> ubr-03
TEST-TYPE -> ADM-MGW-MGCP-CONNECTIVITY-TEST
TEST-DURATION -> 0
RESULT -> TEST-SUCCESS
REASON -> PASSED
Reply: Diagnostic command executed. 

diag mgw id=ubr-03; test=3;

Reply Example:

MEDIA GATEWAY LINE DIAGNOSTIC TEST EXECUTED -> diag mgw
ID -> ubr-03
TEST-TYPE -> ADM-MGW-NETW-CONNECTIVITY-TEST
TEST-DURATION -> 11
RESULT -> TEST-SUCCESS
REASON -> PASSED

MEDIA GATEWAY LINE DIAGNOSTIC TEST EXECUTED -> diag mgw
ID -> ubr-03
TEST-TYPE -> ADM-MGW-MGCP-CONNECTIVITY-TEST
TEST-DURATION -> 0
RESULT -> TEST-SUCCESS
REASON -> PASSED
Reply: Diagnostic command executed.

Step 4 Force the media gateway into INS state:

control mgw id=c2421.65; mode=forced; target-state=ins;

Reply Example:

Reply : Success: CLI change successful

MGW ID -> c2421.65
INITIAL STATE -> ADMIN_MAINT
REQUEST STATE -> ADMIN_INS
RESULT STATE -> ADMIN_INS
FAIL REASON -> ADM found no failure
REASON -> ADM executed successful
RESULT -> ADM configure result in success

Subscriber Termination Tests

This section describes the tests that can be performed on subscriber terminations. All terminations must be in the MAINT state.


Step 1 Force the subscriber termination into MAINT state:

control subscriber-termination id=sub2-ctx2; mode=forced; target-state=maint;

Step 2 Display the Test Menu.

diag subscriber-termination;

Reply Example:

Reply: Diagnostic Subscriber Menu.
===
(1) Subscriber MGCP Connectivity Test
(2) Subscriber Termination Connection Test
(3) Subscriber Termination Ring Test
(4) ALL

Note Test #1 tests if MGCP has access to the termination.
Test #2 tests if there is a path to the device (ping).
Test #3 tests if the subscriber can be rung. The Ring parameter must be specified in seconds for this test. The default is 5 seconds.
Test #4 performs tests 1 through 3.


Step 3 To perform a specific test, use the following examples as a guide.

diag subscriber-termination id=sub2-ctx2; test=1;

Reply Example:

SUBSCRIBER LINE DIAGNOSTIC TEST EXECUTED -> diag subscriber-termination
ID -> sub2-ctx2
TEST-TYPE -> ADM-MGW-MGCP-CONNECTIVITY-TEST
TEST-DURATION -> 10
RESULT -> TEST-SUCCESS
REASON -> PASSED: Reason: AUEP-NACK received with RespCode = 510
Reply: Diagnostic command executed.

diag subscriber-termination id=sub-ubr3-1@cisco.com; test=2;

Reply Example:

SUBSCRIBER LINE DIAGNOSTIC TEST EXECUTED -> diag subscriber-termination
ID -> sub-ubr3-1@Cisco.com
TEST-TYPE -> ADM-TERM-CONNECTION-TEST
TEST-DURATION -> 55
RESULT -> TEST-SUCCESS
REASON -> PASS successfully.
Reply: Diagnostic command executed.
diag subscriber-termination id=sub-ubr3-1@cisco.com; test=3; ring-duration=10;

Reply Example:

SUBSCRIBER LINE DIAGNOSTIC TEST EXECUTED -> diag subscriber-termination
ID -> sub-ubr3-1@Cisco.com
TEST-TYPE -> ADM-TERM-RING-TEST
TEST-DURATION -> 9989
RESULT -> TEST-SUCCESS
REASON -> PASSED
Reply: Diagnostic command executed. 

Step 4 Force the subscriber termination into INS state:

control subscriber-termination id=sub2-ctx2; mode=forced; target-state=ins;

Note Ring-duration values are 0-999 (Default = 5). Maximum ring time is 30 seconds regardless of whether the duration is set higher than or equal to 31.



Signaling System 7 Trunk Termination Tests

This section describes the tests that can be performed on Signaling System 7 (SS7) trunk terminations. All terminations must be in the MAINT state for testing.


Step 1 Force the SS7 trunk termination into MAINT state:

control ss7-trunk-termination tgn-id=103; mode=forced; target-state=maint;

Note Set customer-originated trace (COT), circuit verification message (CVM), and circuit query message (CQM) on the terminating gateway or switch to perform these tests. Otherwise, the test or tests will fail.


Step 2 Display the Test Menu.

diag ss7-trunk-termination

Reply Example:

Reply: Diagnostic SS7 Trunk Group Menu.
===
Test=1: SS7 MGCP Connectivity
Test=2: SS7 Termination Connection Test
Test=3: COT
Test=4: CQM
Test=5: CVT
Test=6: CIC
Test=7: All


Note Test #1 tests if MGCP has access to the SS7 trunk termination.
Test #2 tests if there is a path to the device (ping).
Test #3 tests the integrity of the SS7 Bearer Path.
Test #4 queries the SS7 circuit (or group of circuits) status. A range of CICs can be specified (to a maximum of 24). Both remote and local trunk states are displayed in the results.
Test #5 tests to ensure that each end of the circuit has sufficient and consistent information for using the circuit in call connections. Common language location identifier (CLLI) names are included.
Test #6 tests to ensure the CIC connections.
Test #7 performs tests 1 through 6.


Step 3 To perform a specific test, use the following examples as a guide:

diag ss7-trunk-termination tgn-id=103; cic=13; test=1;

Reply Example:

TRUNK DIAGNOSTIC TEST EXECUTED -> diag trunk
TG-NUM -> 103
CIC -> 13
TEST-TYPE -> ADM-MGW-MGCP-CONNECTIVITY-TEST
TEST-DURATION -> 0
RESULT -> TEST-SUCCESS
REASON -> PASSED: Reason: AUEP-NACK received with RespCode = 510
Reply: Diagnostic command executed.

diag ss7-trunk-termination tgn-id=103; cic=13; test=2;

Reply Example:

TRUNK DIAGNOSTIC TEST EXECUTED -> diag trunk
TG-NUM -> 103
CIC -> 13
TEST-TYPE -> ADM-TERM-CONNECTION-TEST
TEST-DURATION -> 33
RESULT -> TEST-SUCCESS
REASON -> PASS successfully.
Reply: Diagnostic command executed.

diag ss7-trunk-termination tgn-id=103; cic=14; test=3;

Reply Example:

TRUNK DIAGNOSTIC TEST EXECUTED -> diag trunk
TG-NUM -> 103
CIC -> 14
TEST-TYPE -> ADM-SS7-COT-TEST
TEST-DURATION -> 0
RESULT -> TEST-FAILURE
REASON -> ADM-MAINT-STATE-REQUIRED
Reply: Diagnostic command executed.

diag ss7-trunk-termination tgn-id=2;cic=1-24;test=4

Reply Example:

Reply : Success: 

TGN ID -> 2
START CIC -> 1
END CIC -> 24
TEST TYPE -> ADM running SS7 circuit query message test
TEST DURATION -> 0
RESULT -> ADM ran test successfully
REASON -> CQM test pass
CIC COUNT -> 24
CIC STATES -> 


Remote State
Local State

CIC 1 -> CS_IDLE
ACTV
IDLE

CIC 2 -> CS_IDLE
ACTV
IDLE

CIC 3 -> CS_IDLE
ACTV
IDLE

CIC 4 -> CS_IDLE
ACTV
IDLE

CIC 5 -> CS_IDLE
ACTV
IDLE

CIC 6 -> CS_IDLE
ACTV
IDLE

CIC 7 -> CS_IDLE
ACTV
IDLE

CIC 8 -> CS_IDLE
ACTV
IDLE

CIC 9 -> CS_IDLE
ACTV
IDLE

CIC 10 -> CS_IDLE
ACTV
IDLE

CIC 11 -> CS_IDLE
ACTV
IDLE

CIC 12 -> CS_IDLE
ACTV
IDLE

CIC 13 -> CS_IDLE
ACTV
IDLE

CIC 14 -> CS_IDLE
ACTV
IDLE

CIC 15 -> CS_IDLE
ACTV
IDLE

CIC 16 -> CS_IDLE
ACTV
IDLE

CIC 17 -> CS_IDLE
ACTV
IDLE

CIC 18 -> CS_IDLE
ACTV
IDLE

CIC 19 -> CS_IDLE
ACTV
IDLE

CIC 20 -> CS_IDLE
ACTV
IDLE

CIC 21 -> CS_IDLE
ACTV
IDLE

CIC 22 -> CS_IDLE
ACTV
IDLE

CIC 23 -> CS_IDLE
ACTV
IDLE

CIC 24 -> CS_IDLE 
ACTV 
IDLE



Note Table 15-1 lists the responses that can be returned for the CQM test:


diag ss7-trunk-termination tgn-id=2;cic=1;test=5

Reply Example:

Reply : Success: 

TGN ID -> 2
START CIC -> 1
END CIC -> 1
TEST TYPE -> ADM running SS7 circuit validation test 
TEST DURATION -> 0
RESULT -> ADM ran test successfully
REASON -> CVT test pass
CLLI -> DALLTXRCDN5

Step 4 Force the SS7 trunk termination into INS state:

control ss7-trunk-termination tgn-id=103; mode=forced; target-state=ins;

Table 15-1 CQM Responses 

Response
Description

CS_TRANSIENT

Transient

CS_UNEQUIPPED

Unequipped

CS_IC_BUSY

Incoming Busy

CS_IC_BUSY_LOCBLOC

Incoming Busy and Locally Maintenance Blocked

CS_IC_BUSY_REMBLOC

Incoming Busy and Remotely Maintenance Blocked

CS_IC_BUSY_BOTH_BLOC

Incoming Busy and Remotely and Locally Maintenance Blocked

CS_OG_BUSY

Outgoing Busy

CS_OG_BUSY_LOCBLOC

Outgoing Busy and Locally Maintenance Blocked

CS_OG_BUSY_REMBLOC

Outgoing Busy and Remotely Maintenance Blocked

CS_OG_BUSY_BOTH_BLOC

Outgoing Busy and Remotely and Locally Maintenance Blocked

CS_IDLE

Idle

CS_IDLE_LOCBLOC

Idle and Locally Maintenance Blocked

CS_IDLE_REMBLOC

Idle and remotely maintenance blocked

CS_IDLE_BOTH_BLOC

Idle and Remotely and Locally Maintenance Blocked

CS_HW_LOCBLOC

Locally Hardware Blocked

CS_HW_LOCBLOC_LOCBLOC

Locally Hardware and Locally Maintenance Blocked

CS_HW_LOCBLOC_REMBLOC

Locally Hardware and Remotely Maintenance Blocked

CS_HW_LOCBLOC_BOTHBLOC

Locally Hardware and Remotely and Locally Maintenance Blocked

CS_HW_REMBLOC

Remotely Hardware Blocked

CS_HW_REMBLOC_LOCBLOC

Remotely Hardware and Locally Maintenance Blocked

CS_HW_REMBLOC_REMBLOC

Remotely Hardware and Remotely Maintenance Blocked

CS_HW_REMBLOC_BOTHBLOC

Remotely Hardware and Remotely and Locally Maintenance Blocked

CS_HW_BOTHBLOC

Remotely and Locally Hardware Blocked

CS_HW_BOTHBLOC_LOCBLOC

Remotely and Locally Hardware and Locally Maintenance Blocked

CS_HW_BOTHBLOC_REMBLOC

Remotely and Locally Hardware and Remotely Maintenance Blocked

CS_HW_BOTHBLOC_BOTHBLOC

Remotely and Locally Hardware and Remotely and Locally Maintenance Blocked



Integrated Services Digital Network Trunk Termination Tests

This section describes the tests that can be performed on Integrated Services Digital Network (ISDN) trunk terminations. All terminations must be in the MAINT state for testing.


Step 1 Force the ISDN trunk termination into MAINT state:

control isdn-trunk-termination tgn-id=17; mode=forced; target-state=maint;

Step 2 Display the Test Menu.

diag isdn-trunk-termination

Reply Example:

Reply: Diagnostic ISDN Trunk Group Menu.
=== 
(1) ISDN MGCP Connectivity Test
(2) ISDN Termination Connection Test
(3) ALL

Note Test #1 tests if MGCP has access to the ISDN termination.
Test #2 tests if there is a path to the device (ping).
Test #3 performs tests 1 and 2.


Step 3 To perform a specific test, use the following examples as a guide.

diag isdn-trunk-termination test=1; tgn-id=17; cic=1;

Reply Example:

TRUNK DIAGNOSTIC TEST EXECUTED -> diag trunk
TG-NUM -> 17
CIC -> 1
TEST-TYPE -> ADM-MGW-MGCP-CONNECTIVITY-TEST
TEST-DURATION -> 0
RESULT -> TEST-SUCCESS
REASON -> PASSED: Reason: AUEP-NACK received with RespCode = 510
Reply: Diagnostic command executed.

diag isdn-trunk-termination test=2; tgn-id=17; cic=1;

Reply Example:

TRUNK DIAGNOSTIC TEST EXECUTED -> diag trunk
TG-NUM -> 17
CIC -> 1
TEST-TYPE -> ADM-TERM-CONNECTION-TEST
TEST-DURATION -> 0
RESULT -> TEST-SUCCESS
REASON -> PASSED: Reason: AUEP-NACK received with RespCode = 510
Reply: Diagnostic command executed.

Step 4 Force the ISDN trunk termination into MAINT state:

control isdn-trunk-termination tgn-id=17; mode=forced; target-state=maint;

Channel-Associated Signaling Trunk Termination Tests

This section describes the tests that can be performed on channel-associated signaling (CAS) trunk terminations. All terminations must be in the MAINT state for testing.


Step 1 Force the CAS trunk termination into MAINT state:

control cas-trunk-termination tgn-id=64; mode=forced; target-state=maint;

Step 2 Display the Test Menu.

diag cas-trunk-termination

Reply Example:

Reply: Diagnostic CAS Trunk Group Menu.
===
(1) CAS MGCP Connectivity Test
(2) CAS Termination Connection Test
(3) ALL

Note Test #1 tests if MGCP has access to the CAS termination.
Test #2 tests if there is a path to the device (ping).
Test #3 performs tests 1 and 2.


Step 3 To perform a specific test, use the following examples as a guide:

diag cas-trunk-termination tgn-id=64;cic=1;test=1;

Reply Example:

TRUNK DIAGNOSTIC TEST EXECUTED -> diag trunk
TG-NUM -> 64
CIC -> 1
TEST-TYPE -> ADM-MGW-MGCP-CONNECTIVITY-TEST
TEST-DURATION -> 0
RESULT -> TEST-SUCCESS
REASON -> PASSED: Reason: AUEP-NACK received with RespCode = 510
Reply: Diagnostic command executed.

diag cas-trunk-termination tgn-id=64;cic=1;test=2;

Reply Example:

TRUNK DIAGNOSTIC TEST EXECUTED -> diag trunk
TG-NUM -> 64
CIC -> 1
TEST-TYPE -> ADM-TERM-CONNECTION-TEST
TEST-DURATION -> 32
RESULT -> TEST-SUCCESS
REASON -> PASS successfully.
Reply: Diagnostic command executed.

diag cas-trunk-termination tgn-id=64;cic=1;test=3;

Reply Example:

TRUNK DIAGNOSTIC TEST EXECUTED -> diag trunk
TG-NUM -> 64
CIC -> 1
TEST-TYPE -> ADM-MGW-MGCP-CONNECTIVITY-TEST
TEST-DURATION -> 11
RESULT -> TEST-SUCCESS
REASON -> PASSED: Reason: AUEP-NACK received with RespCode = 510

TRUNK DIAGNOSTIC TEST EXECUTED -> diag trunk
TG-NUM -> 64
CIC -> 1
TEST-TYPE -> ADM-TERM-CONNECTION-TEST
TEST-DURATION -> 32
RESULT -> TEST-SUCCESS
REASON -> PASS successfully.
Reply: Diagnostic command executed.

Step 4 Force the CAS trunk termination into INS state:

control cas-trunk-termination tgn-id=64; mode=forced; target-state=ins;

Announcement Trunk Termination Tests

This section describes the tests that can be performed on Announcement trunk terminations. All terminations must be in the MAINT state for testing.


Step 1 Force the Announcement trunk termination into MAINT state:

control annc-trunk-termination tgn-id=13; mode=forced; target-state=maint;

Step 2 Display the Test Menu.

diag annc-trunk-termination:

Reply Example:

Reply: Diagnostic ANC Trunk Group Menu.
===
(1) ANC MGCP Connectivity Test
(2) ANC Termination Connection Test
(3) ALL


Note Test #1 tests if MGCP has access to the announcements module (ANC) termination.
Test #2, tests if there is a path to the device (ping).
Test #3 performs tests 1 and 2.


Step 3 To perform a specific test, use the following examples as a guide.

diag annc-trunk-termination;test=1;tgn-id=13;cic=1

Reply Example:

TRUNK DIAGNOSTIC TEST EXECUTED -> diag trunk
TG-NUM -> 13
CIC -> 1
TEST-TYPE -> ADM-MGW-MGCP-CONNECTIVITY-TEST
TEST-DURATION -> 0
RESULT -> TEST-SUCCESS
REASON -> PASSED: Reason: AUEP-NACK received with RespCode = 510
Reply: Diagnostic command executed.

diag annc-trunk-termination;test=2;tgn-id=13;cic=1

Reply Example:

TRUNK DIAGNOSTIC TEST EXECUTED -> diag trunk
TG-NUM -> 13
CIC -> 1
TEST-TYPE -> ADM-TERM-CONNECTION-TEST
TEST-DURATION -> 33
RESULT -> TEST-SUCCESS
REASON -> PASS successfully.
Reply: Diagnostic command executed.

diag annc-trunk-termination;test=3;tgn-id=13;cic=1

Reply Example:

TRUNK DIAGNOSTIC TEST EXECUTED -> diag trunk
TG-NUM -> 13
CIC -> 1
TEST-TYPE -> ADM-MGW-MGCP-CONNECTIVITY-TEST
TEST-DURATION -> 11
RESULT -> TEST-SUCCESS
REASON -> PASSED: Reason: AUEP-NACK received with RespCode = 510

TRUNK DIAGNOSTIC TEST EXECUTED -> diag trunk
TG-NUM -> 13
CIC -> 1
TEST-TYPE -> ADM-TERM-CONNECTION-TEST
TEST-DURATION -> 33
RESULT -> TEST-SUCCESS
REASON -> PASS successfully.
Reply: Diagnostic command executed.

Step 4 Force the Announcement trunk termination into INS state:

control annc-trunk-termination tgn-id=13; mode=forced; target-state=ins;

Troubleshooting Using Snoop


Caution Snoop should NOT be used on the Cisco BTS 10200 Softswitch call agent itself in a Production Network. It can cause performance degradation.

Snoop can be used on the Cisco BTS 10200 Softswitch call agent during test and turn-up phase during very low call volume periods. Snoop can always be used on a separate UNIX machine connected to a switch that has been properly setup for port span/mirroring. You must be logged in as "root" user to run snoop. Snoop can be used to decode text protocols or can be saved to a file and opened with Ethereal when binary protocols are used. Ethereal is open source software and can be downloaded from http://www.ethereal.com. To use Snoop to diagnose network problems, take the following steps:


Step 1 Find all routes to the destination in question. Most likely there will be multiple routes therefore multiple interfaces will need to be snooped. (Skip this step if you are snooping from a separate Unix machine - you will just snoop the span destination interface in that case.) In this example, destination Internet Protocol (IP) 10.0.0.1 is in question. The fully qualified domain name (FQDN) can be used if it is resolvable by domain name system (DNS). Issue the command several times as there may be redundant routes.

mssol-ca0-a# route get 10.0.0.1
   route to: 10.0.0.1
destination: default
       mask: default
    gateway: 10.0.0.253
  interface: qfe4
      flags: <UP,GATEWAY,DONE>
 recvpipe  sendpipe  ssthresh    rtt,ms rttvar,ms  hopcount      mtu     expire
       0         0         0         0         0         0      1500         0 
mssol-ca0-a# route get 10.0.0.1
   route to: 10.0.0.1
destination: default
       mask: default
    gateway: 10.0.0.253
  interface: qfe4
      flags: <UP,GATEWAY,DONE>
 recvpipe  sendpipe  ssthresh    rtt,ms rttvar,ms  hopcount      mtu     expire
       0         0         0         0         0         0      1500         0 
mssol-ca0-a# route get 10.0.0.1
   route to: 10.0.0.1
destination: default
       mask: default
    gateway: 10.20.0.253
  interface: qfe0
      flags: <UP,GATEWAY,DONE>
 recvpipe  sendpipe  ssthresh    rtt,ms rttvar,ms  hopcount      mtu     expire
       0         0         0         0         0         0      1500         0 
mssol-ca0-a# route get 10.0.0.1
   route to: 10.0.0.1
destination: default
       mask: default
    gateway: 10.20.0.253
  interface: qfe0
      flags: <UP,GATEWAY,DONE>
 recvpipe  sendpipe  ssthresh    rtt,ms rttvar,ms  hopcount      mtu     expire
       0         0         0         0         0         0      1500         0 


Note Each interface reported above must be snooped to catch all packets across redundant routes. In the given example interface qfe0 as well as qfe4 must be snooped.


Step 2 Issue the snoop command. It may differ in syntax depending on protocol(s) that are being analyzed.

Session Initiation Protocol (SIP) example:

10.0.0.1 is a SIP Phone. The goal is to monitor the SIP traffic between the Cisco BTS 10200 Softswitch and the SIP phone.

# snoop -d qfe0 -x 42 host 10.0.0.1 and port 5060 and udp &
# snoop -d qfe4 -x 42 host 10.0.0.1 and port 5060 and udp &

MGCP/network-based call signaling (NCS) example:

10.0.0.1 is an integrated access device (IAD) running MGCP. The goal is to monitor MGCP traffic between the Cisco BTS 10200 Softswitch and the IAD.

# snoop -d qfe0 -x 42 host 10.0.0.1 and port 2427 and udp &
# snoop -d qfe4 -x 42 host 10.0.0.1 and port 2427 and udp &

Stream Control Transmission Protocol (SCTP)/MTP3 user adaptation (M3UA)/ISDN user part (ISUP) example:

Since these protocols are not TEXT based as the ones mentioned above, use the -o option with snoop to capture packets in an Ethereal readable format. Ethereal can decode SCTP/M3UA/ISUP or SCTP/SCCP user adapter (SUA)/Transaction Capabilities Application Part (TCAP). 10.0.0.1 is a Signaling Gateway acting as an M3UA peer with the Cisco BTS 10200 Softswitch.

# snoop -d qfe0 -o sctp.cap host 10.0.0.1  (this will capture all traffic)

Step 3 Use Control-C to stop the packet capture. Open the file in Ethereal and inspect. To capture sctp packets that contain M3UA information:

a. First, find the port M3UA will use to communicate with the signaling gateway (SG).

CLI>show sctp-assoc platform-id=CA146

ID=sgp1-itpa
SGP_ID=sgp1
SCTP_ASSOC_PROFILE_ID=sctp-prof1
REMOTE_PORT=2905  <-------------------this port
REMOTE_TSAP_ADDR1=10.0.0.1
PLATFORM_ID=CA146
DSCP=NONE
IP_TOS_PRECEDENCE=CRITICAL
LOCAL_RCVWIN=3000
MAX_INIT_RETRANS=3
MAX_INIT_RTO=500
STATUS=INS
ULP=XUA

# snoop -d qfe0 -o m3ua.cap host 10.0.0.1 and port 2905

b. Use Control-C to stop the packet capture. Open the file in Ethereal and inspect.

SCTP/SUA/TCAP example 1:

10.0.0.1 is a Signaling Gateway acting as an SUA peer with the Cisco BTS 10200 Softswitch. The goal is to capture all 800/local number portability (LNP) queries.

a. Follow the same syntax as for the M3UA case, except find which port SUA communicates with the SG for Advanced Intelligent Network (AIN) features:

CLI>show sctp-assoc platform-id=FSAIN205

ID=sctp-ain-itpa
SGP_ID=sgp1
SCTP_ASSOC_PROFILE_ID=sctp-prof1
REMOTE_PORT=2907  <-------------------this port
REMOTE_TSAP_ADDR1=10.0.0.1
PLATFORM_ID=FSAIN205
DSCP=NONE
IP_TOS_PRECEDENCE=CRITICAL
LOCAL_RCVWIN=3000
MAX_INIT_RETRANS=3
MAX_INIT_RTO=500
STATUS=INS
ULP=XUA

# snoop -d qfe0 -o suaain.cap host 10.0.0.1 and port 2907

b. Use Control-C to stop the packet capture. Open the file in Ethereal and inspect.

SCTP/SUA/TCAP example 2:

10.0.0.1 is a Signaling Gateway acting as an SUA peer with the Cisco BTS 10200 Softswitch. The goal is to capture all offnet automatic callback and automatic rollback (ACAR) queries.

a. Follow the same syntax as for the M3UA case, except find the port SUA communicates with the SG for plain old telephone service (POTS) features:

CLI>show sctp-assoc platform-id=FSPTC235

ID=sctp-ptc-itpa
SGP_ID=sgp2
SCTP_ASSOC_PROFILE_ID=sctp-prof1
REMOTE_PORT=2906  <------------------this port
REMOTE_TSAP_ADDR1=10.0.0.1
PLATFORM_ID=FSPTC235
DSCP=NONE
IP_TOS_PRECEDENCE=FLASH
LOCAL_RCVWIN=64000
MAX_INIT_RETRANS=5
MAX_INIT_RTO=1000
STATUS=INS
ULP=XUA

# snoop -d qfe0 -o suapots.cap host 10.0.0.1 and port 2906

b. Use Control-C to stop the packet capture. Open the file in Ethereal and inspect.

H.323 Protocol (H323) example:

10.0.0.1 is an H323 gateway. 10.0.0.129 is an H323 gatekeeper. Our goal is to monitor both Registration, Admissions, and Status (RAS) and H.225 messaging.

a. First, find the RAS port number and the H.225 port number.

CLI>show h323-gw

ID=ccm3_gw1
STATUS=INS
OPER_STATUS=NF
GW_H225_PORT=1720  <----------- this port
TGN_ID=4441
SECURITY=N
H245_TUNNELING=DEFAULT
TCP_MAX_LIMIT=5
TCP_MAX_AGE=30
MAX_VOIP_CALLS=65535
HIGH_WATER_MARK=0
LOW_WATER_MARK=0
IRR_BANDWIDTH_SUPP=N
IPTOS_SIG_LOWDELAY=Y
IPTOS_SIG_THROUGHPUT=N
IPTOS_SIG_RELIABILITY=N
IPTOS_SIG_PRECEDENCE=FLASH
BRQ_SUPP=Y
ANNEXE_RETRANSMIT_TIMER=500
ANNEXE_RETRANSMIT_MULTIPLIER=2
ANNEXE_RETRANSMIT_ATTEMPTS=8
CALL_START_MODE=FAST_START
ANNEXE_SUPP=N
ANNEXR_SUPP=N
STATUS_ENQ_TIMER=4
CODEC_NEG_TIMER=200
CODEC_NEG_ATTEMPTS=4
SOURCE_BASED_ROUTING=NONE 

CLI>show h323-gw2gk

H323_GW_ID=ccm3_gw1
GK_ID=Metro-GK
PRIORITY=0
GK_IP_ADDR=10.0.0.129
GK_RAS_PORT=1719  <------------ this port
MULTICAST=N
TIME_TO_LIVE=60

# snoop -d qfe0 -o h323.cap host 10.0.0.1 and port 1720 or host 10.0.0.129 and port 
1719

b. Use Control-C to stop the packet capture. Open the file in Ethereal and inspect.

COPs example:

10.0.0.1 is a cable modem termination system (CMTS) and is configured as an aggregation identification (AGGR-ID) in the Cisco BTS 10200 Softswitch. The goal is to monitor all Common Open Policy Service Protocol (COPS) messaging to and from the CMTS.

a. Issue the following command:

# snoop -d qfe0 -o cops.cap host 10.0.0.1 and port 2126 and tcp

b. Use Control-C to stop the packet capture. Open the file in Ethereal and inspect.

Step 4 Packets can be redirected to a file (not readable by Ethereal) at follows:

# snoop -d qfe0 -x 42 host 10.0.0.1 and port 2427 and udp > mycapt.cap

Step 5 Stop the snoop processes.

# pkill snoop
# pgrep snoop (should not report any process ids)

Query Verification Tool and Translation Verification Tool

This section describes the Query Verification Tool (QVT) and the Translation Verification Tool (TVT) and is organized into the following sub-sections:

Tool Requirements

Query Verification Tool

Translation Verification Tool

Using Query Verification Tool and Translation Verification Tool Together

Tool Requirements

The following requirements are supported in the QVT and TVT:

TVT—Provide a tool to find, diagnose, and trace call flow path decisions.

Query Local Routing Number (QLRN) Tool—Provide the ability to enter a ten digit directory number and launch a query to the service control point (SCP) as though it was a called number from the signal switching point (SSP).

Query Tool E800VER Command—Send a database query to the SCP as if it was an 800 called number from the SSP without initiating a call.

Query Tool CNAMDVER and TESTSS CNAMD Commands—Provide the ability to query the SCP database for the calling name delivery (CNAM) display and privacy status associated with the name without initiating a call.

Query Verification Tool

This section describes the QVT and includes the following sections:

Overview

Command Format

Response Format

Query Errors

Query Verification Tool Measurements

Overview

The QVT enables a user to generate TCAP queries to external databases through the command line interface (CLI) interface. The types of queries supported are:

Line information database (LIDB)—Generated by the POTS Feature Server

Toll-Free—Generated by the AIN Feature Server

LNP—Generated by the AIN Feature Server

Command Format

The QVT command uses the following format:

query <lidb|toll-free|lnp> parameter=value;

Examples

query lidb calling-dn=8002550002; opc-id=opc;

Syntax Description

* OPC-Id

Origination Point Code ID

* Calling-DN

The caller's directory number.

Table-Info

Specifies whether or not you want to see the tables accessed when processing the query. Y/N; default=N


Examples

query toll-free

Syntax Description

* OPC-Id

Origination Point Code ID

* Calling-DN

The caller's directory number.

* User-Type

Specifies whether the User-ID is a Trunk-Group-ID or the Calling-DN. Mandatory for AIN0.1 queries; not used in intelligent network (IN)/1 queries.

* User-ID

Specifies either the Trunk-Group-ID or Calling-DN, depending upon what you have specified in User-Type. Mandatory for AIN0.1 queries; not used in IN/1 queries.

* Called-DN

 

* LATA

Local access and transport area. VARCHAR (5)

Originating Line Information (OLI)

Optional parameter used if the message-type is IN/1. 0 (default) = POTS.

Bearer-Capability

Valid values are: Speech, f31KhzAudio, b56kbps, or b64kbps.

Trigger-Criteria

Valid values are: 3, 6, 7, 8, 9, or 10.

Table-Info

Specifies whether or not you want to see the tables accessed when processing the query. Y/N; default=N


Examples

query lnp;

Syntax Description

* OPC-Id

Origination Point Code ID

* Calling-DN

The caller's directory number. VARCHAR(10): 10 digits in the format npaxxxxxxx.

* User-Type

Specifies whether the User-ID is a Trunk-Group-ID or the Calling-DN.

* User-ID

Specifies either the Trunk-Group-ID or Calling-DN, depending upon what you have specified in User-Type. Values are POTS DN NPA-NXX-XXXX (Calling-DN) or numeric number nomenclature (NNN) (Trunk-Group-ID).

* Called-DN

 

* LATA

Local access and transport area. VARCHAR (5)

Bearer-Capability

Valid values are: Speech, f31KhzAudio, b56kbps, or b64kbps.

Trigger-Criteria

 

Table-Info

Specifies whether or not you want to see the tables accessed when processing the query. Y/N; default=N


Response Format

The system response to a query is in the following format:

Reply: <success|failure>; parameter=value;

Common Response Parameters

Successful response parameters include the following:

OPC—Originating Point Code

SSN—Subsystem Number

TT—translation type

SCP-Point-Code—Point Code of the SCP

Automatic call gapping (ACG) component received

ACG-Control-Code-Length

Generic address parameter (GAP) - duration

GAP-Interval

Announcement-Cause-Code

An error message will be displayed if the query is not successful. For more information about error messages and problem resolution, refer to the "Query Errors" section on page 4.

Query Line Information Database Response Parameters

Additional parameters returned in response to a query lidb command include:

Calling-DN

Caller-ID Name String

Caller-ID Name Privacy

Query Toll-Free Parameters

The following additional parameters are returned in response to a query toll-free command:

Message-Type

Original Number

Translated Number

Carrier

Send-Notification-Received

Query Local Number Portability Parameters

The following additional parameters are returned in response to a query LNP command:

Original Number

Translated Number

Query Errors

An error can occur when a query command fails. This section specifies error responses and possible resolutions for problems.

Request Timeout

A query is sent to the feature server, but no response is received. The error response is similar to the following example:

CLI> query lidb; calling-dn=123247238723; opc-id=opc;
QUERY ON FEATURE SERVER FSPTC235 IS ...->
FSPTC235 -> No Reply received!
Reply : Failure:
CLI>

The Feature Server did not respond to the query before a timeout occurred. Take the following steps to resolve the problem:

If it was an LIDB query, execute the nodestat command on the POTS Feature Server to confirm that it is Active.

If it was a Toll-Free or LNP query, execute the nodestat command on the AIN Feature Server to confirm that it is Active.

If the platform is Active, execute the following command to confirm that the selective call acceptance (SCA) process is running:

ps -aef | grep sca

If the process is not running, start it through process debug manager (PDM) or by stopping and restarting the platform.

If the platform is Active, execute the following command to confirm that the TCAP signaling adapter (TSA) process is running:

ps -aef | grep tsa

If the process is not running, start it through PDM or by stopping and restarting the platform.

If the SCA and TSA processes are running on the Active platform, check the trace files for errors associated with the query.

Service Control Point Timeout

The SCP does not respond to a query. The error response is similar to the following example:

CLI> query lidb; calling-dn=1232472387283; opc-id=opc;
QUERY ON FEATURE SERVER FSPTC235 IS...->
RESULT ->
QVT query has timed out
QUERYSTATUS -> Miscellaneous Failure
Reply : Success:
CLI>

There is no response from the SCP. Contact the SCP provider to find out why there is no error response returned from the SCP.

Missing Mandatory Parameter

The user performs a query but does not provide all required parameters. The error response is similar to the following example:

CLI> query toll-free; called-dn=8002550002; user-type=calling-dn; user-id=2182640018; 
lata=100; bearer-capability=speech; trigger-criteria=9;
Required attributes missing:
opc_id
CLI>

Supply all required parameters for the query. To view a list of parameters required for a command, enter a question mark (?) after the partial command. For example, query lidb? will display a list of required parameters for a LIDB query.

Advanced Intelligent Network 0.1 Query Attempted for IN/1 Configuration

An AIN0.1 Toll-Free query has been performed, but the system specifies that the Toll-Free subsystem is IN/1. The error response is similar to the following example:

CLI> query toll-free; called-dn=8002550002; user-type=calling-dn; user-id=2182640018; 
lata=100; bearer-capability=speech; trigger-criteria=9, opc-id=opc;
Reply : Failure: Missing CALLING_DN for the IN/1 query
CLI>

Reissue the command in the IN/1 format. To see what message type is specified for the Toll-Free subsystem, enter the following command:

CLI> query toll-free-msg-type; opc-id=opc;
MESSAGE-TYPE=IN1
Reply : Success:

IN/1 Query Attempted for Advanced Intelligent Network 0.1 Configuration

An IN/1 Toll-Free query has been performed, but the system specifies that the Toll-Free subsystem is AIN 0.1. The error response is similar to the following example:

CLI> query toll-free; called-dn=8002550002; calling-dn=2182640018; lata=100; 
trigger-criteria=9; opc-id=opc;
Reply : Failure: Missing USER_TYPE for the AIN 0.1 query
CLI>

Reissue the command in the AIN 0.1 format. To see what message type is specified for the Toll-Free subs system, enter the following command:

CLI> query toll-free-msg-type; opc-id=opc;
MESSAGE-TYPE=AIN01
Reply : Success:
CLI>

Parameter Boundary Error

The query can fail if you enter invalid data for a specific parameter. In the following example, a value outside the boundary of expected values for the trigger-criteria parameter has been specified.

CLI> query toll-free; called-dn=8002550002; calling-dn=2182640018; lata=100; 
trigger-criteria=12; opc-id=opc;
Invalid parameter value.
trigger_criteria=12; Enter one of the following values: [3,6,7,8,9,10].
CLI>

To resolve this error, enter a valid value for the specified parameter.

Record Does Not Exist

In the following example, a value has been entered for a lata that has not been provisioned:

CLI> query toll-free; called-dn=8002550002; calling-dn=2182640018; lata=101; 
trigger-criteria=9; opc-id=opc;
Reply : Failure: LATA 101 does not exist
CLI>

To resolve this error, enter a provisioned local access and transport area (LATA).

Local Network Failure

When communication is lost between the Cisco BTS 10200 Softswitch and the IP transfer point (ITP) gateway, a local network failure may occur. The most likely reason for this error is that the SCTP association is Out Of Service. The error response is similar to the following example:

CLI> query toll-free; called-dn=8002550002; calling-dn=2182640018; lata=100; 
trigger-criteria=9; opc-id=opc;
QUERY ON FEATURE SERVER FSAIN205 IS...->
RESULT->
MTP failure - occurs at SP (PC7-44-1, SSN=254)
QUERYSTATUS -> Network Failure
Reply : Success:
CLI>

Perform the following to diagnose the problem:

Execute the query again with the table-info option set to yes

Determine the status of the SCTP associations used for this command. If the associations are Out Of Service, control the associations back into service.

Remote Network Failure

A failure has occurred at a point code other than the OPC. The query response will specify what problem has occurred and at which point code the problem is detected. In the following example, the point code of the signal transfer point (STP) is reporting a failure because there is no Global Title Translation entry in the STP global text telephony (GTT) database for the calling-dn.

CLI> query lidb; calling-dn=9823456789; opc-id=opc;
QUERY ON FEATURE SERVER FSPTC235 IS...->
RESULT ->
No translation for this specific address - occurs at SP (PC=1-101-0, SSN=0)
QUERYSTATUS -> Network Failure
Reply : Success:
CLI> status sctp-assoc;

To resolve this error, add an entry to the STP GTT database to translate the calling-dn and route the query request to the LIDB subsystem on the SCP.

Query Verification Tool Measurements

Table 15-2 identifies the measurements generated by the AIN Feature Server for the QVT feature.

Table 15-2 QVT AIN Tools Counters

Counter Label
Counter Description

TOOLS_LNP_QUERY_ATTMP

The total number of times the reporting feature server received a request to perform an LNP query from the QVT tool.

TOOLS_LNP_QUERY_SUCC

The total number of times the reporting feature server received a request to perform an LNP query from the QVT tool and completed it successfully.

TOOLS_TOLLFREE_QUERY_ATTMP

The total number of times the reporting feature server received a request to perform a Toll Free query from the QVT tool.

TOOLS_TOLLFREE_QUERY_SUCC

The total number of times the reporting feature server received a request to perform a Toll Free query from the QVT tool and completed it successfully.


Table 15-3 identifies the measurements generated by the POTS Feature Server for the QVT feature.

Table 15-3 QVT POTS Tools Counters

Counter Label
Counter Description

TOOLS_LIDB_QUERY_ATTMP

The total number of times the reporting feature server received a request to perform an LIDB query from the QVT tool.

TOOLS_LIDB_QUERY_SUCC

The total number of times the reporting feature server received a request to perform an LIDB query from the QVT tool and completed it successfully.


Translation Verification Tool

This section describes the TVT and includes the following sections:

Overview

Command Format

Response Format

Translation Verification Tool Measurements

Overview

The TVT is a diagnostic tool that simulates a call from the originator to a specific destination based on dialed digits. It enables a user to check system translations and determine if routing will occur as expected without making a call.

Command Format

The TVT command uses the following format:

translate <line|trunk>; parameter=value;

Examples

translate line calling-dn=2189722345; called-dn=8002550005

Syntax Description

* Calling-DN

The caller's directory number. VARCHAR(10): 10 digits in the format npaxxxxxxx.

Called-DN

 

Examples

translate trunk tgn-id= 1; called-dn=7034321234;

Syntax Description

* Called-DN

 

* Tgn-ID

 

GAP

 

Response Format

Translation is the process of determining the destination of a call based on the dialed digits. The TVT performs translations and returns the tables traversed in order to reach the destination number. It does not complete a call but only allows you to view the route of the call.

The following example illustrates an incoming line call terminating to a trunk.

CLI> translate line calling-dn=9722331286;called-dn=7034321234;

TABLE: SUBSCRIBER

ID=sub1_ata2;CATEGORY=INDIVIDUAL;NAME=sub1;STATUS=ACTIVE;DN1=9722331003;PRIVACY=NONE;RING_ 
TYPE_DN1=1;TERM_ID=a00/1;MGW_ID=ata2;PIC1=NONE;PIC2=NONE;PIC3=NONE;GRP=N;USAGE_SENS=Y;SUB_ 
PROFILE_ID=northtexas;TERM_TYPE=TERM;IMMEDIATE_RELEASE=N;TERMINATING_IMMEDIATE_REL=N;SEND_ 
BILLING_DN=N;SEND_BDN_AS_CPN=N;SEND_BDN_FOR_EMG=N;

TABLE: SUBSCRIBER_PROFILE

ID=northtexas;DIAL_PLAN_ID=dp1;LOCAL_PFX1_OPT=NR;TOLL_PFX1_OPT=RQ;POP_ID=1;OLI=0;EA_USE_PI
C1=Y;

TABLE: DIAL_PLAN_PROFILE

ID=dp1;DESCRIPTION=dialingplanprofile;NANP_DIAL_PLAN=Y;DNIS_DIGMAN_ID=dp1;

TABLE: DIAL_PLAN

ID=dp1;DIGIT_STRING=408555;DEST_ID=ssp1dest;SPLIT_NPA=NONE;DEL_DIGITS=0;MIN_DIGITS=10;MAX_
DIGITS=10;NOA=NATIONAL;

TABLE: DESTINATION
DEST_ID=ssp1dest;CALL_TYPE=LOCAL;ROUTE_TYPE=ROUTE;ROUTE_GUIDE_ID=ssp1rg;ZERO_PLUS=N;INTRA_ 
STATE=Y;GAP_ROUTING=N;CLDPTY_CTRL_REL_ALWD=N;TABLE: ROUTE_GUIDE 
ID=ssp1rg;POLICY_TYPE=ROUTE;POLICY_ID=ssp1route;

TABLE: ROUTE
ID=ssp1route;TGN1_ID=1;DEL_DIGITS1=0;DEL_DIGITS2=0;DEL_DIGITS3=0;DEL_DIGITS4=0;DEL_DIGITS5 
=0;DEL_DIGITS6=0;DEL_DIGITS7=0;DEL_DIGITS8=0;DEL_DIGITS9=0;DEL_DIGITS10=0;TG_SELECTION=RR;

TABLE: TRUNK_GRP
ID=1;CALL_AGENT_ID=CA146;TG_TYPE=SS7;NUM_OF_TRUNKS=24;DPC=1-12-1;TG_PROFILE_ID=ssp1-tg-pro
f;STATUS=INS;DIRECTION=BOTH;SEL_POLICY=ASC;GLARE=EVEN;ALT_ROUTE_ON_CONG=N;SIGNAL_PORTED_NU
MBER=N;POP_ID=1;REMOTE_SWITCH_LRN=2122129999;DIAL_PLAN_ID=dp19;DESCRIPTION=TG to 
BTS12;DEL_DIGITS=0;OPER_STATUS=NF;TRAFFIC_TYPE=TANDEM;ANI_BASED_ROUTING=N;CLLI=DAL177DS3;C
ALL_CTRL_ROUTE_ID=bts12-ccroute1;MGCP_PKG_TYPE=T;ANI_SCREENING=N;SEND_RDN_AS_CPN=N;

Reply :Success:

CLI>

Translation Verification Tool Measurements

Table 15-4 identifies the measurements generated by the TVT Tool.

Table 15-4 TVT Tool Counters

Counter Label
Counter Description

TOOLS_LNP_QUERY_ATTMP

The total number of times the reporting feature server received a request to perform an LNP query from the QVT tool.

TOOLS_LNP_QUERY_SUCC

The total number of times the reporting feature server received a request to perform an LNP query from the QVT tool and completed it successfully.

TOOLS_TOLLFREE_QUERY_ATTMP

The total number of times the reporting feature server received a request to perform a Toll Free query from the QVT tool.

TOOLS_TOLLFREE_QUERY_SUCC

The total number of times the reporting feature server received a request to perform a Toll Free query from the QVT tool and completed it successfully.


Using Query Verification Tool and Translation Verification Tool Together

It may be necessary to use both QVT and TVT queries to diagnose routing of a call. If the results of a translate command indicate that a toll-free or LNP query is generated, execute the QVT query. Use the results of the QVT query to generate another TVT query.

The following example illustrates verifying routing of a call from (972) 233-1286 to (800) 255-3002:


Step 1 Execute a TVT translate command:

CLI> translate line calling-dn=9722331286; called-dn=8002553002;

TRANSLATE LINE ON CALL AGENT CA146 IS...->
TABLEINFO ->
******TOLL FREE CALL NEEDS AN 800 QUERY******

Reply : Success:

CLI>

Step 2 The translate command indicates that a Toll-Free query is required. Perform the QVT query to do the number translation.

CLI> query toll-free called-dn=8002553002; calling-dn=9722331286; lata=100; opc-id=opc;

TOLL FREE QUERY ON FEATURE SERVER FSAIN520 IS...->
RESULT->
OPC=7-2-1
SSN=254
TT-254
SCP-Point-Code=1-101-0
Message-Type=IN/1
Called Number=8002553002
Translated Number=7034323002
Carrier=0000

Reply : Success:

CLI>

Step 3 The translated number returned by the QVT query can now be used in a TVT translate command to verify call routing.

CLI> translate line calling-dn=9722331286;called-dn=7034323002;

TRANSLATE LINE ON CALL AGENT CA146 IS... ->

TABLEINFO ->

TABLE: SUBSCRIBER

ID=sub_1_6;CATEGORY=INDIVIDUAL;NAME=sub16;STATUS=ACTIVE;ADDRESS1=1651 n glenville suite 
200;ADDRESS2=Richardson tx 
75081;BILLING_DN=9722331286;DN1=9722331286;PRIVACY=NONE;RING_TYPE_DN1=1;TERM_ID=aaln/S1/6;
MGW_ID=c2421_1;PIC1=NONE;PIC2=NONE;PIC3=NONE;GRP=N;USAGE_SENS=Y;SUB_PROFILE_ID=sub_pmlhg_p
rof1;TERM_TYPE=TERM;IMMEDIATE_RELEASE=N;TERMINATING_IMMEDIATE_REL=N;SEND_BILLING_DN=N;SEND
_BDN_AS_CPN=N;SEND_BDN_FOR_EMG=N;

TABLE: SUBSCRIBER_PROFILE

ID=sub_pmlhg_prof1;DIAL_PLAN_ID=dp1;LOCAL_PFX1_OPT=NR;TOLL_PFX1_OPT=RQ;LSA=9;POP_ID=1;OLI=
0;EA_USE_PIC1=N;

TABLE: DIAL_PLAN_PROFILE
ID=dp1;DESCRIPTION=dialing plan profile ID 1;NANP_DIAL_PLAN=Y;DNIS_DIGMAN_ID=dp_svc;

TABLE: DIAL_PLAN

ID=dp1;DIGIT_STRING=703432;DEST_ID=ssp1-dest;SPLIT_NPA=NONE;DEL_DIGITS=0;MIN_DIGITS=7;MAX_
DIGITS=10;NOA=NATIONAL;

TABLE: DESTINATION

DEST_ID=ssp1-dest;CALL_TYPE=LOCAL;ROUTE_TYPE=ROUTE;ROUTE_GUIDE_ID=ssp1-rg;ZERO_PLUS=N;INTR
A_STATE=Y;GAP_ROUTING=N;CLDPTY_CTRL_REL_ALWD=N;

TABLE: ROUTE_GUIDE

ID=ssp1-rg;POLICY_TYPE=ROUTE;POLICY_ID=ssp1-route;

TABLE: ROUTE

ID=ssp1-route;TGN1_ID=3;DEL_DIGITS1=0;DEL_DIGITS2=0;DEL_DIGITS3=0;DEL_DIGITS4=0;DEL_DIGITS
5=0;DEL_DIGITS6=0;DEL_DIGITS7=0;DEL_DIGITS8=0;DEL_DIGITS9=0;DEL_DIGITS10=0;TG_SELECTION=RR
;

TABLE: TRUNK_GRP

ID=3;CALL_AGENT_ID=CA146;TG_TYPE=SS7;NUM_OF_TRUNKS=24;DPC=1-12-1;TG_PROFILE_ID=ssp1-tg-pro
f;STATUS=INS;DIRECTION=BOTH;SEL_POLICY=ASC;GLARE=EVEN;ALT_ROUTE_ON_CONG=N;SIGNAL_PORTED_NU
MBER=N;POP_ID=1;REMOTE_SWITCH_LRN=2122129999;DIAL_PLAN_ID=dp19;DESCRIPTION=TG to 
BTS12;DEL_DIGITS=0;OPER_STATUS=NF;TRAFFIC_TYPE=TANDEM;ANI_BASED_ROUTING=N;CLLI=DAL177DS3;C 
ALL_CTRL_ROUTE_ID=bts12-ccroute1;MGCP_PKG_TYPE=T;ANI_SCREENING=N;SEND_RDN_AS_CPN=N;

Reply : Success:

CLI>


Network Loopback Test for Network-based Call Signaling/Media Gateway Control Protocol Endpoints

This section describes the feature that provides the capability to perform network loopback test on any line side PacketCable Network-based Call Signaling protocol specification/Media Gateway Control Protocol (NCS/MGCP) Residential Gateways initiated from designated test endpoints. This document also describes enhancements to the TDM bearer path test call feature.

This section contains the following:

Overview

Restrictions

Installing

Configuring

Using/Operating the Network Loopback Test for Network-based Call Signaling/Media Gateway Control Protocol Endpoints

Overview

The Network Loopback Test for NCS/MGCP Endpoints feature provides a testing device with the capability to perform network loopback tests from any line side NCS/MGCP residential gateways or media termination adapters (MTAs). These loopback tests are initiated from designated test endpoints (subscribers) controlled by the Cisco BTS 10200 Softswitch.

Restrictions

Although you can test this feature by using the regular MTA as the testing device by configuring the endpoints as subscriber terminations in Cisco BTS 10200 Softswitch, you need special test equipment such as BRIX if voice quality testing needs to be done.

You should configure the testing and tested devices on the same Call Agent. The Cisco BTS 10200 Softswitch cannot perform network loopback test calls that originate from another switch and does not route calls from a testing device on an H.323 or SIP interface.


Note You cannot perform the network loopback test if the status of the subscriber to be tested is unequipped (UEQP) or operational-out-of-service (OOS).


Installing

The following items must be configured:

Test origination endpoints as trunks instead of line.

Special dial plan and destination with CALL-TYPE TEST-CALL; CALL-SUBTYPE=NLB-TEST).

Configuring

To configure the originating line (media gateway profile) for the testing device, use the following procedure:


Step 1 Configure the media gateway for the testing device as RGW (residential gateway):

MGW-PROFILE::TYPE=RGW

Step 2 Associate the media gateway to the MGW-PROFILE specific to network loopback test origination:

MGW-PROFILE::SPARE2-SUPP=Y

Step 3 Configure all test lines in the testing device as subscriber terminations.


Configuration Examples

The following example describes the steps required to configure the originating line (media gateway profile) to identify a network loopback call.


Note These tasks include examples of CLI commands that illustrate how to provision the specific feature. Most of these tables have additional tokens that are not included in the examples. For a complete list of all CLI tables and tokens, see the Cisco BTS 10200 Softswitch Command Line Interface Reference Guide.


 
Command or Action
Purpose

Step 1 

Configure the basic office database (such as Call-Agent; POP; Office).

 

Step 2 

Enter the following CLI commands:


add mgw-profile id=mta1; SPARE2-SUPP=Y;

add mgw id=brix; mgw-profile=mta1; tasp-addr=mta.abc.com; call-agent-id=CA146


Configures the MGW as a testing device.

Note "brix" is an example of a test equipment that can be used.

Step 3 

Enter the following CLI commands:


add termination prefix=aaln/s1/; port-start=1; port-end=2; type=LINE; mgw-id= brix;

add subscriber-profile id=dp5; dial-plan-id=dp1; pop-id=1;

add sub id=Abc; category=INDIVIDUAL; name=ABC; status=ACTIVE; billing-dn= 555-123-4567; ring-type-dn1= 1; term-id=aaln/S1/1; sub-profile-id=dp5; mgw-id=c2421;


Configures the test originating subscriber lines on the testing device.

Where:

brix is an example of a test equipment

555-123-4567 is an example of a subscriber number

Note If you want calls to terminate on the subscriber testing device, you must assign dn1 when the subscriber is provisioned, as shown in the following example:

dn1= <subscriber number>

Using/Operating the Network Loopback Test for Network-based Call Signaling/Media Gateway Control Protocol Endpoints

This section explains how to perform the following task:

Dedicated Test Trunk Group

Shared Test Trunk Group

Configuring the Originating Trunk Group

To use this feature, place a call from the testing device subscriber to any MGCP subscriber to be tested. For example, if the testing device is an MGCP telephone, dial the number of the subscriber to be tested.

Dedicated Test Trunk Group

The Cisco BTS10200 Softswitch allows NCS/MGCP endpoints in a trunk group to be provisioned as a test trunk group with certain test attributes.

The test attributes consist of whether the incoming calls arriving on these test trunk groups will trigger the Cisco BTS10200 Softswitch to perform call completion via Network Loopback (NLB) or Network Continuity Test (NCT) method toward the eMTA. Hence, the category of the test is pre-provisioned on these incoming test dedicated trunk groups—all calls from a particular test trunk group invoke the same test category toward the eMTAs while calls from another test trunk group perform a different test category. The call from the testing device addresses the eMTA directory number (DN) as any regular digit that can be dialed.

The called party number format is:

<Test-data>

Where:

<Test-data> = DN (for example, the NCS/MGCP dialed digits signaled to the Cisco BTS10200 Softswitch are in the form of a 10-digit DN such as 2145261234, or <TG>TM> (Trunk group and trunk member)

The steps for configuring the originating trunk group are:


Step 1 Add a trunk group for the testing device as CAS trunk group (TRUNK-GRP::TG-TYPE=CAS).

Step 2 Associate the trunk group to CAS-TG-PROFILE specific to network loopback test origination type (CAS-TG-PROFILE::TEST-LINE=Y; CAS-TG-PROFILE::TEST-LINE-TYPE=NLB-LINE/NCT-LINE/NLB-TRUNK/NCT-TRUNK.

Step 3 Add all test lines in the testing device as trunk termination.


Shared Test Trunk Group

In addition to dedicated test trunk groups, the Cisco BTS 10200 Softswitch allows a shared test trunk group, where the category of the test to be run is specified by the test-prefix. Cisco BTS 10200 Softswitch allows a test trunk group to be associated with a test dial plan. The test trunk group can be either the IP or CAS TDM trunks. Incoming calls from the network on these trunk groups will be analyzed according to a pre configured test dial plan. The following is the format of dialed digits for these incoming test calls.

Called party number format:

<Test-prefix><Test-data>

Where:

<Test-prefix> is a string of digits that denote the test category. Operator must configure the definition (recommended as a pattern of 1 to 6 digits, the BTS10200 Softswitch will perform the longest match) of the test prefix and its length, whether it is an IP or TDM testing. If it is TDM testing, the traditional 1xx test type value is expected or the general TDM test category needs to be specified (for example, 199) when the route out DN testing is going to be used.

For example, test-prefix 152 may denote NLB IP testing, or 105 may convey the TDM 105 test-type, or 199 may be defined to specify the TDM route out DN testing, or 153 is the configured prefix for NCT.

<Test-data> is a string that depends on the test-prefix content.

Configuring the Originating Trunk Group

The following are the steps for configuring the originating trunk group:


Step 1 Add a trunk-group for the testing device as CAS trunk-group (TRUNK-GRP::TG-TYPE=CAS).

Step 2 Associate the trunk-grp to CAS-TG-PROFILE specific to network loopback test origination (CAS-TG-PROFILE::TEST-LINE=Y; CAS-TG-PROFILE::TEST-LINE-TYPE=NTE.

Step 3 Configure all test lines in Testing device as trunk-termination.

Step 4 Configure the test dial plan destination with the exact type of test call.

Step 5 Configure the main subscriber ID for testing trunk-grp.

Step 6 Configure the digit map for collecting prefixed digits and associate it to the SUBSCRIBER-PROFILE table.

Session Initiation Protocol Subscriber Registration Status Check

The SIP subscriber registration status check CLI command (sip-reg-contact) is used to check the registration status of a SIP subscriber. The need to check the registration status of a SIP subscriber may arise, for example, when a subscriber complains about not being able to receive calls. The first item to check would be the registration status using the sip-reg-contact CLI command. The next item would be to check for events regarding authentication failures and etc.

The following examples show the usage of the sip-reg-contact CLI command. The first example provides an example of a expired contact and the second example provides an example of a registered contact or current contact.

Example 1:

CLI to check the registration status of an address of record (AOR).

CLI>status sip-reg-contact;
CLI>AOR_ID=4692551119@sia-SYS44CA146.ipclab.cisco.com;
AOR ID -> 4692551119@sia-SYS44CA146.ipclab.cisco.com
USER -> 4692551119
HOST -> 10.89.220.21
PORT -> 5060
USER TYPE ->  USER_PHONE_TYPE
EXPIRES -> 3600
EXPIRETIME -> Tue Oct  7 12:13:11 2003
STATUS -> EXPIRED CONTACT
Reply : Success:

Example 2:

CLI to check the registration status of an AOR.

CLI>status sip-reg-contact;
CLI>AOR_ID=4692551001@sia-SYS44CA146.ipclab.cisco.com;
AOR ID -> 4692551001@sia-SYS44CA146.ipclab.cisco.com
USER -> 4692551001
HOST -> 10.89.223.193
PORT -> 5060
USER TYPE -> USER_IP_TYPE
EXPIRES -> 3600
EXPIRETIME -> Thu Oct 23 16:23:48 2003
STATUS -> REGISTERED CONTACT
Reply : Success:

System Health Report

The System Health Report (system-health) (SHR) allows the retrieval of the status of various processes within the Cisco BTS 10200 Softswitch.

Use the following command example to run a SHR immediately:

CLI>report system-health period=720;

PERIOD

The amount of time to collect back to in hours. INTEGER: 1-720 (Default = 24).


The SHR command can be used in conjunction with the command scheduler. Using the command scheduler, the SHR runs at periodic intervals collecting the last 24 hours (configurable) worth of data. Upon initial installation and startup, there is an SHR command already scheduled to execute at midnight every 24 hours.

To schedule multiple SHR command(s) at different times, the command scheduler add command can be issued multiple times:

CLI>add scheduled-command verb=report; noun=system-health; <recurrence=DAILY>; 
<start-time=...>; <keys=period>; <values=...>

Use the following command to remove any scheduled SHR command(s):

CLI>delete scheduled-command id=NNN

Use the following command to obtain an ID number and view the list of scheduled command(s):

CLI>show scheduled-command verb=report; noun=system-health

To reschedule an SHR command for another time, change the recurrence, or change the collection period, use the following command:

CLI>change scheduled-command id=NNN; <recurrence=DAILY>; <start-time=...>; <keys=period>; 
<values=...>