The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
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.
This section describes the status and control commands for ISDN.
Table Name: ISDN-DCHAN
Table Containment Area: EMS, Call Agent
Status and control
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;
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.
See the Cisco BTS 10200 Softswitch CLI Database for more information on the ISDN D Channel token.
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>
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.
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.
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.
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.
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.
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?
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
This section describes how to check provisioning on IOS and IUA/SCTP gateways.
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
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
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
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.
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 7.0.
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).