Introduction
This document provides a case study on how the Media Gateway Control Protocol (MGCP) ReStart In Progress (RSIP) message works for the Cisco PGW 2200 Softswitch in Call Control mode.
Prerequisites
Requirements
Readers of this document should have knowledge of these topics:
The following abbreviations, acronyms, and terms are used in this document:
-
CGB—Circuit Group Block (Message)
-
CGBA—Circuit Group Block Acknowledge (Message)
-
CGU—Circuit Group Unblock (Message)
-
CGUA—Circuit Group Unblock Acknowledge (Message)
-
CIC—Circuit Identification Code
-
PSTN—Public Switched Telephone Network
Components Used
The information in this document is based on the Cisco PGW 2200 Softswitch.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Conventions
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
Cisco PGW 2200 MGCP RSIP Problem
This document describes the working of the MGCP RSIP message used on the Media Gateway Controller (MGC) software for the Cisco PGW 2200 in Call Control mode.
The description of this document is part of RFC 2705 MGCP Version 0.1 – RSIP message (Cisco PGW 2200 release 9.2[2] to 9.3[2]).
When the Cisco PGW 2200 receives the RSIP message, it sends a 200 return code to acknowledge the gateway.
-
Forced Shutdown: The Cisco PGW 2200 blocks all the circuits for call setup and terminates the existing connections.
-
Graceful Shutdown: The Cisco PGW 2200 blocks idle circuits and waits for the exiting connections to be terminated.
-
Restart: The Cisco PGW 2200 unblocks all the circuits for call setup.
Example (sniffer trace):
IP address 10.48.84.20 = The Cisco PGW2200—IP address 10.48.84.189
= The Cisco NAS SS7 Point Code 1-010-1 = The Cisco PGW2200—SS7 Point Code
1-004-1 = SS7 STP [PSTN]
17:40:10.495444 10.48.84.189:2427 10.48.84.20:2427 MGCP...... -> RSIP 5 S0/DS1-0/*@V5300-4.cisco.com MGCP 0.1
RM: graceful
RD: 0
This brings the controller of the network access server (NAS) into "shutdown" mode, which results in an RSIP message being sent to the Cisco PGW 2200 with a graceful shutdown.
17:40:10.495763 10.48.84.20:2427 10.48.84.189:2427 MGCP...... -> 200 5
RSIP message has been acknowledged by a 200 message from the Cisco PGW 2200 to the NAS.
17:40:10.722502 1-004-1[02081] 1-010-1[02129] ITU ISUP. -> CGB (18) CIC=00001
SLS=01 Pr:0 Ni:NTL
The Cisco PGW 2200 also blocks the Signaling System 7 (SS7) circuits.
17:40:10.819932 1-010-1[02129] 1-004-1[02081] ITU ISUP. -> CGBA(1a) CIC=00001
SLS=01 Pr:0 Ni:NTL
17:40:14.420686 1-010-1[02129] 1-004-1[02081] ITU ISUP. -> CGB (18) CIC=00001
SLS=01 Pr:0 Ni:NTL
17:40:14.433572 1-004-1[02081] 1-010-1[02129] ITU ISUP. -> CGBA(1a) CIC=00001
SLS=01 Pr:0 Ni:NTL
17:40:33.576082 10.48.84.189:2427 10.48.84.20:2427 MGCP...... -> RSIP 6 S0/DS1-0/*@V5300-4.cisco.com MGCP 0.1
RM: restart
RD: 1
This brings the controller of the NAS into "no shutdown" mode, which results in an RSIP message being sent to the Cisco PGW 2200 with a "restart" message.
17:40:33.576373 10.48.84.20:2427 10.48.84.189:2427 MGCP...... -> 200 6
RSIP message has been acknowledged by a 200 message from the Cisco PGW 2200 to the NAS
17:40:33.802731 1-004-1[02081] 1-010-1[02129] ITU ISUP. -> CGU (19) CIC=00001
SLS=01 Pr:0 Ni:NTL
The Cisco PGW 2200 also blocks the SS7 circuits.
17:40:33.901392 1-010-1[02129] 1-004-1[02081] ITU ISUP. -> CGUA(1b) CIC=00001
SLS=01 Pr:0 Ni:NTL
17:40:39.662585 1-010-1[02129] 1-004-1[02081] ITU ISUP. -> CGU (19) CIC=00001
SLS=01 Pr:0 Ni:NTL
17:40:39.682974 1-004-1[02081] 1-010-1[02129] ITU ISUP. -> CGUA(1b) CIC=00001
SLS=01 Pr:0 Ni:NTL
You can check the status of the Cisco PGW 2200 at the same time by issuing the Man-Machine Language (MML) command rtrv-tc:all when the controller is in shutdown mode. In this case, the status is set on the Cisco PGW 2200 into GW_STAT=INTERFACE_DISABLED,BLK=GATEWAY & REMAUTO".
PGW2200 mml> rtrv-tc:all
Retrieving results. This could take a few moments...
MGC-01 - Media Gateway Controller 2004-01-30 18:33:21.128 GMT
M RTRV
"ss7path:CIC=1,"
"ss7path:PST=IS,CALL=IDLE,GW_STAT=INTERFACE_DISABLED,BLK=GATEWAY & REMAUTO"
"ss7path:CIC=2,"
"ss7path:PST=IS,CALL=IDLE,GW_STAT=INTERFACE_DISABLED,BLK=GATEWAY & REMAUTO"
"ss7path:CIC=3,"
"ss7path:PST=IS,CALL=IDLE,GW_STAT=INTERFACE_DISABLED,BLK=GATEWAY & REMAUTO"
"ss7path:CIC=4,"
"ss7path:PST=IS,CALL=IDLE,GW_STAT=INTERFACE_DISABLED,BLK=GATEWAY & REMAUTO"
"ss7path:CIC=5,"
"ss7path:PST=IS,CALL=IDLE,GW_STAT=INTERFACE_DISABLED,BLK=GATEWAY & REMAUTO"
"ss7path:CIC=6,"
"ss7path:PST=IS,CALL=IDLE,GW_STAT=INTERFACE_DISABLED,BLK=GATEWAY & REMAUTO"
"ss7path:CIC=7,"
"ss7path:PST=IS,CALL=IDLE,GW_STAT=INTERFACE_DISABLED,BLK=GATEWAY & REMAUTO"
"ss7path:CIC=8,"
"ss7path:PST=IS,CALL=IDLE,GW_STAT=INTERFACE_DISABLED,BLK=GATEWAY & REMAUTO"
"ss7path:CIC=9,"
"ss7path:PST=IS,CALL=IDLE,GW_STAT=INTERFACE_DISABLED,BLK=GATEWAY & REMAUTO"
!--- Output suppressed.
Note: If the status is "GW_STAT=INTERFACE_DISABLED,BLK=GATEWAY," consider this information:
When dynamically adding CICs, the default state is INTERFACE_DISABLED. Then the audit is started for the added SS7 CICs. When you receive a positive audit response, the INTERFACE_DISABLED is cleared.
Also take note of the fact that GW_STAT=INTERFACE_DISABLED, in addition to BLK=GATEWAY, gives you an indication that the Cisco PGW 2200 received RSIP (RM:forced) or RSIP (RM:graceful) from the gateway. This state is cleared when the Cisco PGW 2200 receives RSIP (RM:restart) from the gateway.
If the SS7 CICs stayed in the INTERFACE_DISABLED state, issue the debug mgcp packet command on the gateway to gain a good understanding of this error message. This can be linked when receiving a gateway return code 500 (UNKNOWN_ENDPOINT) to the audit endpoint (AUEP) message, which stays in this status. Check the status on the file bearChanSwitched.dat, located in the /opt/CiscoMGC/etc directory, and be sure that the endpoint naming convention notification is the same as on the gateway. Do not make any modifications to the .dat files, but use the Man-Machine Lanuage (MML) commands for this change.
This is an example:
s7/ds1-0/1@v5400-1.cisco.com
For Cisco AS5400 with CT1/CE1/PRI (TGW)
Sx/DS1-y/z@host.dom.com
x = 0 - 7,
y = 0 - 7,
z = T1:1-24 or E1: 1 - 31
For Cisco AS5400 with CT3 (TGW)
S0/DS1-x/y@host.dom.com
x = 1 - 28,
y = 1 - 24
The correct working status looks like this:
PGW2200 mml> rtrv-tc:all
Retrieving results. This could take a few moments...
MGC-01 - Media Gateway Controller 2004-01-30 18:37:57.972 GMT
M RTRV
"ss7path:CIC=1,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
"ss7path:CIC=2,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
"ss7path:CIC=3,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
"ss7path:CIC=4,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
"ss7path:CIC=5,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
"ss7path:CIC=6,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
"ss7path:CIC=7,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
"ss7path:CIC=8,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
"ss7path:CIC=9,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
"ss7path:CIC=10,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
"ss7path:CIC=11,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
"ss7path:CIC=12,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
"ss7path:CIC=13,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
"ss7path:CIC=14,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
"ss7path:CIC=15,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
"ss7path:CIC=16,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
"ss7path:CIC=17,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
"ss7path:CIC=18,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
!--- Press SPACE for next page, Enter for next line, or q to quit this output.
!--- Output suppressed.
For the Call Control concept of the Cisco PGW 2200, you may encounter problems if you do not use a Domain Name System (DNS) server and want to configure the no ip domain-lookup command. You may also encounter problems when issuing the Cisco IOS Software command ip host ip1 ip2 command. In this case, you must attend to the problem, because in some scenarios the MGCP RSIP message cannot be sent out to the secondary IP host address due to the default settings of the Cisco IOS Software MGCP timers. To change this behavior, you must change a timer.
Default MGCP settings:
# show mgcp profile
MGCP Profile default
Description: None
Call-agent: mgc-bru-20 2427 Initial protocol service is MGCP 0.1
Tsmax timeout is 20 sec, Tdinit timeout is 15 sec
Tdmin timeout is 15 sec, Tdmax timeout is 600 sec
Tcrit timeout is 4 sec, Tpar timeout is 16 sec
Thist timeout is 30 sec, MWI timeout is 16 sec
Ringback tone timeout is 180 sec, Ringback tone on connection timeout is 180 sec
Network congestion tone timeout is 180 sec, Busy tone timeout is 30 sec
Dial tone timeout is 16 sec, Stutter dial tone timeout is 16 sec
Ringing tone timeout is 180 sec, Distinctive ringing tone timeout is 180 sec
Continuity1 tone timeout is 3 sec, Continuity2 tone timeout is 3 sec
Reorder tone timeout is 30 sec, Persistent package is ms-package
Max1 DNS lookup: DISABLED, Max1 retries is 5
Max2 DNS lookup: ENABLED, Max2 retries is 7
Source Interface: NONE
T3 endpoint naming convention is T1
#
The cause of this situation is that with the default settings of tsmax (20 seconds), max1 retries (5), and max2 retries (7), the tsmax time is exceeded before the gateway has a chance to try the secondary host address from the ip host ip1 ip2 command to retransmit the RSIPs. In this case, if you want to resend the RSIPs to the second Cisco PGW 2200 host address, set the value of tsmax higher to allow the gateway to try max1 retries with the first Cisco PGW 2200 address. This way, it still has time to get to the max2 retries for the second Cisco PGW 2200 address. (The algorithm is defined in section 4.2 of RFC 2705 .) For this reason, setting tsmax to 100 seconds is recommended.
The following configuration change modifies the value tsmax:
# conf term
V5300(config)# mgcp profile default
V5300(config-mgcp-profile)# timeout tsmax 100
Another reason the gateway tries to send to the first IP address for a second round of tries before failing over to the second IP address is because of a forced DNS lookup (which looks at "ip host ..." if no ip domain-lookup is configured). This is due to exceeding the number of max1 retries. When this happens, the first IP address is returned and used again. To avoid this behavior, configure no max1 lookup in the MGCP profile.
The following configuration change modifies the value no max1 lookup:
# conf term
V5300(config)# mgcp profile default
V5300(config-mgcp-profile)# no max1 lookup
This causes the Cisco IOS Software code to skip the force of the DNS lookup. The DNS lookup is on by default.
Note: You must reload the router for the no max1 lookup configuration change under the MGCP profile to take effect.
# show mgcp profile
MGCP Profile default
Description: None
Call-agent: mgc-bru-20 2427 Initial protocol service is MGCP 0.1
Tsmax timeout is 100 sec, Tdinit timeout is 15 sec
Tdmin timeout is 15 sec, Tdmax timeout is 600 sec
Tcrit timeout is 4 sec, Tpar timeout is 16 sec
Thist timeout is 30 sec, MWI timeout is 16 sec
Ringback tone timeout is 180 sec, Ringback tone on connection timeout is 180 sec
Network congestion tone timeout is 180 sec, Busy tone timeout is 30 sec
Dial tone timeout is 16 sec, Stutter dial tone timeout is 16 sec
Ringing tone timeout is 180 sec, Distinctive ringing tone timeout is 180 sec
Continuity1 tone timeout is 3 sec, Continuity2 tone timeout is 3 sec
Reorder tone timeout is 30 sec, Persistent package is ms-package
Max1 DNS lookup: DISABLED, Max1 retries is 5
Max2 DNS lookup: ENABLED, Max2 retries is 7
Source Interface: NONE
T3 endpoint naming convention is T1
#
If you continue to encounter MGCP RSIP problems, issue the debug mgcp packet command on the gateway. If you have a low CPU load, issue the debug mgcp parser command as well. The output of this command shows exactly what steps the Cisco IOS Software is taking to do a DNS lookup or to issue the ip host ip address command for sending the RSIP message out.
Related Information