Cisco BTS 10200 Softswitch Troubleshooting Guide, Release 7.0

Diagnostic Tests

Introduction

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

•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

•Fast Audit and Sync Tool

•ISDN Network Loopback Test

•Enhanced Traffic Measurement

•Cisco BTS 10200 Status

•Call Tracer (CTRAC)

•Tabular Display of Events and Alarms

•Prior to Manual Switchover Switch Integrity Diagnostic Utility

•PSTN Trunk Testing

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 might 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 maintenance state.

Step 1 Force the media gateway into maintenance 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 maintenance state.

Step 1 Force the subscriber termination into maintenance 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 maintenance state for testing.

Step 1 Force the SS7 trunk termination into maintenance 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

Test 2: SS7 Termination Connection Test

Test 3: SS7 COT Test

Test 4: SS7 CQM Test

Test 5: SS7 CVT Test

Test 6: SS7 CIC Audit

Test 0: ALL Tests

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 0 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;

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 maintenance state for testing.

Step 1 Force the ISDN trunk termination into maintenance 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 maintenance state for testing.

Step 1 Force the CAS trunk termination into maintenance 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 maintenance state for testing.

Step 1 Force the Announcement trunk termination into maintenance 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 call agent itself in a production network. It can cause performance degradation.

Snoop can be used on the Cisco BTS 10200 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 set up 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. There are probably multiple roots, so 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 snoop 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 example, interfaces qfe0 and qfe4 must be snooped.

Step 2 Issue the snoop command. The syntax might differ 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 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 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 like those 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.

# 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. 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 uses to communicate 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. 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 uses to communicate 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 Registration, Admissions, 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. 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) in the following way:

# 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 number called from the signal switching point (SSP).

