Cisco BTS 10200 Softswitch ISDN Guide, Release 6.0.4

Maintaining and Troubleshooting the ISDN System

Introduction

This chapter describes ISDN maintenance and troubleshooting commands and procedures for the Cisco BTS 10200 Softswitch. See also the Cisco BTS 10200 Softswitch Troubleshooting Guide for more details about causes and corrective actions related to events and alarms.

Status and Control Commands

This section describes the status and control commands for ISDN.

Table Name: ISDN-DCHAN

Table Containment Area: EMS, Call Agent

Command Types

Status and control

Examples

Status isdn-dchan dchan-type=primary; 

Status isdn-dchan dchan-type= backup; 

Control isdn-dchan dchan-type=primary; mode=forced; target-state=oos; 

Control isdn-dchan dchan-type=backup; mode=forced; target-state=oos; 

Control isdn-dchan dchan-type=primary; mode=forced; target-state=ins; 

Control isdn-dchan dchan-type=backup; mode=forced; target-state=ins; 

Usage Guidelines

Table 4-1 describes the D channel operational status to status output mappings.

Table 4-2 describes the D Channel NFAS operational status to status output mappings.

Syntax Description

See the Cisco BTS 10200 Softswitch CLI Database for more information on the ISDN D Channel token.

How to Troubleshoot When the ISDN D Channel Fails to be Restored

This section shows how to troubleshoot if the ISDN D Channel fails to restore. Determine if the D Channel failed to restore by entering the following command:

status isdn-dchan id=nnn;dchan-type=<primary | backup>;

•If the response shows that the D Channel is out-of-service for the administrative state, then enter the control command.

status isdn-dchan id=100;dchan-type=primary 

REASON -> ADM executed successfully

RESULT -> ADM configure result in success

ISDN DCHAN ID -> 100

DCHAN TYPE -> PRIMARY

ADMIN STATE -> ADMIN_OOS 

OPER STATE -> ISDN D Channel is Out-Of-Service

Reply : Success: at 2007-01-03 14:56:18 by btsadmin

control isdn-dchan id=nnn;dchan-type=<primary | backup>;target-state=ins

•If the response does not show that the D Channel is in-service; and if the NFAS or D Channel backup shows ISDN_DCHAN_STATE_INS for the D Channel operational status, then:

–If the response is "ISDN D Channel out-of-service" go to Step 1.

–If the response is ISDN D "Channel restore session set fail normal or switchover" go to Step 2.

–If the response is "ISDN D Channel restore establish fail normal or switchover" go to Step 3.

–If the response is "ISDN D Channel is in Wait for Service Ack or ISDN D Channel is Maintenance Busy" go to Step 4.

–If the response is "ISDN D Channel down session set fail hard normal" go to Step 5.

–If the response is "ISDN D Channel down establish fail hard normal" go to Step 6.

–If the response is "ISDN D Channel delete graceful" go to Step 7.

Step 1 D Channel state for FAS: "ISDN D Channel out-of-service", or NFAS: "ISDN D Channel is Manual Out-of-Service".

This means the administrative state was set to in service, but the command to go to operational state was ignored due to bad provisioning.

Things to Check:

Make sure that the correct entries exist in the ISDN D Channel table.

Step 2 D Channel states for FAS: "ISDN D Channel restore session set fail normal or switchover"; or NFAS: "ISDN D Channel is Backhaul Session Down".

This response means that the Call Agent and the media gateway are not communicating. The backhaul session is not coming up. The problem has to do with the UDP port numbers, IP addresses or DNS names, or network connectivity. These values are all provisioned in the RUDP Backhaul Session table in the Call Agent. For Cisco IOS gateways, these values are part of the session group groupn.....

Things to Check

a. Do the four entries in the RUDP Backhaul Session table of the Call Agent match the values in the gateway? (for Cisco IOS gateways, these values are part of session group groupn...).

b. If the call-agent-tsap-addr, or the mgw-tsap-addr are DNS names, does nslookup on both Call Agents resolve the values to one unique IP address?

c. Can the call-agent-tsap-addr in the four entries be pinged from the media gateway? Do the Call Agents actually have the IP addresses, or DNS names, specified?

d. Can the mgw-tsap-addr be pinged from both Call Agents?

e. Does the isdn-dchan-profile exist (show isdn-dchan-profile id=%)? Keep in mind that the profile id is case sensitive.

