Troubleshooting Guide
Appendix A - System Usage of MGW Keepalive Parameters
Downloads: This chapterpdf (PDF - 506.0KB) The complete bookPDF (PDF - 7.16MB) | Feedback

System Usage of MGW Keepalive Parameters, Release 4.4.x

Table Of Contents

System Usage of MGW Keepalive Parameters, Release 4.4.x

Provisionable Parameters

Definitions and Additional Parameters

Examples of Successful MGCP Message Transmissions

Initial AUEP Transmission Successful

Scenarios with Retransmissions

Keepalive Process

Scenario 1—MGW Reachable

Basic Scenario

MGCP Message Sent and Is Unsuccessful

MGCP Message Sent and Is Successful

Scenario 2 (Special Case)—Reachable RGW with 16 or Fewer Endpoints and No Stable Calls In Progress

Basic Scenario

MGCP Message Sent and Is Unsuccessful

MGCP Message Sent and Is Successful

Scenario 3—MGW Unreachable

Release 4.4.0—KA Attempts Unsuccessful, MGW Unreachable

Releases 4.4.1 and Later—KA Attempts Unsuccessful, MGW Unreachable

Releases 4.4.1 and Later—MGW Unreachable, New Call Termination Attempt Occurs


System Usage of MGW Keepalive Parameters, Release 4.4.x


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

This appendix explains how the Cisco BTS 10200 Softswitch determines the connectivity status between itself and a media gateway (MGW). The Cisco BTS 10200 Softswitch executes a keepalive (KA) process that includes the transmission of audit-endpoint (AUEP) messages to MGCP, TGCP, and NCS based MGWs.

This appendix also describes a special set of provisionable parameters that you can adjust if there are network bandwidth or reliability issues, or if a MGW is slow in responding to commands from the Call Agent.

Provisionable Parameters

The following tokens are involved in KA process:

In the mgw-profile table:

keepalive-method (default = AUEP)

mgcp-keepalive-retries (default = 3)

mgcp-max1-retries (default = 2)

mgcp-max2-retries (default = 3)

mgcp-keepalive-interval (default = 60 seconds)

mgcp-t-tran (default = 400 milliseconds)

In the call-agent table:

mgw-monitoring-enabled (default=Y)

The system behavior described in this document assumes that all of the tokens in the above list are set to their default values. This has the following effect:

Enabling the KA process—Using the default values of mgw-monitoring-enabled (Y) and keepalive-method (AUEP) enables the sending of AUEP messages from the Cisco BTS 10200 Softswitch to the MGW.


Note We recommend that you keep these tokens set to their default values (which enables the KA process) unless you have some other method of determining MGW connectivity status.


Tuning the KA process—The other mgw-profile tokens in the above list have numerical values, and the default values typically work well for most systems. The interaction among these tokens is described in this document. We do not recommend that you modify these values unless you experience problems with bandwidth, reliability, or response times in your network.


Caution Before modifying any of these numerical values (using values different than the factory default settings), thoroughly read and understand the contents of this document. If you have questions, contact your Cisco account team or Cisco TAC.

Definitions and Additional Parameters

This section defines some of the terms used to describe the KA process.

KA procedure—A series of transmissions and retransmissions of AUEP messages used to determine the MGCP connectivity status between the Cisco BTS 10200 Softswitch and the MGW. If there is a loss of connectivity, the Cisco BTS 10200 Softswitch retries the series of AUEP transmissions up to a specified number of retries before declaring the MGW to be in down status.

KA attempt—The transmission of an AUEP message, with a defined number of retransmissions of the same AUEP message, until an ACK message is received or the defined number of retransmissions has been reached. This can include retransmissions to additional IP addresses if provisioned to do so. A KA attempt is defined as successful if an ACK is received from the MGW, and failed if no ACK is received after the defined number of AUEP retransmissions. A KA attempt is also called an AUEP transaction.

KA retries—Subsequent KA attempts, sent only if the initial KA attempt fails.

MGW in working status—A KA attempt to this MGW is successful (an ACK is received).

MGW in down status—After a defined number of KA retry failures, the Cisco BTS 10200 Softswitch declares this MGW to be in down status, and continues to perform the KA procedure.


Note To learn more about the MGW operational states reported by the Cisco BTS 10200 Softswitch, see the MGW Status Command in the Cisco BTS 10200 Softswitch Operations and Maintenance Guide.


The following parameters are also related to MGW connection status, but are not discussed in detail in this appendix. For additional details, see the Cisco BTS 10200 Softswitch Command Line Reference Guide.

Long transaction—The mgcp-t-longtran field in the mgw-profile table specifies the initial MGCP transaction timeout (in seconds) after receiving a provisional response (return code 100) from the MGW. The range is 1-10 (default = 5).