•Query Tool E800VER Command—Send a database query to the SCP as if it were 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;

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.

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 one in 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 subsystem, 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 and the IP transfer point (ITP) gateway, a local network failure might 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 title translation (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-3 identifies the measurements generated by the POTS Feature Server for the QVT feature.

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;

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_PIC1=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; EL_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-prof; STATUS=INS; DIRECTION=BOTH; SEL_POLICY=ASC; GLARE=EVEN; 
ALT_ROUTE_ON_CONG=N; SIGNAL_PORTED_NUMBER=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; 
CALL_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.

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_prof1; 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; 
INTRA_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_DIGITS5=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-prof; STATUS=INS; DIRECTION=BOTH; SEL_POLICY=ASC; GLARE=EVEN; 
ALT_ROUTE_ON_CONG=N; SIGNAL_PORTED_NUMBER=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; 
CALL_CTRL_ROUTE_ID=bts12-ccroute1; MGCP_PKG_TYPE=T; ANI_SCREENING=N; SEND_RDN_AS_CPN=N;

Reply: Success:

CLI>

LNP Examples

The following examples illustrate typical LNP call scenarios.

Example 1

This example illustrates a TVT command on a trunk origination, with CdPN resulting in an LNP query. QVT gets the RN and suggests the second translate command. The second TVT shows the route of the outgoing trunk group to the recipient switch.

btsadmin> translate trunk tgn-id=5; called-dn=11501160;

TRANSLATE ON CALL AGENT CA146 IS... -> 

TABLEINFO -> 

TABLE: TRUNK_GRP

ID=5; CALL_AGENT_ID=CA146; TG_TYPE=SS7; NUM_OF_TRUNKS=24; DPC=5-2-3; 
TG_PROFILE_ID=tgprof_inet116; STATUS=INS; DIRECTION=IN; SEL_POLICY=DSC; GLARE=SLAVE; 
ALT_ROUTE_ON_CONG=N; SIGNAL_PORTED_NUMBER=Y; POP_ID=hun1; DIAL_PLAN_ID=dp_trk_itu; 
Description=TG IN from Inet 116; DEL_DIGITS=0; TRAFFIC_TYPE=LOCAL; ANI_BASED_ROUTING=N; 
CALL_CTRL_ROUTE_ID=cc_rte_i116_tg5; MGCP_PKG_TYPE=T; ANI_SCREENING=N; SEND_RDN_AS_CPN=N; 
STATUS_MONITORING=N; SEND_EARLY_BKWD_MSG=N; EARLY_BKWD_MSG_TMR=5; SCRIPT_SUPP=N; 
VOICE_LAYER1_USERINFO=AUTO; VOICE_INFO_TRANSFER_CAP=AUTO; ACCESS_TYPE=COMBINED; 
POI=INTER_ENDOFFICE; PERFORM_LNP_QUERY=Y;

TABLE: DIAL_PLAN_PROFILE

.

.

.

TABLE: OFFICE_CODE

DIGIT_STRING=11501; OFFICE_CODE_INDEX=15; DID=N; CALL_AGENT_ID=CA146; DIALAB

LE=Y; NDC=1; EC=150; DN_GROUP=1xxx; EC_DIGIT_STRING=1150;

TABLE: DN2SUBSCRIBER

OFFICE_CODE_INDEX=15; DN=1160; STATUS=PORTED_OUT; RING_TYPE=1; LNP_TRIGGER=N; 
NP_RESERVED=N; LAST_CHANGED=2005-08-11 14:30:09.0; VIRTUAL_DN=N; PORTED_IN=N;

 ****** THIS CALL NEEDS AN LNP QUERY ******

****** LNP QUERY is needed (Onward Call Routing query), Suggested QUERY 

Command to Run ******

QUERY LNP; tgn-id=5; called-dn=11501160

****** If query result is Routing Number (RN) Not Found,

       the above translation is valid

****** Otherwise, use the TRANSLATE command

       suggested by the query result

Reply: Success: 

btsadmin> QUERY LNP tgn-id=5; called-dn=11501160;

QUERY ON FEATURE SERVER FSAIN205 IS... -> 

RESULT -> 

Called Number=11501160, Routing Number (RN) =4101

**** Suggested TRANSLATE Command ****

TRANSLATE TRUNK tgn_id=5; original_called_dn=11501160; called_dn=4101-11501160; 
noa=PORTED_NUMBER_WITH_RN;

btsadmin> TRANSLATE TRUNK tgn_id=5; original_called_dn=11501160; called_dn=4101-11501160; 
noa=PORTED_NUMBER_WITH_RN;

TRANSLATE ON CALL AGENT CA146 IS... -> 

TABLEINFO -> 

TABLE: TRUNK_GRP

.

.

.

ID=inet116_rg1; POLICY_TYPE=ROUTE; POLICY_ID=inet116_rte;

TABLE: ROUTE

ID=inet116_rte; TGN1_ID=6; 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=SEQ; NEXT_ACTION=NONE;

TABLE: TRUNK_GRP

ID=6; CALL_AGENT_ID=CA146; TG_TYPE=SS7; NUM_OF_TRUNKS=24; DPC=5-2-4; 
TG_PROFILE_ID=tgprof_inet116; STATUS=INS; DIRECTION=OUT; SEL_POLICY=DSC; GLARE=SLAVE; 
ALT_ROUTE_ON_CONG=N; SIGNAL_PORTED_NUMBER=Y; POP_ID=hun1; DIAL_PLAN_ID=dp_trk_itu; 
Description=TG OUT to Inet 116; DEL_DIGITS=0; TRAFFIC_TYPE=LOCAL; ANI_BASED_ROUTING=N; 
CALL_CTRL_ROUTE_ID=cc_rte_i116_tg6; MGCP_PKG_TYPE=T; ANI_SCREENING=N; SEND_RDN_AS_CPN=N; 
STATUS_MONITORING=N; SEND_EARLY_BKWD_MSG=N; EARLY_BKWD_MSG_TMR=5; SCRIPT_SUPP=N; 
VOICE_LAYER1_USERINFO=AUTO; VOICE_INFO_TRANSFER_CAP=AUTO; ACCESS_TYPE=COMBINED; 
POI=INTER_ENDOFFICE; PERFORM_LNP_QUERY=N;

Reply: Success: 

Example 2

In this example, a subscriber dials a DN ported-out of this switch. QVT gets the RN, and a second TVT shows the route of the outgoing trunk group to the recipient switch.

Because the called DN is ported-out, the call cannot be routed on this switch without an LNP query. If QVT does not find an RN, perhaps because the DN2RN table is incorrect temporarily during the porting transition, the call will be released due to cause unallocated number.

btsadmin> translate line calling-dn=11501511; called-dn=11501160;

TRANSLATE ON CALL AGENT CA146 IS... -> 

TABLEINFO -> 

TABLE: SUBSCRIBER

ID=sipata1; CATEGORY=INDIVIDUAL; NAME=h15 sipata1 Moe; STATUS=ACTIVE; BILLING_DN=11501511; 
DN1=11501511; PRIVACY=NONE; RING_TYPE_DN1=1; PIC1=NONE; PIC2=NONE; PIC3=NONE; GRP=N; 
USAGE_SENS=Y; SUB_PROFILE_ID=hungary_prof; TERM_TYPE=SIP; IMMEDIATE_RELEASE=N; 
TERMINATING_IMMEDIATE_REL=N; AOR_ID=11501511@192.168.54.124; SEND_BDN_AS_CPN=N; 
SEND_BDN_FOR_EMG=N; PORTED_IN=N; BILLING_TYPE=NONE; VMWI=Y; SDT_MWI=Y;

.

.

.

TABLE: DN2SUBSCRIBER

OFFICE_CODE_INDEX=15; DN=1160; STATUS=PORTED_OUT; RING_TYPE=1; LNP_TRIGGER=N; 
NP_RESERVED=N; LAST_CHANGED=2005-08-11 14:30:09.0; VIRTUAL_DN=N; PORTED_IN=N;

 ****** THIS CALL NEEDS AN LNP QUERY ******

****** LNP QUERY is needed (Onward Call Routing query), Suggested QUERY Command to Run 
******

QUERY LNP calling-dn=11501511; called-dn=11501160

****** If query result is Routing Number (RN) Not Found,

       the above translation is valid

****** Otherwise, use the TRANSLATE command

       suggested by the query result

Reply: Success: 

btsadmin>

btsadmin>

btsadmin> QUERY LNP calling-dn=11501511; called-dn=11501160

QUERY ON FEATURE SERVER FSAIN205 IS... -> 

RESULT -> 

Called Number=11501160, Routing Number (RN) =4101

**** Suggested TRANSLATE Command ****

TRANSLATE LINE calling_dn=11501511; original_called_dn=11501160; called_dn=4101-11501160; 
NOA=PORTED-NUMBER-WITH-RN;

QUERYSTATUS -> Query Success

Reply: Success: 

btsadmin>

btsadmin>

btsadmin> TRANSLATE LINE calling_dn=11501511; original_called_dn=11501160; 
called_dn=4101-11501160; NOA=PORTED-NUMBER-WITH-RN;

TRANSLATE ON CALL AGENT CA146 IS... -> 

TABLEINFO -> 

TABLE: SUBSCRIBER

ID=sipata1; CATEGORY=INDIVIDUAL; NAME=h15 sipata1 Moe; STATUS=ACTIVE; BILLING_DN=11501511; 
DN1=11501511; PRIVACY=NONE; RING_TYPE_DN1=1; PIC1=NONE; PIC2=NONE; PIC3=NONE; GRP=N; 
USAGE_SENS=Y; SUB_PROFILE_ID=hungary_prof; TERM_TYPE=SIP; IMMEDIATE_RELEASE=N; 
TERMINATING_IMMEDIATE_REL=N; AOR_ID=11501511@192.168.54.124; SEND_BDN_AS_CPN=N; 
SEND_BDN_FOR_EMG=N; PORTED_IN=N; BILLING_TYPE=NONE; VMWI=Y; SDT_MWI=Y;

.

.

.

TABLE: TRUNK_GRP

ID=6; CALL_AGENT_ID=CA146; TG_TYPE=SS7; NUM_OF_TRUNKS=24; DPC=5-2-4; 
TG_PROFILE_ID=tgprof_inet116; STATUS=INS; DIRECTION=OUT; SEL_POLICY=DSC; GLARE=SLAVE; 
ALT_ROUTE_ON_CONG=N; SIGNAL_PORTED_NUMBER=Y; POP_ID=hun1; DIAL_PLAN_ID=dp_trk_itu; 
Description=TG OUT to Inet 116; DEL_DIGITS=0; TRAFFIC_TYPE=LOCAL; ANI_BASED_ROUTING=N; 
CALL_CTRL_ROUTE_ID=cc_rte_i116_tg6; MGCP_PKG_TYPE=T; ANI_SCREENING=N; SEND_RDN_AS_CPN=N; 
STATUS_MONITORING=N; SEND_EARLY_BKWD_MSG=N; EARLY_BKWD_MSG_TMR=5; SCRIPT_SUPP=N; 
VOICE_LAYER1_USERINFO=AUTO; VOICE_INFO_TRANSFER_CAP=AUTO; ACCESS_TYPE=COMBINED; 
POI=INTER_ENDOFFICE; PERFORM_LNP_QUERY=N;

Reply: Success: 

btsadmin>

Example 3

In this example, the first TVT shows a translation but indicates that an LNP query is needed. The QVT does not find an RN, so the first TVT has the correct translation and routing information.

btsadmin> translate line calling-dn=11501511; called-dn=11501512;

TRANSLATE ON CALL AGENT CA146 IS... -> 

TABLEINFO -> 

TABLE: SUBSCRIBER

ID=sipata1; CATEGORY=INDIVIDUAL; NAME=h15 sipata1 Moe; STATUS=ACTIVE; BILLING_DN=11501511; 
DN1=11501511; PRIVACY=NONE; RING_TYPE_DN1=1; PIC1=NONE; PIC2=NONE; PIC3=NONE; GRP=N; 
USAGE_SENS=Y; SUB_PROFILE_ID=hungary_prof; TERM_TYPE=SIP; IMMEDIATE_RELEASE=N; 
TERMINATING_IMMEDIATE_REL=N; AOR_ID=11501511@192.168.54.124; SEND_BDN_AS_CPN=N; 
SEND_BDN_FOR_EMG=N; PORTED_IN=N; BILLING_TYPE=NONE; VMWI=Y; SDT_MWI=Y;

TABLE: SUBSCRIBER_PROFILE

ID=hungary_prof; DIAL_PLAN_ID=dp_sub_itu; LOCAL_PFX1_OPT=NR; TOLL_PFX1_OPT=RQ; 
POP_ID=hun1; OLI=0; EA_USE_PIC1=Y; INTERLATA_PFX1_OPT=RQ;

.

.

.

TABLE: SUBSCRIBER

ID=sipata2; CATEGORY=INDIVIDUAL; NAME=h15 sipata2 Larry; STATUS=ACTIVE; 
BILLING_DN=11501512; DN1=11501512; PRIVACY=NONE; RING_TYPE_DN1=1; PIC1=NONE; PIC2=NONE; 
PIC3=NONE; GRP=N; USAGE_SENS=Y; SUB_PROFILE_ID=hungary_prof; TERM_TYPE=SIP; 
IMMEDIATE_RELEASE=N; TERMINATING_IMMEDIATE_REL=N; AOR_ID=11501512@192.168.54.124; 
SEND_BDN_AS_CPN=N; SEND_BDN_FOR_EMG=N; PORTED_IN=N; BILLING_TYPE=NONE; VMWI=Y; SDT_MWI=Y;

****** LNP QUERY is needed (LNP-TRIGGER for ODBR), Suggested QUERY Command to Run ******

QUERY LNP calling-dn=11501511; called-dn=11501512

****** If query result is Routing Number (RN) Not Found,

       the above translation is valid

****** Otherwise, use the TRANSLATE command

       suggested by the query result

Reply: Success: 

btsadmin>

btsadmin> QUERY LNP calling-dn=11501511; called-dn=11501512

QUERY ON FEATURE SERVER FSAIN205 IS... -> 

RESULT -> 

Called Number=11501512, Routing Number (RN) Not Found

QUERYSTATUS -> Query Success

Reply: Success: 

Example 4

This example is for a QOR originating switch. A subscriber dials a DN that is ported-out of another (donor) switch. The call is translated and routed to the donor switch, as shown in the first translate TVT command below. The donor switch sends a REL with LNP QOR: Ported Number cause to the originating switch.

The originating switch receives the REL with LNP QOR: Ported Number cause, and then the originating switch does an LNP query. The QVT query finds an RN, and the RN and NOA are used as input to the TVT to show the routing after the QOR query, as shown in the second translated command below.

btsadmin> translate line calling-dn=11501511; called-dn=11161168

TRANSLATE ON CALL AGENT CA146 IS... -> 

TABLEINFO -> 

TABLE: SUBSCRIBER

ID=sipata1; CATEGORY=INDIVIDUAL; NAME=h15 sipata1 Moe; STATUS=ACTIVE; BILLING_DN=11501511; 
DN1=11501511; PRIVACY=NONE; RING_TYPE_DN1=1; PIC1=NONE; PIC2=NONE; PIC3=NONE; GRP=N; 
USAGE_SENS=Y; SUB_PROFILE_ID=hungary_prof; TERM_TYPE=SIP; IMMEDIATE_RELEASE=N; 
TERMINATING_IMMEDIATE_REL=N; AOR_ID=11501511@192.168.54.124; SEND_BDN_AS_CPN=N; 
SEND_BDN_FOR_EMG=N; PORTED_IN=N; BILLING_TYPE=NONE; VMWI=Y; SDT_MWI=Y;

TABLE: SUBSCRIBER_PROFILE

ID=hungary_prof; DIAL_PLAN_ID=dp_sub_itu; LOCAL_PFX1_OPT=NR; TOLL_PFX1_OPT=RQ; 
POP_ID=hun1; OLI=0; EA_USE_PIC1=Y; INTERLATA_PFX1_OPT=RQ;

.

.

.

TABLE: TRUNK_GRP

ID=6; CALL_AGENT_ID=CA146; TG_TYPE=SS7; NUM_OF_TRUNKS=24; DPC=5-2-4; 
TG_PROFILE_ID=tgprof_inet116; STATUS=INS; DIRECTION=OUT; SEL_POLICY=DSC; GLARE=SLAVE; 
ALT_ROUTE_ON_CONG=N; SIGNAL_PORTED_NUMBER=Y; POP_ID=hun1; DIAL_PLAN_ID=dp_trk_itu; 
Description=TG OUT to Inet 116; DEL_DIGITS=0; TRAFFIC_TYPE=LOCAL; ANI_BASED_ROUTING=N; 
CALL_CTRL_ROUTE_ID=cc_rte_i116_tg6; MGCP_PKG_TYPE=T; ANI_SCREENING=N; SEND_RDN_AS_CPN=N; 
STATUS_MONITORING=N; SEND_EARLY_BKWD_MSG=N; EARLY_BKWD_MSG_TMR=5; SCRIPT_SUPP=N; 
VOICE_LAYER1_USERINFO=AUTO; VOICE_INFO_TRANSFER_CAP=AUTO; ACCESS_TYPE=COMBINED; 
POI=INTER_ENDOFFICE; PERFORM_LNP_QUERY=N;

Reply: Success: 

btsadmin>

btsadmin>

btsadmin>

btsadmin>

btsadmin> query LNP calling-dn=11501511; called-dn=11161168;

QUERY ON FEATURE SERVER FSAIN205 IS... -> 

RESULT -> 

Called Number=11161168, Routing Number (RN) =4001

**** Suggested TRANSLATE Command ****

TRANSLATE LINE calling_dn=11501511; original_called_dn=11161168; called_dn=4001-11161168; 
NOA=PORTED-NUMBER-WITH-RN;

QUERYSTATUS -> Query Success

Reply: Success: 

btsadmin>

btsadmin>

btsadmin>

btsadmin>

btsadmin> TRANSLATE LINE calling_dn=11501511; original_called_dn=11161168; 
called_dn=4001-11161168; NOA=PORTED-NUMBER-WITH-RN;

TRANSLATE ON CALL AGENT CA146 IS... -> 

TABLEINFO -> 

TABLE: SUBSCRIBER

ID=sipata1; CATEGORY=INDIVIDUAL; NAME=h15 sipata1 Moe; STATUS=ACTIVE; BILLING_DN=11501511; 
DN1=11501511; PRIVACY=NONE; RING_TYPE_DN1=1; PIC1=NONE; PIC2=NONE; PIC3=NONE; GRP=N; 
USAGE_SENS=Y; SUB_PROFILE_ID=hungary_prof; TERM_TYPE=SIP; IMMEDIATE_RELEASE=N; 
TERMINATING_IMMEDIATE_REL=N; AOR_ID=11501511@192.168.54.124; SEND_BDN_AS_CPN=N; 
SEND_BDN_FOR_EMG=N; PORTED_IN=N; BILLING_TYPE=NONE; VMWI=Y; SDT_MWI=Y;

TABLE: SUBSCRIBER_PROFILE

ID=hungary_prof; DIAL_PLAN_ID=dp_sub_itu; LOCAL_PFX1_OPT=NR; TOLL_PFX1_OPT=RQ; 
POP_ID=hun1; OLI=0; EA_USE_PIC1=Y; INTERLATA_PFX1_OPT=RQ;

.

.

.

TABLE: TRUNK_GRP

ID=6; CALL_AGENT_ID=CA146; TG_TYPE=SS7; NUM_OF_TRUNKS=24; DPC=5-2-4; 
TG_PROFILE_ID=tgprof_inet116; STATUS=INS; DIRECTION=OUT; SEL_POLICY=DSC; GLARE=SLAVE; 
ALT_ROUTE_ON_CONG=N; SIGNAL_PORTED_NUMBER=Y; POP_ID=hun1; DIAL_PLAN_ID=dp_trk_itu; 
Description=TG OUT to Inet 116; DEL_DIGITS=0; TRAFFIC_TYPE=LOCAL; ANI_BASED_ROUTING=N; 
CALL_CTRL_ROUTE_ID=cc_rte_i116_tg6; MGCP_PKG_TYPE=T; ANI_SCREENING=N; SEND_RDN_AS_CPN=N; 
STATUS_MONITORING=N; SEND_EARLY_BKWD_MSG=N; EARLY_BKWD_MSG_TMR=5; SCRIPT_SUPP=N; 
VOICE_LAYER1_USERINFO=AUTO; VOICE_INFO_TRANSFER_CAP=AUTO; ACCESS_TYPE=COMBINED; 
POI=INTER_ENDOFFICE; PERFORM_LNP_QUERY=N;

Reply: Success: 

Example 5

This example illustrates an incoming trunk call with an RN prefix and ported number NOA.

Note In this example, the Cisco BTS 10200 reminds you that the NOA and ORIGINAL-CALLED-DN tokens must both be specified.

btsadmin> translate trunk tgn-id=5; called-dn=400111501512; NOA=PORTED-NUMBER-WITH-RN;

Reply: Failure: NOA and ORIGINAL-CALLED-DN should be specified together

btsadmin>

btsadmin>

btsadmin> translate trunk tgn-id=5; called-dn=400111501512; NOA=PORTED-NUMBER-WITH-RN; 
original-called-dn=11501512;

TRANSLATE ON CALL AGENT CA146 IS... -> 

TABLEINFO -> 

TABLE: TRUNK_GRP

ID=5; CALL_AGENT_ID=CA146; TG_TYPE=SS7; NUM_OF_TRUNKS=24; DPC=5-2-3; 
TG_PROFILE_ID=tgprof_inet116; STATUS=INS; DIRECTION=IN; SEL_POLICY=DSC; GLARE=SLAVE; 
ALT_ROUTE_ON_CONG=N; SIGNAL_PORTED_NUMBER=Y; POP_ID=hun1; DIAL_PLAN_ID=dp_trk_itu; 
Description=TG IN from Inet 116; DEL_DIGITS=0; TRAFFIC_TYPE=LOCAL; ANI_BASED_ROUTING=N; 
CALL_CTRL_ROUTE_ID=cc_rte_i116_tg5; MGCP_PKG_TYPE=T; ANI_SCREENING=N; SEND_RDN_AS_CPN=N; 
STATUS_MONITORING=N; SEND_EARLY_BKWD_MSG=N; EARLY_BKWD_MSG_TMR=5; SCRIPT_SUPP=N; 
VOICE_LAYER1_USERINFO=AUTO; VOICE_INFO_TRANSFER_CAP=AUTO; ACCESS_TYPE=COMBINED; 
POI=INTER_ENDOFFICE; PERFORM_LNP_QUERY=Y;

TABLE: DIAL_PLAN_PROFILE

ID=dp_trk_itu; Description=Trunk Origination Local dial-plan (ITU); NANP_DIAL_PLAN=N; 
ANI_DIGMAN_ID=dm_dpp_ani_itu; DNIS_DIGMAN_ID=dm_dpp_trk_itu; OVERDECADIC_DIGITS_SUPP=N; 
NOA_BASED_ROUTING=Y; NOA_ROUTE_PROFILE_ID=noa_rt;

TABLE: DIGMAN

ID=dm_dpp_ani_itu; RULE=1; MATCH_NOA=ANY; REPLACE_NOA=NATIONAL;

TABLE: DIGMAN

ID=dm_dpp_trk_itu; RULE=1; MATCH_STRING=^4001; REPLACE_STRING=NONE; 
MATCH_NOA=PORTED_NUMBER_WITH_RN; REPLACE_NOA=UNKNOWN;

TABLE: NOA_ROUTE_PROFILE

ID=noa_rt; Description=NOA Route profile (ITU) to RN dial-plan;

CONTINUE WITH EXISTING DIAL-PLAN

TABLE: DIAL_PLAN

ID=dp_trk_itu; DIGIT_STRING=1150; DEST_ID=dest_sub_itu; SPLIT_NPA=NONE; DEL_DIGITS=0; 
MIN_DIGITS=8; MAX_DIGITS=8; NOA=UNKNOWN;

TABLE: DESTINATION

DEST_ID=dest_sub_itu; CALL_TYPE=LOCAL; ROUTE_TYPE=SUB; ZERO_PLUS=N; INTRA_STATE=Y; 
Description=ITU Sub dest: Allow LNP query; GAP_ROUTING=N; ANI_DIGMAN_ID=dm_dest_sub_ani; 
DNIS_DIGMAN_ID=dm_dest_rn; CLDPTY_CTRL_REL_ALWD=N; CALL_SUBTYPE=NONE; 
ACQ_LNP_QUERY=PERFORM_LNP_QUERY;

TABLE: OFFICE_CODE

DIGIT_STRING=11501; OFFICE_CODE_INDEX=15; DID=N; CALL_AGENT_ID=CA146; DIALABLE=Y; NDC=1; 
EC=150; DN_GROUP=1xxx; EC_DIGIT_STRING=1150;

TABLE: DN2SUBSCRIBER

OFFICE_CODE_INDEX=15; DN=1512; STATUS=ASSIGNED; RING_TYPE=1; LNP_TRIGGER=Y; NP_RESERVED=N; 
SUB_ID=sipata2; LAST_CHANGED=2005-09-08 11:08:47.0; VIRTUAL_DN=N; PORTED_IN=N;

TABLE: SUBSCRIBER

ID=sipata2; CATEGORY=INDIVIDUAL; NAME=h15 sipata2 Larry; STATUS=ACTIVE; 
BILLING_DN=11501512; DN1=11501512; PRIVACY=NONE; RING_TYPE_DN1=1; PIC1=NONE; PIC2=NONE; 
PIC3=NONE; GRP=N; USAGE_SENS=Y; SUB_PROFILE_ID=hungary_prof; TERM_TYPE=SIP; 
IMMEDIATE_RELEASE=N; TERMINATING_IMMEDIATE_REL=N; AOR_ID=11501512@192.168.54.124; 
SEND_BDN_AS_CPN=N; SEND_BDN_FOR_EMG=N; PORTED_IN=N; BILLING_TYPE=NONE; VMWI=Y; SDT_MWI=Y;

Reply: Success: 

btsadmin>

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 tests on any line side PacketCable Network-based Call Signaling protocol specification/Media Gateway Control Protocol (NCS/MGCP) Residential Gateways. The network loopback tests can be initiated from designated test endpoints. This section also describes enhancements to the TDM bearer path test call feature.

This section contains the following:

•Overview

•Restrictions

•Installing

•Configuring

•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.

The basic network loopback test feature is service affecting. In other words, while a network loopback call is in progress, the endpoint is considered busy.

The Cisco BTS 10200 network loopback and network continuity tests also have a service-not-affected mode. In this mode, the Cisco BTS 10200 will attempt to create coexisting test connections on the test device; however, if the endpoint does not have enough resources, the Cisco BTS 10200 gives preference to regular calls, processing them first before it processes any test calls.

In the service-affected mode the Cisco BTS 10200 will not try to initiate other calls, even if the MTA/TGW can set up multiple connections (PARALLEL-TEST-CONN-SUPP=Y).

The Cisco BTS 10200 allows the system level configuration to specify whether the network loopback and network continuity test calls will be service affecting or not service affecting.

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), 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 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