f. Snoop can be used to see if the gateway and Call Agent are talking in order to establish the session. Snoop can be used to eliminate the question of whether the problem is on the Call Agent or the media gateway side.

g. The show backhaul session all command on the media gateway can be useful in debugging.

h. Look at the trace.log on the Call Agent. Search for BSM_create_ss or bsm_create_ss. This shows the exact values used by the Call Agent.

Note Backhaul deletion is triggered by all D Channels of a backhaul-set being in the admin-OOS state. Backhaul creation is triggered by controlling one of the trunk groups to INS. Determine the D Channel list using the show isdn-dchan set-id command.

Step 3 D Channel states for FAS: "ISDN D Channel restore establish fail normal or switchover" or NFAS: "ISDN D Channel sent Establish Request".

This means the specific ISDN D Channel could not be restored. This is likely related to ISDN layer1 or layer2 not being up, or it is related to DCHAN-SLOT and DCHAN-PORT in the ISDN D Channel table. The media gateway and Call Agent are communicating successfully (session came up).

Things to Check:

a. On the media gateway, enter a show isdn status command. Is layer 1 shown as ACTIVE? If not, there may be a cable problem, or the PBX is down.

b. Does the show isdn status command return a "Network side configuration"? The PBX should be set up for the user side. The gateway should be set up for the network side.

c. Was the media gateway reloaded (rebooted) after setting up the parameters? There can be problems when this has not been done. This is usually reflected by having two TEI values for the T1.

d. Are the DCHAN-SLOT and DCHAN-PORT provisioned correctly in the IDSN D Channel table?

e. Does the T1 on the media gateway show an alarm (red or yellow lights)? These are more clues that there is an ISDN layer1 or layer2 problem.

f. Is the controller T1, or interface Serialn:23, provisioned correctly on the gateway?

g. Look at the trace.log on the Call Agent. Search for BSM_dchan_tbl_insert or bsm_dchan_tbl_insert. The slot-port value is the actual value retrieved from the database. For the AS5300, this value should be 0, 1, 2, or 3. This is a decimal value. The top 16 bits are the slot and the bottom 16 bits are the port.

Step 4 D Channel states for NFAS: "ISDN D Channel is in Wait for Service Ack or ISDN D Channel is Maintenance Busy".

This means the states at the far end are going to send a SERVICE_ACK to the Cisco BTS 10200 Softswitch service message for PRI.

Things to Check:

Make sure the far end is sending a SERVICE_ACK. There are some other D Channel states that happen after the ISDN backhaul is successfully established.

Step 5 Trunk group states for FAS: "ISDN D Channel down session set fail hard normal" or NFAS: "ISDN D Channel is Backhaul Session Down".

As seen in the "ISDN D Channel restore session set fail normal or ISDN D Channel is Backhaul Session Down" error message, here, the backhaul session was already successfully established, and then went out. This likely means that the Call Agent and media gateway have lost IP connectivity. Or, the media gateway has lost power. This can also happen if the provisioning was changed, particularly the session settings in the media gateway.

Step 6 D Channel states for FAS: "ISDN D Channel down establish fail hard normal" or NFAS: "ISDN D Channel sent Establish Request".

This is the same as ISDN "D Channel restore establish fail normal" or "ISDN D Channel sent Establish Request". However, in this case, the D channel was already successfully established, and then went out.

Things to Check:

a. Was, the cable unplugged between the PBX and the gateway?

b. Was the provisioning changed on the gateway?

Step 7 Trunk group state for FAS: ISDN D Channel delete graceful.

The following command indicates you are waiting for calls to finish before going to out-of-service. If the wait time is too long, you can control the trunk group with mode=forced.

control isdn-dchan id=xxxx; mode=graceful; target-state=oos;dchan-type=<primary | backup>

Checking the Status of a Trunk Termination

Check the status of a trunk termination using the following command:

status trunk-termination tgn-id=<trunk group number>;cic=<cic number>;

Reply : Success:

TGN_ID -> 100

CIC -> 8

RESULT -> ADM configure result in success

REASON -> ADM executed successfully

TERM_ADMIN_STATE -> ADMIN_INS

TERM_OPER_STATE -> Term is available for new calls

TERM_REASON -> No fault reason available

TRUNK_STATIC_STATE -> ACTV

TRUNK_DYNAMIC_STATE -> IDLE