Return code action—The endpoint action (ep-action) field in the Media Gateway Control Protocol Return Code Action (mgcp-retcode-action) table specifies what action to take when an MGCP message is received from an MGW.

Examples of Successful MGCP Message Transmissions

This section illustrates several scenarios with successful MGCP message transmissions.


Note This section describes how the system sends AUEP messages. This discussion can be applied to the sending of any MGCP messages (including AUEP).


Initial AUEP Transmission Successful

Figure A-1 illustrates the basic scenario in which the initial AUEP transmission is successful, that is, the Cisco BTS 10200 Softswitch receives an acknowledgement (ACK) message before the designated time, t, has elapsed.

The period, t, is defined as a time period equal to the greater of the following:

Average response time between the sending of an MGCP message, and receiving a response.

A specified lower limit, provisioned as mgcp-t-tran (default 400 milliseconds) in the mgw-profile table.


Note The drawings in this section are not to scale.


Figure A-1 Initial AUEP Successful

Scenarios with Retransmissions

Figure A-2 and Figure A-3 show scenarios in which a message transmission is successful (receives an ACK response) after one or more retries (retransmissions). You can adjust the parameters mgcp-max1-retries and mgcp-max2-retries, if necessary, to improve response if there are network bandwidth or reliability issues, or if a MGW is slow in responding to commands from the Call Agent. These parameters are defined as follows:

mgcp-max1-retries = Number of AUEP retransmissions sent to a single IP address before selecting the next IP address for this MGW listed in the DNS server (default=2).

mgcp-max2-retries = Number of AUEP retransmissions sent to the last IP address for this MGW listed in the DNS server (default=3).

The Cisco BTS 10200 Softswitch processes inbound calls for a MGW as follows, based on the values of mgcp-max1-retries and mgcp-max2-retries:

If an inbound call for a MGW has not received an ACK and is within mgcp-max1-retries or mgcp-max2-retries, the system holds the command to the specific MGW in the command sequencer until one of the following occurs:

A positive response is received from the MGW. The system sends the next message that was held.

A negative response is received from the MGW. The system takes the recovery action specified in the ep-action field of the applicable Media Gateway Control Protocol Return Code Action (mgcp-retcode-action) table.

The mgcp-max2-retries are completed without an ACK received. Held messages are deleted.

If an inbound call for a MGW has not received an ACK and is beyond mgcp-max2-retries, the system takes the following action, depending upon the specific software release:

In Release 4.4.0—The system declares the termination to be unreachable (TERM_UNREACH) and expedites the MGW KA process (as described in the "Keepalive Process" section.)

In Release 4.4.1 and later—The system expedites the KA process (as described in the "Keepalive Process" section) without immediately declaring the termination to be unreachable. However, if the KA process also fails, the system declares the MGW and all associated terminations to be unreachable.

All releases—If the system declares the termination to be unreachable, it attempts to forward the call to voice mail if provisioned. If the system attempts to terminate the call on an unreachable termination, the calling party hears an announcement; however, if an announcement is not provisioned, the caller hears a reorder tone.

Figure A-2 is applicable when a single IP address is provisioned for the MGW in the DNS server. It illustrates the scenario in which the initial AUEP transmission does not receive an ACK message, but an ACK is received in response to retries (retransmissions).

Figure A-2 Single IP Address in DNS, ACK Received after Retries

Figure A-3 is applicable when two IP addresses are provisioned for the MGW in the DNS server. It illustrates the scenario in which the initial AUEP transmission does not receive an ACK message, but an ACK is received in response to retries (retransmissions).

Figure A-3 Two IP Addresses in DNS, ACK Received after Retries


Note The system attempts up to four different IP addresses for any single MGW listed in the DNS server. (This maximum number of IP addresses is not provisionable.)


Keepalive Process

This section describes the keepalive (KA) process. The Cisco BTS 10200 Softswitch performs KA attempts to determine whether a MGW should be considered to be in working status or down status.

There are three KA scenarios covered in this section:

Scenario 1—MGW Reachable

Scenario 2 (Special Case)—Reachable RGW with 16 or Fewer Endpoints and No Stable Calls In Progress

Scenario 3—MGW Unreachable


Note The following sections refer to two types of MGWs, residential gateways (RGWs) and trunking gateways (TGWs). A MGW is identified as either a RGW or TGW according to the provisioning of the type token in the mgw table (type=rgw or type=tgw).


Scenario 1—MGW Reachable

This scenario applies to the following types of MGWs (when the MGWs are reachable):

Trunking gateways (TGWs), with or without stable calls in progress

Residential gateways (RGWs) with more than 16 endpoints, with or without stable calls in progress