In order for parallel test connections to work, the following settings need to be configured in the ca-config:

add ca-config type=NLB-TEST-SERVICE-AFFECTING; datatype=BOOLEAN; value=N;

add ca-config type=NCT-TEST-SERVICE-AFFECTING; datatype=BOOLEAN; value=N;

Configuration Examples

The following example shows 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 CLI Database.

Global Configuration Example

Step 1 Add ca-config NLB-TEST-SERVICE-AFFECTING.

add ca-config type=NLB-TEST-SERVICE-AFFECTING; value=N

Step 2 Add ca-config NCT-TEST-SERVICE-AFFECTING.

add ca-config type=NCT-TEST-SERVICE-AFFECTING; value=N;

Step 3 Add ca-config TEST-TRUNK-GRP-DIGITS.

add ca-config type=TEST-TRUNK-GRP-DIGITS; value=4;

Step 4 Add ca-config TEST-TRUNK-MEMBER-DIGITS.

add ca-config type=TEST-TRUNK-MEMBER-DIGITS; value=4;

Dedicated NLB Testing Device Configuration Example

The following procedure is a dedicated NLB testing device configuration example. Change TEST-LINE-TYPE to different values (other than NTE) to change test origination type.

Step 1 Add MGW profile.

add mgw-profile id=BRIX; vendor=Tollgrade; mgcp-version=mgcp_1_0; MGCP-VARIANT=NCS-1-0;