TRUNK_REASON -> NON_FAULTY

Reply : Success: at 2007-01-03 15:41:32 by btsadmin

Entry 1 of 1 returned.

The above status shows that the trunk is active, in idle mode, and ready for call use.

If the trunk static state is set to locally blocked, go to the "Trunk Static State Is Set to Locally Blocked" section.

If the trunk static state is set to TRNS, go to the "Trunk Static State Is Set to TRNS" section.

If the trunk static state is set to remotely blocked, go to the "Trunk Static State Is Set to RBLK" section.

If the trunk static state is set to TERM_STATUS_FAULTY, go to the "Termination Status Is Faulty" section.

If the trunk static state returns Cannot Make Call, go to the "Cannot Make a Call" section.

Trunk Static State Is Set to Locally Blocked

The three Trunk Static State is set to locally blocked (LBLK) stateif the following is true:

Step 1 If the Trunk Reason is set to MAINT-OOS, then a user has manually taken the trunks out of service. The user must manually put the trunks into the in-service mode.

Use the control command on the specified trunk to put the trunk back into the in-service mode.

Clear the MAINT-OOS. Trunks should be in active or idle mode and ready for use.

Step 2 If the Trunk Reason is set to Signalling-fault, then the D channels are not in-service. Check the D Channels ADMIN and OPER states.

•If the D Channel ADMIN state is ADMIN_OOS, use the control command to put the D Channel into in-service mode.

•If the D Channel ADMIN state is ADMIN _INS, verify that the D Channel OPER-STATE is IN-SERVICE (see the "How to Troubleshoot When the ISDN D Channel Fails to be Restored" section in case of any issues).

•Clear any SIGNALLING-FAULT states. Trunks must be in active or idle mode and ready for use.

Step 3 If Trunk Reason is set to TERM_FAULT, then the terminations are in Faulty states. Verify the IP connectivity from the CA to the gateway.

a. Clear any termination faults at the gateway by turning off, then turning on, MGCP (use the mgcp, no mgcp procedure on the media gateway).

b. Clear any TERM_FAULT on the Cisco BTS 10200 Softswitch. Trunks must be in active or idle mode and ready for use.

Trunk Static State Is Set to TRNS

Perform the following steps when the trunk static state is set to TRNS.

Note If the trunk static state is set to TRNS, then the PBX has not responded with a SERVICE_ACK or RESTART_ACK for the service or restart message set by the Call Agent.

Step 1 Verify that the initialization procedure, as depicted by the associated isdn-dchan-profile, and as used by PBX, is synchronized.

Step 2 Verify that the isdn-service-supp token is set to N if PBX does not support service messages.

Trunk Static State Is Set to RBLK

Perform the following steps if trunk static state is set to RBLK.

Note If the trunk static state is set to RBLK, and isdn-dchan-profile has isdn-farend-init=Y, then the PBX must start the initialization procedure, or the PBX specifically sends a service message with SERVICE-OOS mode to the Cisco BTS 10200 Softswitch to put the trunks into the remote out-of-state mode.

Step 1 Verify that the initialization procedure (ISDN-FAREND-INIT token) used by the PBX is in sync, as depicted by associated isdn-dchan-profile in the Cisco BTS 10200 Softswitch.

Step 2 Using the CLI command control trunk-termination to reset the RBLK state, perform a control trunk-termination to OOS, then control trunk-termination to INS—in case there is an error on the PBX side. Also, set the isdn-service-supp token in the ISDN D Channel group profile according to the procedures supported by the PBX.

Termination Status Is Faulty

The "TERM_STATUS_FAULTY" message indicates an MGCP problem.

Things to Check:

•Is the MGW profile set up for the trunk?

•Is the MGW in the in-service operational state?

Perform the "no mgcp, mgcp" commands on the gateway if an MGCP problem is indicated.

Cannot Make a Call

If you have a problem making a call, use the following "Things to Check", and then go to the "Checking MGW Provisioning" section

Note When terminations are added, they have strings like S0/DS1-2/1. The S# refers to the slot number. The DS1-# refers to the port number. The /# at the end refers to the specific B channel (1-23). The slot and port numbers must match the dchan values (dchan-slot, dchan-port) for the related D Channel id (dchan-id), assuming that the DS0 is on a T1 that contains a D channel.

Things to Check:

•Are all Cisco BTS 10200 Softswitch Ethernet cables plugged in and intact?