RGWs with 16 or fewer endpoints and with stable call(s) in progress

Three variations of this scenario are described in this section:

Basic Scenario

MGCP Message Sent and Is Unsuccessful

MGCP Message Sent and Is Successful

Basic Scenario

The basic scenario is shown in Figure A-4. The MGW is reachable (an ACK is received during each KA attempt) and has stable calls, but no MGCP messages have been exchanged between the Cisco BTS 10200 Softswitch and the MGW for a time interval equal to the provisioned value of mgcp-keepalive-interval (default 60 seconds) in the mgw-profile table.

Figure A-4 KA Attempts—MGW Reachable with Stable Calls


Note For detailed examples of successful KA attempts, see Figure A-1 through Figure A-3.


The system takes the following actions in the scenario shown in Figure A-4:

If KA attempts are successful, and stable calls exist: The system continues this pattern of KA attempts (Scenario 1—MGW Reachable).

For RGWs with 16 or fewer endpoints—If KA attempts are successful, and no stable calls exist: The system implements the KA pattern shown in Scenario 2. (See Scenario 2 (Special Case)—Reachable RGW with 16 or Fewer Endpoints and No Stable Calls In Progress.)


Note For TGWs and RGWs with more than 16 endpoints—If a KA attempt is successful, the system continues to implement Scenario 1 regardless of whether there are stable calls or not.


If a KA attempt is unsuccessful: The system implements the KA pattern shown in Scenario 3. (See Scenario 3—MGW Unreachable.)

MGCP Message Sent and Is Unsuccessful

If the Cisco BTS 10200 Softswitch sends an MGCP message to the MGW, and the message is unsuccessful (no ACK received), the KA process is expedited even though the next KA attempt is scheduled for a later time. This condition is shown in Figure A-5.

Figure A-5 MGW Reachable with Stable Calls, and MGCP Message Unsuccessful

MGCP Message Sent and Is Successful

If the Cisco BTS 10200 Softswitch sends an MGCP message to the MGW, and the message is successful (an ACK is received), the system restarts the keepalive timer. This condition is shown in Figure A-6.

Figure A-6 MGW Reachable with Stable Calls, and MGCP Message Successful

Scenario 2 (Special Case)—Reachable RGW with 16 or Fewer Endpoints and No Stable Calls In Progress

This scenario is applicable to RGWs with 16 or fewer endpoints, but not to TGWs or RGWs with more than 16 endpoints. (The Cisco BTS 10200 Softswitch always uses Scenario 1—MGW Reachable procedures for reachable TGWs and reachable RGWs with more than 16 endpoints, regardless of whether there are stable calls or not.)

Three variations of this scenario are described in this section:

Basic Scenario

MGCP Message Sent and Is Unsuccessful

MGCP Message Sent and Is Successful

Basic Scenario

The basic scenario is shown in Figure A-7. The MGW is reachable (an ACK is received during each KA attempt) and has no stable calls, and no MGCP messages have been exchanged between the Cisco BTS 10200 Softswitch and the MGW for a time interval equal to the provisioned value of mgcp-keepalive-interval (default 60 seconds) in the mgw-profile table.

Figure A-7 KA Attempts—MGW Reachable with No Stable Calls


Note For detailed examples of successful KA attempts, see Figure A-1 through Figure A-3.


The system takes the following actions in the scenario shown in Figure A-7:

If KA attempts are successful, and stable calls exist: The system implements the KA pattern shown in Scenario 1. (See Scenario 1—MGW Reachable.)

If KA attempts are successful, and no stable calls exist: The system continues this pattern of KA attempts (Scenario 2 (Special Case)—Reachable RGW with 16 or Fewer Endpoints and No Stable Calls In Progress).

If a KA attempt is unsuccessful: The system implements the KA pattern shown in Scenario 3. (See Scenario 3—MGW Unreachable.)

MGCP Message Sent and Is Unsuccessful

If the Cisco BTS 10200 Softswitch sends an MGCP message to the MGW, and the message is unsuccessful (no ACK received), the KA process is expedited even though the next KA attempt is scheduled for a later time. This condition is shown in Figure A-8.

Figure A-8 MGW Reachable with No Stable Calls, and MGCP Message Unsuccessful

MGCP Message Sent and Is Successful

If the Cisco BTS 10200 Softswitch sends an MGCP message to the MGW, and the message is successful (an ACK is received), the system restarts the keepalive timer. This condition is shown in Figure A-9.

Figure A-9 MGW Reachable with No Stable Calls, and MGCP Message Successful

Scenario 3—MGW Unreachable

This scenario applies to residential gateways (RGWs) and trunking gateways (TGWs). Separate descriptions are provided for the following software releases:

Release 4.4.0—KA Attempts Unsuccessful, MGW Unreachable

Releases 4.4.1 and Later—KA Attempts Unsuccessful, MGW Unreachable

Releases 4.4.1 and Later—MGW Unreachable, New Call Termination Attempt Occurs

Release 4.4.0—KA Attempts Unsuccessful, MGW Unreachable

If no ACK is received during any KA attempt, and no MGCP messages have been exchanged between the Cisco BTS 10200 Softswitch and the MGW for a specified time interval (see the time interval description in the drawing), the system performs a specified number of KA retries before declaring the MGW to be unreachable. This condition is shown in Figure A-10.

Figure A-10 Release 4.4.0—KA Attempts Unsuccessful, MGW Unreachable


Note For detailed examples of successful KA attempts, see Figure A-1 through Figure A-3.


The system takes the following actions in the scenario shown in Figure A-10:

If KA attempts are successful, and stable calls exist: The system implements the KA pattern shown in Scenario 1. (See Scenario 1—MGW Reachable.)

For RGWs with 16 or fewer endpoints—If KA attempts are successful, and no stable calls exist: The system implements the KA pattern shown in Scenario 2. (See Scenario 2 (Special Case)—Reachable RGW with 16 or Fewer Endpoints and No Stable Calls In Progress.)


Note For TGWs and RGWs with more than 16 endpoints—If a KA attempt is successful, the system implements Scenario 1—MGW Reachable regardless of whether there are stable calls or not.


If a KA attempt is unsuccessful (Release 4.4.0): The system raises one or more alarms and continues this pattern of KA attempts (Scenario 3—MGW Unreachable). The system releases any active calls on this MGW. Typical alarms for this condition include:

SIGNALING (36)—Trunk locally blocked (applicable to CAS, ISDN, and SS7 trunks)

SIGNALING (68)—Media Gateway endpoints are out of service at GW

SIGNALING (79)—Media Gateway unreachable

If all KA attempts are unsuccessful through mgcp-keepalive-retries, the system declares the MGW unreachable.

Releases 4.4.1 and Later—KA Attempts Unsuccessful, MGW Unreachable

If no ACK is received during any KA attempt, and no MGCP messages have been exchanged between the Cisco BTS 10200 Softswitch and the MGW for a specified time interval (see the time interval description in the drawing), the system performs a specified number of KA retries before declaring the MGW to be unreachable. This condition is shown in Figure A-11.

Figure A-11 Release 4.4.1 Later—KA Attempts Unsuccessful, MGW Unreachable


Note For detailed examples of successful KA attempts, see Figure A-1 through Figure A-3.


The system takes the following actions in the scenario shown in Figure A-11:

If KA attempts are successful, and stable calls exist: The system implements the KA pattern shown in Scenario 1. (See Scenario 1—MGW Reachable.)

For RGWs with 16 or fewer endpoints—If KA attempts are successful, and no stable calls exist: The system implements the KA pattern shown in Scenario 2. (See Scenario 2 (Special Case)—Reachable RGW with 16 or Fewer Endpoints and No Stable Calls In Progress.)


Note For TGWs and RGWs with more than 16 endpoints—If a KA attempt is successful, the system implements Scenario 1—MGW Reachable regardless of whether there are stable calls or not.


If a KA attempt is unsuccessful (Release 4.4.1): The system raises one or more alarms and continues this pattern of KA attempts (Scenario 3—MGW Unreachable). The system does not release any active calls on this MGW. Typical alarms for this condition include:

SIGNALING (36)—Trunk locally blocked (applicable to CAS, ISDN, and SS7 trunks)

SIGNALING (68)—Media Gateway endpoints are out of service at GW

SIGNALING (79)—Media Gateway unreachable

If all KA attempts are unsuccessful through mgcp-keepalive-retries, the system declares the MGW unreachable.

Figure A-12 shows an additional example of this condition. In this case the mgcp-keepalive-retries token (default = 3) has been provisioned as 6.

Figure A-12 Release 4.4.1 and Later—KA Attempts Unsuccessful, MGW Unreachable
(Illustrative Example with mgcp-keepalive-retries Provisioned as 6)

Releases 4.4.1 and Later—MGW Unreachable, New Call Termination Attempt Occurs

If the MGW is in down status, and a new call termination attempt is made on any termination on that MGW, the KA process is expedited even though the next keepalive attempt is scheduled for a later time. If the MGW is still in down status, the KA attempts continue. This condition is shown in Figure A-13.


Note In this case, the Cisco BTS 10200 Softswitch fails the call immediately after receiving the call termination attempt, without sending any MGCP message to the MGW.


Figure A-13 Release 4.4.1 and Later—MGW Unreachable, New Call Termination Attempt Occurs