Step 2 Add cas-tg-profile.

add cas-tg-profile id=BRIX_TG; sig-type=LINE; TEST-LINE=Y; TEST-LINE-TYPE=NLB-LINE-TEST

Step 3 Add MGW.

add mgw id=brix1; tsap-addr=<mgw DNS / IP address>; mgw-profile-id=BRIX; type=TGW; 
call-agent id=CA146;

Step 4 Add trunk-grp.

add trunk-grp id=100; call-agent-id=CA146; tg-type=CAS; cas-tg-profile=BRIX_TG; 
mgcp-pkg-type=LINE

Step 5 Add termination.

add termination prefix=aaln/; port-start=1; port-end=2; type=TRUNK; mgw-id=c925.172; 

Step 6 Add trunk.

add trunk termination-prefix=aaln/; termination-port-start=1; termination-port-end=2; 
cic-start=1; cic-end=2; tgn-id=100

Shared Testing Device Configuration Example

The following procedure is a shared testing device configuration example.

Step 1 Add MGW profile.

add mgw-profile id=BRIX; vendor=Tollgrade; mgcp-version=mgcp_1_0; MGCP-VARIANT=NCS-1-0;

Step 2 Add cas-tg-profile.

add cas-tg-profile id=BRIX_TG; sig-type=LINE; TEST-LINE=Y; TEST-LINE-TYPE=NTE