•Are all gateway Ethernet cables plugged in and intact?

IUA Traces

The existing Cisco BTS 10200 Softswitch trace capability is used to troubleshoot IUA and SCTP. Use the get-trace and set-trace CLI commands to enable and disable various trace details of the IUA/SCTP protocol at run time. Set the IUM process trace levels to INFO5 to enable IUA/SCTP traces.

The Call Agent table has an additional field, IUA-DEBUG-LEVEL, to enable and disable various trace details of the IUA stack using the get-trace and set-trace commands. The IUA-DEBUG-LEVEL can be set to any of the following:

•ERROR (default)—Only error traces

•STATE—State transitions and errors

•PACKET—IUA packets sent or received and errors

•ALL—SCTP signals received from SCTP stack, state transitions, IUA packets sent or received and errors

In the following example, a CLI command enables specific trace details:

set-trace call-agent id=CA146; trace-sctp-api=y; trace-sctp-txrxchunks=y; 
trace-sctp-state=y; trace-sctp-signal=y; trace-sctp-multihome=y; trace-sctp-congestion=y; 
trace-sctp-init=y;

The following example displays the output from the get-trace command:

get-trace call-agent id=CA146

CA ID -> CA146

RESULT -> ADM configure result in success

REASON -> ADM executed successfully

TRACE SCTP API -> Y

TRACE SCTP TXRXCHUNKS -> Y

TRACE SCTP STATE -> Y

TRACE SCTP SIGNAL -> Y

TRACE SCTP MULTIHOME -> Y

TRACE SCTP CONGESTION -> Y

TRACE SCTP INIT -> Y

IUA DEBUG LEVEL -> ERROR

Reply : Success: at 2006-04-10 13:11:59 by btsadmin

Checking MGW Provisioning

This section describes how to check provisioning on IOS and IUA/SCTP gateways.

IOS Gateway

The following example shows how a Cisco IOS gateway is provisioned for ISDN backhauling using RUDP.

Note The typical problem areas are in bold type. Look at the problem area after the Call Agent is provisioned.

Current configuration:

!

================

version 12.2

no service pad

service timestamps debug datetime msec

service timestamps log datetime localtime

no service password-encryption

!

hostname c2421.200

!

enable password xxxxxxx

!

clock timezone CDT -6

network-clock base-rate 56k

network-clock-select 3 T1 0

network-clock-select 1 T1 1

network-clock-select 2 system (SCB)

ip subnet-zero

!

!

ip domain-name ipclab.cisco.com

ip name-server 10.89.224.1

!

ip audit notify log

ip audit po max-events 100

backhaul-session-manager 

  set isdn1 client ft      

  group group1 set isdn1   

  group group2 set isdn1   

  session group group1 10.89.225.223 9000 10.89.227.200 9000 1  

  session group group1 10.89.226.223 9001 10.89.227.200 9001 2  

  session group group2 10.89.225.224 9000 10.89.227.200 9000 1  

  session group group2 10.89.226.224 9001 10.89.227.200 9001 2  

isdn switch-type primary-ni

isdn voice-call-failure 0

!

!

!

!

!

!

!

no voice confirmation-tone

voice-card 0

!

controller T1 0

 framing esf

 linecode b8zs

 channel-group 0 timeslots 1-24 speed 64

!

controller T1 1

 framing esf

 linecode b8zs

 pri-group timeslots 1-24 service mgcp

!

!

!

!

interface Ethernet0

 ip address 10.89.227.200 255.255.255.0

 no cdp enable

!

interface Serial0

 no ip address

 shutdown

!

interface Serial0:0

 no ip address

 ip nat outside

 encapsulation ppp

 shutdown

 no cdp enable

!

interface Serial1:23

 bandwidth 64000

 no ip address

 no logging event link-status

 isdn switch-type primary-ni

 isdn protocol-emulate network    

 isdn incoming-voice voice

 isdn bind-l3 backhaul isdn1 

 no cdp enable

!

ip classless

ip route 0.0.0.0 0.0.0.0 10.89.227.254

no ip http server

ip pim bidir-enable

!

!

access-list 1 permit 10.0.24.0 0.0.0.255

call rsvp-sync

!

voice-port 1:23

!

mgcp

mgcp call-agent mgcp-SYS01CA.ipclab.cisco.com service-type mgcp version 1.0

mgcp dtmf-relay voip codec all mode nte-gw