Step 3 Add MGW.

add mgw id=brix1; tsap-addr=<mgw DNS / IP address>; mgw-profile-id=BRIX; type=TGW; 
call-agent id=CA146;

Step 4 Add trunk-grp.

add trunk-grp id=100; call-agent-id=CA146; tg-type=CAS; cas-tg-profile=BRIX_TG; 
mgcp-pkg-type=LINE

Step 5 Add termination.

add termination prefix=aaln/; port-start=1; port-end=2; type=TRUNK; mgw-id=c925.172;

Step 6 Add trunk.

add trunk termination-prefix=aaln/; termination-port-start=1; termination-port-end=2; 
cic-start=1; cic-end=2; tgn-id=100

Step 7 Add dial-plan-profile.

add dial-plan-profile id=dp1; description=NA_Default;

Step 8 Add dial-plan.

add dial-plan id=dp1; digit-string=919-392; dest-id=sub; noa=national;

Step 9 Add digit-map.

add digit-map id=test; 
digit-pattern=[2-9]xx[2-9]xxxxxx|011xxxxxx.T|01xxxxxx.T|101xxxx|#|*xx|11xx|xxxxxxxxxxxxxxx
xxxx; description=default_pattern

Step 10 Add subscriber-profile.

add subscriber-profile id=subpf1; digit-map-id=test; dial-plan-id=DP1; POP-ID=1;

Step 11 Add subscriber.

add subscriber id=sub11; sub-profile-id= subpf1; category=individual; term-id=aaln/0; 
mgw-id=c925.172; dn1=919-392-1235; name=RTP5;

Tested Line Device Configuration Example

The following procedure is a tested line device configuration example.

Step 1 Add MGW profile.

add mgw-profile id=UBR925; vendor=Cisco; mgcp-version=mgcp_1_0; MGCP-VARIANT=NCS_1_0;

Step 2 Add MGW.

add mgw id=c925.172; tsap-addr=<mgw DNS / IP address>; mgw-profile-id=UBR925; call-agent 
id=CA103;

Step 3 Add termination.

add termination prefix=aaln/; port-start=0; port-end=1; type=line; mgw-id=c925.172; 
mgcp-pkg-type=line-ncs; 

Step 4 Add destination.

add destination dest-id=local-call; route-type=sub; call-type=local;

Step 5 Add dial-plan-profile.

add dial-plan-profile id=dp1; description=NA_Default;

Step 6 Add dial-plan.

add dial-plan id=dp1; digit-string=919-392; dest-id=sub; noa=national;

Step 7 Add subscriber-profile.

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

Step 8 Add subscriber.

add subscriber id=sub11; sub-profile-id= subpf1; category=individual; term-id=aaln/0; 
mgw-id=c925.172; dn1=919-392-1235; name=RTP5;

Routing for Shared trunk-grp IP Testing Flow Chart Configuration Example

The following procedure is a routing for shared trunk-grp IP testing flow chart configuration example.

Step 1 Add destination.

add destination dest-id=DEST_NLB_SUB; call-type=TEST-CALL; call-subtype=NLB-LINE-TEST; 
route-type=SUB;

add destination dest-id=DEST_NCT_SUB; call-type=TEST-CALL; call-subtype=NCT-LINE-TEST; 
route-type=SUB;