mgcp package-capability rtp-package

mgcp default-package dt-package

no mgcp timer receive-rtcp

!

mgcp profile default

 timeout tsmax 100

 max2 retries 3

!

dial-peer cor custom

!

!

!

dial-peer voice 1 pots

 application mgcpapp

 port 1:23

!

!

line con 0

line aux 0

line 2 3

line vty 0 4

 password xxxxxxxx

 login

!

ntp server 10.89.227.254

end

IUA/SCTP Gateway

The following example shows how a gateway is provisioned for IUA/SCTP.

Note The typical problem areas are in bold type. Look at the problem area after the Call Agent is provisioned.

Current configuration:

Current configuration : 3734 bytes

!

! No configuration change since last restart

!

version 12.2

service timestamps debug datetime msec

service timestamps log datetime localtime

no service password-encryption

!

hostname c5400-102

!

boot system flash:c5400-is-mz.sc70930

no boot startup-test

logging queue-limit 100

logging buffered 99999 debugging

enable password callagent

!

!

!

resource-pool disable

clock timezone cdt -5

spe default-firmware spe-firmware-1

aaa new-model

!

!

aaa authentication login default group tacacs+ enable

aaa authorization config-commands

aaa authorization exec default group tacacs+ none 

aaa authorization commands 1 default group tacacs+ none 

aaa authorization commands 15 default group tacacs+ none 

aaa accounting exec default start-stop group tacacs+

aaa accounting commands 1 default start-stop group tacacs+

aaa accounting commands 15 default start-stop group tacacs+

aaa session-id common

ip subnet-zero

ip cef

ip domain name ipclab.cisco.com

ip name-server 10.89.224.1

ip name-server 10.89.224.9

!

isdn switch-type primary-ni

isdn voice-call-failure 0

isdn debug 0000043D

!

!

!

!

!

!

!

no voice hpi capture buffer

no voice hpi capture destination 

!

!

!

mta receive maximum-recipients 0

!

iua

  AS as-tb78 10.89.232.102 9900 

   ASP asp-tb78 AS as-tb78  190.101.56.214 190.101.55.214 9900 

   ASP asp-sec-tb78 AS as-tb78  190.101.56.212 190.101.55.212 9900 

!

!

controller T1 6/0

 framing esf

 linecode b8zs

 pri-group timeslots 1-24 service mgcp

!

controller T1 6/1

 framing esf

 linecode b8zs

!

controller T1 6/2

 framing sf

 linecode ami

!

controller T1 6/3

 framing sf

 linecode ami

 pri-group timeslots 1-24 service mgcp

!

controller T1 6/4

 framing sf

 linecode ami

!

controller T1 6/5

 framing sf

 linecode ami

controller T1 6/6

 framing sf

 linecode ami

!

controller T1 6/7

 framing sf

 linecode ami

!

controller T1 7/0

 framing sf

 linecode ami

!

controller T1 7/1

 framing sf

 linecode ami

!

controller T1 7/2

 framing sf

 linecode ami

!

controller T1 7/3

 framing sf

 linecode ami

!

controller T1 7/4

 framing sf

 linecode ami

!

controller T1 7/5

 framing sf

 linecode ami

!

controller T1 7/6

 framing sf

 linecode ami

!

controller T1 7/7

 framing sf

 linecode ami

!

!

interface FastEthernet0/0

 ip address 10.89.232.102 255.255.255.0

 duplex auto

!

interface FastEthernet0/1

 no ip address

 shutdown

 duplex auto

 speed auto

!

interface Serial0/0

 no ip address

 shutdown

 clockrate 2000000

!

interface Serial6/0

 no ip address

 shutdown

!

interface Serial7/0

 no ip address

 shutdown

!

interface Serial0/1

 no ip address

 shutdown

 clockrate 2000000

!

interface Serial6/0:23

 no ip address

 isdn switch-type primary-ni

 isdn protocol-emulate network

 isdn bind-l3 iua-backhaul as-tb78

 no cdp enable

!

interface Serial6/3:23

 no ip address

 isdn switch-type primary-ni

 no cdp enable

!

interface Group-Async0

 no ip address

 group-range 1/00 5/107

!

ip classless

ip route 0.0.0.0 0.0.0.0 10.89.232.254

ip http server

!

!

logging trap debugging

logging 10.89.227.251

!

tacacs-server host 10.89.232.104

tacacs-server timeout 15

tacacs-server directed-request

snmp-server community public RO

snmp-server community private RW

snmp-server system-shutdown

snmp-server enable traps tty

!

radius-server authorization permit missing Service-Type

call rsvp-sync

!

voice-port 6/0:23

!

voice-port 6/3:23

!

mgcp

mgcp call-agent mga-SYS78CA146.ipclab.cisco.com service-type mgcp version 1.0

!

mgcp profile default

!

dial-peer cor custom

!

!

!

!

!

line con 0

line aux 0

line vty 0 4

 exec-timeout 30 0

 password callagent

line 1/00 3/107

 no flush-at-activation

 modem InOut

line 5/00 5/107

 no flush-at-activation

 modem InOut

!

scheduler allocate 10000 400

ntp server 10.89.227.254

end

Additional CLI Verification

Perform the following steps to provide additional CLI verification of a problem:

Step 1 Use the control command to put the trunk group out of service (OOS) and back into service (INS):

Place OOS:

control tgn-id=17; target-state=oos; mode=graceful;

Place INS:

control tgn-id=17; target-state=ins; mode=forced;

Step 2 If the B channel is not IDLE, use the control command to put each circuit OOS and back INS:

Place OOS:

control trunk-termination tgn-id=17; cic=1; target-state=oos; mode=forced;

Place INS:

control trunk-termination tgn-id=17; cic=1; target-state=ins; mode=forced;

Step 3 Check the status of the trunk group:

status trunk-grp id=<TG ID number; call-agent-id=<CA ID;

If the trunk group status has still not changed to ADMIN_INS—even though the commands in Steps 1 and 2 were successful—communication to the MGW has been lost. Notify your system administrator and have the problem corrected before continuing.

Step 4 Check trunk termination and trunk status. The single command shown here queries both the trunk-termination status and trunk (channel) status:

status trunk-termination tgn-id=17; cic=all; 

Reply : Request was successful.

REPLY=1status is ....

CONFIGURATION COMMAND EXECUTED TRUNK_GRP -17 -CIC -1

TERM ADMINstatus -ADMIN_INS

TERM OPERstatus -TERM_STATE_IDLE

CIC STATIC STATE -ACTV

CIC DYNAMIC STATE -IDLE

...

...

23status is ....

CONFIGURATION COMMAND EXECUTED TRUNK_GRP -17 -CIC -23

TERM ADMINstatus -ADMIN_INS

TERM OPERstatus -TERM_STATE_IDLE

CIC STATIC STATE -ACTV

CIC DYNAMIC STATE -IDLE

status trunk-termination tgn-id=17; cic=23

Reply : Request was successful.

REPLY=CONFIGURATION COMMAND EXECUTED ISDN_TRUNK_GROUP -17 -CIC -23

TERM ADMINstatus -ADMIN_INS

TERM OPERstatus -TERM_STATE_IDLE

CIC STATIC STATE -ACTV

CIC DYNAMIC STATE -IDLE

Maintenance of a Call Agent Connected to an ISDN Trunk Group

During system operations, the operator can use the CLI control command to switch the Call Agent into one of three states:

•NORMAL

•FORCED-ACTIVE-STANDBY

•FORCED-STANDBY-ACTIVE

When the control command is entered on a Call Agent connected to an ISDN trunk group (D channel), the Call Agent switchover time is approximately 20 seconds. During all but the first 6 seconds of this switchover time, the ISDN D channel is temporarily down. However, the D channel comes back up, and the ISDN trunk group automatically returns to in-service (INS), when the switchover is complete.

Note This switchover process does not have any impact on stable calls.

ISDN D Channel and Trunk Group CLI Command Troubleshooting

Table 4-3 lists CLI commands for performing common ISDN D Channel and trunk group operations for RUDP and IUA. The table shows how the commands differ from one release to the next, starting with Release 4.5.x through 6.0.x.

Use this table to ensure that you are using the correct command for your release.

Note In Release 4.5.x, the number of maximum BSM/RUDP session is increased from 1500 to 2000 counts.

Due to the increased number of sessions from 1500 to 2000, the recovery time of the sessions will also increase. Ensure that the parameters configured in their ISDN gateway are set and changed correctly. Any changes made to the RUDP message time-out value in the networks gateway can adversely affect the link recovery time, and calls can be lost during a switchover.