add destination dest-id=DEST_NLB_TRUNK; call-type=TEST-CALL; call-subtype=NLB-TRUNK-TEST; 
route-type=ROUTE; route-guide-id=abc

add destination dest-id=DEST_NCT_TRUNK; call-type=TEST-CALL; call-subtype=NCT-TRUNK-TEST; 
route-type=ROUTE; route-guide-id=abc

Step 2 Add call-subtype-profile.

add call-subtype-profile call-type=TEST_CALL; call-subtype=NONE; qos-id=1;

Step 3 Add dial-plan-profile.

add dial-plan-profile id=test; nanp-dial-plan=N

Step 4 Add dial-plan.

add dial-plan id=test; digit-string=151; dest-id=DEST_NLB_SUB; min-digits=13; 
max-digits=13

add dial-plan id=test; digit-string=152; dest-id=DEST_NCB_SUB; min-digits=13; 
max-digits=13

add dial-plan id=test; digit-string=153; dest-id=DEST_NLB_TRUNK; min-digits=13; 
max-digits=13

add dial-plan id=test; digit-string=154; dest-id=DEST_NCT_TRUNK; min-digits=13; 
max-digits=13

Testing Device Status and Control Flowchart Configuration Example

The following procedure is a testing device status and control flowchart configuration example.

Step 1 Control MGW.

control mgw id=c925.172; target-state=INS; mode=FORCED;

Step 2 Status MGW.

status mgw id=c925.172;

Step 3 Control trunk-grp.

control trunk-grp id=100; call-agent-id=CA146; 	target-state=INS; mode=forced;

Step 4 Equip trunk-termination.

equip trunk-termination tgn-id=100; cic=all;

Step 5 Control trunk-termination.

control trunk-termination tgn-id=100; cic=all; target-state=INS; mode=forced;

Step 6 Status trunk-termination.

status trunk-termination id=100; cic=all;

Step 7 Reset trunk-termination.

reset trunk-termination id=100; cic=all;

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

This section describes network loopback testing for network-based call signaling and media gateway control protocol endpoints feature and includes descriptions of the following:

•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 BTS 10200 allows NCS/MGCP endpoints in a trunk group to be provisioned as a dedicated test trunk group.

The provisioning of the test trunk group determines if incoming calls arriving on the dedicated test trunk groups trigger the Cisco BTS 10200 to complete the test call through a Network Loopback (NLB) or Network Continuity Test (NCT). The category of the test call is preprovisioned on the dedicated test trunk groups—all calls from a particular test trunk group invoke the same test category while calls from another test trunk group might invoke a different test category. A test call from a test device utilizes the eMTA directory number (DN) the same as any other regular dialed digit string.

The called party number format is:

<Test-data>

Where:

<Test-data> = DN (for example, the NCS/MGCP dialed digits signaled to the Cisco BTS 10200 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 allows a shared test trunk group, where the category of the test to be run is specified by the test-prefix. Cisco BTS 10200 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 are analyzed according to a preconfigured 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 Cisco BTS 10200 Softswitch will perform the longest match) of the test prefix and its length, whether it is 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 call subtype profile.

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

Step 7 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 can arise, for example, when a subscriber complains about not being able to receive calls. The first item to check would be the registration status; use the sip-reg-contact command. The next item would be to check for events regarding authentication failures and so on.

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

Example 1:

Use 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:

Use 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.

Use the following example shows you how to run a SHR:

CLI> report system-health period=720;

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 of the Cisco BTS 10200, an SHR command is scheduled to execute at midnight every 24 hours.

To schedule multiple SHR command(s) at different times, you can use the command scheduler add command 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=...>

Fast Audit and Sync Tool

The bts_audit and bts_sync process tools involve running two commands, bts_audit and bts_sync. The bts_audit and bts_sync tools are designed to improve speed and integrity of auditing and syncing the Cisco BTS 10200 databases. The tools can audit and synchronize all mismatches between network elements.

These tools are not a part of the CLI, but are UNIX programs that are run by the root user. They bypass the platform messaging paths and access the EMS, CA, FSPTC, and FSAIN databases directly using database tools. The data is manipulated and updates are applied directly to synchronize the databases.

The bts_audit tool is able to

•Find tables with mismatches

•Find rows missing in application database

•Find rows missing in EMS database

•Find rows with data mismatches between two databases

•Generate a report that lists these mismatches

•Generate the SQL to be used to correct the mismatches

The bts_sync tool is used to send the generated SQL statements to the appropriate destination to bring the databases into synchronization.

The Cisco BTS 10200 fast audit and sync tools feature consists of two UNIX shell scripts that use other UNIX scripts and utilities to perform full-database and table audits of the databases on the various network elements of the system. The database mismatches are synchronized using the bts_sync tool.

The bts_audit tool determines the table sizes when performing full database audit by analyzing the catalog of the CA, FSPTC and FSAIN databases. The scripts will create copies of the data from the tables in a standardized format. The data files are used to generate a checksum for each table. The checksums are compared, and if they are not equal, the network element data file is transferred to the EMS. On the EMS, the data is compared row by row, and mismatches are printed to a file that can be used by the bts_sync tool to restore synchronization of the table on the network element.

Restrictions and Limitations

The Cisco BTS 10200 fast audit and sync tools feature has the following restrictions and limitations:

•The bts_audit/bts_sync tools are unable to audit and synchronize certain scenarios, such as when a termination record points to an invalid mgw.

•The bts_sync tool should only be run to synchronize the data mismatches between the active platforms.

•If an audit is given a list of tables, and a table references a missing row in another table, the mismatch will not be resolved by the sync.

Using the bts_audit Tool

To use the bts_audit tool, log in at the UNIX root prompt and execute the bts_audit command.

Using the bts_sync Tool

To use the bts_sync tool, the bts_audit command must be executed first. Log in at the unix root prompt and execute the bts_audit command. Once the bts_audit command is execution is complete, execute the bts_sync command to synchronize the system databases.

Command Parameters

This section describes the parameters for the bts_audit and bts_sync commands. The following is an example of the bts_audit command parameters:

Example:

bts_audit -ems <ems> -ca <ca> [-platforms <platforms>] [-tables <tables>] 

Where:

ems is the hostname of the active EMS machine.

ca is the hostname of the active CA machine.

platforms is a list of the platforms to be audited without spaces and separated by commas

tables is a list of tables to be audited without spaces and separated by commas.

Example:

bts_audit -ems priems01 -ca prica01 -platforms CA146,FSAIN205 -tables 
SUBSCRIBER,MGW_PROFILE 

The bts_sync command takes a list of filenames to be used for correcting errors found by the audit.

Example:

bts_sync /opt/ems/report/Audit_CA146_root.sql 

or

bts_sync /opt/ems/report/Audit_*_root.sql 

Command Responses

The execution of the bts_audit command will output a list of database mismatches found.

Database Out of Synchronization

To troubleshoot database out of synchronization alarms, take the following steps:

Step 1 Log in the system at the unix root prompt.

Step 2 Execute the bts_audit command.

Step 3 Once the audit is completed, execute the bts_sync command.

IDX Database Auditing