The retransmit timer value should be at least 2000 and the maximum retransmission count should be 30. The following example displays the configuration in gateway side:

backhaul-session-manager

  set isdn1 client ft

  group group1 set isdn1

  group group1 timer keepalive 10000

  group group1 timer retransmit 2000 

  group group1 retrans 30

  group group2 set isdn1

  group group2 timer keepalive 10000

  group group2 timer retransmit 2000 

  group group2 retrans 30

Note Cisco BTS 10200 5.0.x and 6.0.x IUA does not support Non Facility Associated Signalling (NFAS).

control sctp-assoc 
id=<isdn1>; 
mode=forced; 
target-state=ins;

control sctp-assoc 
id=<isdn1>; 
mode=forced; 
target-state=ins;

control 
isdn-dchan 
id=<dchan1>; 
dchan-type=pri
mary; 
target-state=i
ns; 
mode=forced;

control isdn-dchan 
id=<dchan1>; 
dchan-type=primary
; 
target-state=ins; 
mode=forced;

control isdn-dchan 
id=<dchan1>; 
dchan-type=primary; 
target-state=ins; 
mode=forced;

control isdn-dchan 
id=<dchan1>; 
dchan-type=primary
; 
target-state=ins; 
mode=forced;

control trunk-grp 
id=<100>; 
target-state=ins; 
mode=forced;

control 
trunk-grp 
id=<100>; 
target-state=i
ns; 
mode=forced;

control trunk-grp 
id=<100>; 
target-state=ins; 
mode=forced;

control trunk-grp 
id=<100>; 
target-state=ins; 
mode=forced;

control trunk-grp 
id=<100>; 
target-state=ins; 
mode=forced;

control 
trunk-grp 
id=<100>; 
target-state=o
os; 
mode=forced;

control trunk-grp 
id=<100>; 
target-state=oos; 
mode=forced;

control trunk-grp 
id=<100>; 
target-state=oos; 
mode=forced;

control trunk-grp 
id=<100>; 
target-state=oos; 
mode=forced;

control isdn-dchan 
tgn-id=<100>;

control 
isdn-dchan  
id=<dchan1>; 
mode=forced; 
target-state=s
witchover;

control isdn-dchan  
id=<dchan1>; 
mode=forced; 
target-state=switch
over;

control 
isdn-dchan  
id=<dchan1>; 
dchan-type=pri
mary; 
mode=forced; 
target-state=o
os;

control isdn-dchan  
id=<dchan1>; 
dchan-type=primary; 
mode=forced; 
target-state=oos;

control 
isdn-dchan 
id=<dchan1>; 
dchan-type=bac
kup; 
mode=forced; 
target-state=o
os;

control isdn-dchan 
id=<dchan1>; 
dchan-type=backup; 
mode=forced; 
target-state=oos;

btsadmin>cont
rol 
isdn_dchan 
id=1000;mode=
FORCED;target
_state=OOS;

Reply : 
Failure: at 
2008-02-28 
06:06:37 by 
btsadmin

Please enter 
DCHAN_TYPE.

control 
isdn-dchan  
id=<dchan1>; 
mode=forced; 
target-state=o
os;

control isdn-dchan  
id=<dchan1>; 
mode=forced; 
target-state=oos;

control isdn-dchan  
id=<dchan1>; 
mode=forced; 
target-state=oos;

control isdn-dchan  
id=<dchan1>; 
mode=forced; 
target-state=oos;

control 
isdn-dchan  
id=<dchan1>; 
dchan-type=pri
mary; 
mode=forced; 
target-state=o
os;

control isdn-dchan  
id=<dchan1>; 
dchan-type=primary
; mode=forced; 
target-state=oos;

control isdn-dchan  
id=<dchan1>; 
dchan-type=primary; 
mode=forced; 
target-state=oos;

control isdn-dchan  
id=<dchan1>; 
dchan-type=primary
; mode=forced; 
target-state=oos;

control sctp-assoc 
id=<isdn1>; 
target-state=oos; 
mode=forced;

—

control sctp-assoc 
id=<isdn1>; 
target-state=oos; 
mode=forced;

Control 
isdn_dchan 
id=<dchan>;dch
an_type=backup
;mode=Forced;t
arget_state=IN
S

—

Control isdn_dchan 
id=<dchan>;dchan_ty
pe=backup;mode=Forc
ed;target_state=INS

—