BTS 10200 provides the functionality to compare (audit) the IDX database on both the CA/FS nodes. The IDX database is a proprietary shared memory database. Previous versions of BTS 10200 provided audit functionality between EMS to EMS and EMS to CA/FS nodes. The IDX database auditing feature enables comparison of IDX DB between CA/FS to CA/FS nodes.

There are two kinds of tables in IDX database.

•Static table—contains provisioned data from EMS. Provisioned data is generally static data. Some static tables may also have call-related dynamic data.

•Dynamic table—call related data. This data could be changing quickly and dynamically while calls are being set up, established and terminated. The dynamic tables also contain replication queue information, which holds the replication requests.

Note that this feature audits only the static tables because dynamic tables contain fast changing data, which is difficult to audit.

This feature uses the PAS (Platform Application Server) interface. PAS is the platform independent inter-node XML messaging interface. The messaging is through SSL over TCP/IP connection. Each platform on CA/FS node, CA, FSAIN and FSPTC, has a PAS server process taking requests and sending back responses.

dbm_audit

The dbm_audit program is the executable file that user needs to execute on any EMS node to perform CA/FS to CA/FS IDX audit. This feature is executed from the Unix command shell on any EMS node. The platform status of CA/FS should be either Active or Standby to perform this IDX database audit.

The executable file of this feature is named dbm_audit, and it is installed in the /opt/bts/bin directory on all BTS nodes. The audit report is generated in the /opt/ems/report directory on the EMS node.

The tool compares the following:

•The table row count

•The index of each record

•The content of each record

The file name of the audit report contain the following:

•The hostname of both CA/FS nodes

•The time stamp of the audit complete time

The audit report contains the following information:

•Audit starting time

•Audit ending time

•The error message if audit fails

•Number of the mismatched tables

•Entry for every audited table

–Name of the audited table

–The application (platform) that associates with the audited table

–Overall audit result of the audited table

–Type of the mismatch if any, in the row count, index, record content

–The index number of the mismatched IDX record

Command Parameters

The following is the command usage for using dbm_audit executable:

dbm_audit  -table <value1>  -platform <value2>  -type <value3>

where the -table parameter can have the following values:

•all

•a static table name

The "all" value is the default value if the -table parameter is not specified.

where the -platform parameter can have the following values:

•CA

•FSAIN

•FSPTC

•"all" for all the above platforms.

The "all" value is the default value if the -platform parameter is not specified.

where the -type parameter can have the following values:

•full

•row_count

The "row_count" value is the default value if the -type parameter is not specified.

Error Conditions

The dbm_audit tool displays the following error message when the audit is performed between IDX databases of different release versions of BTS 10200:

ERROR: Unable to audit different release DB

The dbm_audit tool skips the audit of a platform if the status of the platform is neither active or standby. Following error message is displayed:

ERROR: <CA/FS_appname> on <hostname> is neither Active nor Standby

The dbm_audit tool exits with the following error message when a dynamic table name is given for table audit option:

WARNING: <table_name> is not a static table in <platform_name>

The dbm_audit tool exits with the following error message when at least one of the CA/FS transitions to OOS status during audit.

ERROR: <CA/FS_appname> going OOS

The dbm_audit tool exits gracefully with the following error message when the tool is unable to set up PAS connection to the CA/FS nodes.

ERROR: Platform status is found OOS for CA-B on <hostname>
ERROR: Unable to perform DBM audit on CA

The dbm_audit tool exits gracefully with the following error message when the PAS session times out:

ERROR: PAS session not responding

ISDN Network Loopback Test

This section describes the Network Loopback (NLB) Test for ISDN PRI trunks (ISDN NLB) feature. Network Loopback Test for ISDN-PRI trunks (ISDN NLB) feature allows operators to conduct network loopback testing originating from shared ISDN PRI trunks. The shared test trunk group accepts both normal and test calls. Test calls are identified by provisioning the call-type and call-subtype tokens in the Destination table.

The Cisco BTS 10200 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 The network loopback test cannot be performed if the status of the subscriber to be tested is unequipped (UEQP) or operational-out-of-service (OOS).

Configuring

The following items must be configured:

•Test origination endpoints as trunks instead of lines.

•Special dial plan and destination with call-type=test-call.

•Call-subtype must be configured as one of:

–nlb-line-test

–nct-line-test

–nlb-trunk-test

–nct-trunk-test

Originating Trunk Group

The ISDN NLB feature uses a shared test trunk group, where the type of test is specified by the test-prefix. Cisco BTS 10200 allows a test trunk group to be associated with a test dial plan. The test trunk group is an ISDN PRI trunk. Incoming calls from the network on an ISDN PRI trunk are analyzed according to a preconfigured 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 of the test prefix and its length. We recommend a pattern of 1 to 6 digits—but the first digit cannot be "1", the Cisco BTS 10200 performs the longest match.

•<Test-data> is a string that depends on the test-prefix content. The following steps configure the originating trunk group:

Step 1 Add a trunk-group for the testing device as an ISDN PRI trunk-group if it does not already exist.

trunk-grp tg-type=isdn;

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

Step 3 Configure the call type subprofile.

Step 4 Configure a main subscriber ID for the testing trunk group if necessary.

Call Agent Configuration Table

The system defaults for the Call Agent Configuration (ca-config) table may require changing, based on the needs of the test. Take the following steps to change the service affect of the test.

Step 1 Execute the following commands to change service affect for either NCT or NLB testing. The default service affect is Y.

change ca-config nct-test-service-affecting=n;

change ca-config nlb-test-service-affecting=n;

–Y—Subscriber under test cannot make or receive calls.

–N—Subscriber under test can make or receive calls; test calls are dropped.

Step 2 Define the number of digits for the trunk group and CICs that are under test. The defaults for both are 4.

change ca-config test-trunk-grp-digits=<x>;

change ca-config test-trunk-member-digits=<x>;

Dial Plan

If the nanp-dial-plan token in the Dial Plan Profile table is set to Y, then the nature of address (NOA) in the Dial Plan table cannot be unknown. The NOA can be set to national. The first digit of the prefix cannot be 1—use any number between 2 and 9.

Sample Configurations

The following sample configurations illustrate how to configure the Cisco BTS 10200 for ISDN NLB with network terminating equipment (NTE).

Note In these samples, digit-string=nnn (where nnn = 551 and so forth), nnn is the test-prefix.

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 CLI Database.

Line Loopback Tests Over an ISDN Trunks

This section provides examples of Network Test Equipment (NTE) line loopback over ISDN trunks.

NLB Tests

This section provides examples of network loopback (NLB) line loopback tests over ISDN trunks.

NLB Line Loopback Test Over an ISDN Trunk

This section provides sample steps for the NTE NLB trunk test over an ISDN trunk feature.

add destination dest-id=nlb-line-test; 
call-type=test-call; call-subtype=nlb-line-test;

add call-subtype-profile call-type=TEST_CALL; 
call-subtype=NONE; qos-id=1;

add dial plan id=<xxx>; digit-string=551; 
dest-id=nlb-trunk-test; split-npa=none; 
del-digits=0; min-digits=13; max-digits=13; 
noa=national;

From the test equipment, dial the NTE NLB trunk test 
call (551+xxx-xxx-xxxx)

Hang up the test call and verify the Billing call type. 

NLB Line Loopback Test Over an ISDN Trunk With Service Affecting Turned On

This section provides sample steps for the NTE NLB line test over an ISDN trunk with "service affecting" turned on feature.

add destination dest-id=nlb-line-test; 
call-type=test-call; call-subtype=nlb-line-test;

add call-subtype-profile call-type=TEST_CALL; 
call-subtype=NONE; qos-id=1;

add dial plan id=<xxx>; digit-string=551; 
dest-id=nlb-line-test; split-npa=none; 
del-digits=0; min-digits=13; max-digits=13; 
noa=national;

add ca-config type=nlb-test-service-affecting=y; 
datatype=boolean; value=y;

NLB Line Loopback Test Over an ISDN Trunk With Service Affecting Turned Off and Parallel Test Connection Support Turned Off

This section provides sample steps for the NTE NLB line test over an ISDN trunk with "service affecting" turned off feature.

add destination dest-id=nlb-line-test; 
call-type=test-call; call-subtype=nlb-line-test; 

add call-subtype-profile call-type=TEST_CALL; 
call-subtype=NONE; qos-id=1;

add dial plan id=<xxx>; digit-string=551; 
dest-id=nlb-line-test; split-npa=none; 
del-digits=0; min-digits=13; max-digits=13; 
noa=national;

add ca-config type=nlb-test-service-affecting=n; 
datatype=boolean; value=n;

NLB Line Loopback Test Over an ISDN Trunk With Service Affecting Turned Off and Parallel Test Connection Support Turned On: Call from Subscriber Under Test

This section provides sample steps for the NTE NLB line test over an ISDN trunk with "service affecting" turned on and parallel test connection support turned on feature. The call is from the subscriber under test.

add destination dest-id=nlb-line-test; 
call-type=test-call; call-subtype=nlb-line-test; 

add call-subtype-profile call-type=TEST_CALL; 
call-subtype=NONE; qos-id=1;

add dial plan id=<xxx>; digit-string=551; 
dest-id=nlb-line-test; split-npa=none; 
del-digits=0; min-digits=13; max-digits=13; 
noa=national;

add ca-config type=nlb-test-service-affecting=n; 
datatype=boolean; value=n; 

change mgw-profile id=isdnNLB; 
parallel-test-conn-supp=y;

NLB Line Loopback Test Over an ISDN Trunk With Service Affecting Turned Off and Parallel Test Connection Support Turned On: Call to Subscriber Under Test

This section provides sample steps for the NTE NLB line test over an ISDN trunk with "service affecting" turned off and parallel test connection support turned on feature. The call is to the subscriber under test.

add destination dest-id=nlb-line-test; 
call-type=test-call; call-subtype=nlb-line-test; 

add call-subtype-profile call-type=TEST_CALL; 
call-subtype=NONE; qos-id=1;

add dial plan id=<xxx>; digit-string=551; 
dest-id=nlb-line-test; split-npa=none; 
del-digits=0; min-digits=13; max-digits=13; 
noa=national;

add ca-config type=nlb-test-service-affecting=n; 
datatype=boolean; value=n; 

change mgw-profile id=isdnNLB; 
parallel-test-conn-supp=y;

NCT Tests

This section provides examples of line loopback network continuity tests (NCT) over ISDN.

NCT Line Loopback Test Over an ISDN Trunk

This section provides sample steps for the NTE NLB trunk test over an ISDN trunk feature.

add destination dest-id=nlb-line-test; 
call-type=test-call; call-subtype=nct-line-test; 

add call-subtype-profile call-type=TEST_CALL; 
call-subtype=NONE; qos-id=1;

add dial plan id=<xxx>; digit-string=552; 
dest-id=nlb-trunk-test; split-npa=none; 
del-digits=0; min-digits=13; max-digits=13; 
noa=national; 

NCT Line Loopback Test Over an ISDN Trunk With Service Affecting Turned On

This section provides sample steps for NTE NCT line test over an ISDN trunk with "service affecting" turned on feature.

add destination dest-id=nlb-line-test; 
call-type=test-call; call-subtype=nct-line-test; 

add call-subtype-profile call-type=TEST_CALL; 
call-subtype=NONE; qos-id=1;

add dial plan id=<xxx>; digit-string=552; 
dest-id=nlb-line-test; split-npa=none; 
del-digits=0; min-digits=13; max-digits=13; 
noa=national; 

add ca-config type=nlb-test-service-affecting=y; 
datatype=boolean; value=y; 

NCT Line Loopback Test Over an ISDN Trunk With Service Affecting Turned Off and Parallel Test Connection Support Turned Off

This section provides sample steps for the NTE NCT line test over an ISDN trunk with "service affecting" turned off feature.

add destination dest-id=nlb-line-test; 
call-type=test-call; call-subtype=nct-line-test; 

add call-subtype-profile call-type=TEST_CALL; 
call-subtype=NONE; qos-id=1;

add dial plan id=<xxx>; digit-string=552; 
dest-id=nlb-line-test; split-npa=none; 
del-digits=0; min-digits=13; max-digits=13; 
noa=national; 

add ca-config type=nlb-test-service-affecting=n; 
datatype=boolean; value=n; 

NCT Line Loopback Test Over an ISDN Trunk with Service Affecting Turned Off and Parallel Test Connection Support Turned On: Call from Subscriber Under Test

This section provides sample steps for the NTE NCT line test over an ISDN trunk with service "affecting turned" on and parallel test connection support turned on feature. The call is from the subscriber under test.

add destination dest-id=nlb-line-test; 
call-type=test-call; call-subtype=nct-line-test; 

add call-subtype-profile call-type=TEST_CALL; 
call-subtype=NONE; qos-id=1;

add dial plan id=<xxx>; digit-string=552; 
dest-id=nlb-line-test; split-npa=none; 
del-digits=0; min-digits=13; max-digits=13; 
noa=national; 

add ca-config type=nlb-test-service-affecting=n; 
datatype=boolean; value=n; 

change mgw-profile id=isdnNLB; 
parallel-test-conn-supp=y; 

NCT Line Loopback Test Over an ISDN Trunk With Service Affecting Turned Off and Parallel Test Connection Support Turned On: Call to Subscriber Under Test

This section provides sample steps for the NTE NCT line test over an ISDN trunk with "service affecting" turned off and parallel test connection support turned on feature. The call is to the subscriber under test.

add destination dest-id=nlb-line-test; 
call-type=test-call; call-subtype=nct-line-test; 

add call-subtype-profile call-type=TEST_CALL; 
call-subtype=NONE; qos-id=1;

add dial plan id=<xxx>; digit-string=552; 
dest-id=nlb-line-test; split-npa=none; 
del-digits=0; min-digits=13; max-digits=13; 
noa=national; 

add ca-config type=nlb-test-service-affecting=n; 
datatype=boolean; value=n; 

change mgw-profile id=isdnNLB; 
parallel-test-conn-supp=y;