Guest

Cisco Signaling Controllers

PGW 2200 Softswitch Error Resolution for MGCP Hung Calls

Document ID: 50501

Updated: Feb 02, 2006

   Print

Introduction

This document explains the items linked to hung calls on the gateway for the Call Control Cisco PGW 2200 Softswitch solution, in combination with a scenario to help you troubleshoot. Currently, the Cisco IOS® gateway does not have the ability to correlate the service processing element (SPE) (which is explained in the document Understanding NextPort SPE Versions) with a digital service zero (DS0) and a Media Gateway Control Protocol (MGCP) connection. Without Cisco IOS debugs, it is not possible to map a DS0 to a digital signal processor (DSP) with the Cisco IOS command show tdm mapping for MGCP-based call types. Cisco bug ID CSCdz47711 (registered customers only) is introduced to fix this situation for the AS5350, AS5400, and AS5850 Cisco IOS gateways.

Prerequisites

Requirements

Readers of this document should have knowledge of these topics:

Components Used

The information in this document is based on these software and hardware versions:

  • Cisco PGW 2200 software releases 9.3(2) and 9.4(1)

  • Cisco IOS gateway release 12.3 and 12.3T

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.

Resolve MGCP Hung Call Errors

If you experience a hung MGCP call scenario, the use of debugs is not useful. Also, for a live system, it is difficult to correlate the synchronous payload envelope (SPE) with a DS0 and MGCP connection. If you want to correlate the DS0 and DSP for an active call, this document provides an explanation.

Before you begin, on the PGW 2200, ensure that the MgcpBehavior setting (use Man-Machine Language [MML]) has a value that equals 2 for the Cisco IOS gateway. Refer to the document XECfgParm.dat File Parameters for more information.

PGW 2200 version 9.1(5):

  • If MgcpBehavior equals 1 (gateways that are not based on Cisco IOS Software, such as Cisco Voice Interworking Service Module [VISM] and Cisco MGX) upon receipt of the 501 error code, the PGW 2200 sets the circuit to a state to prevent further use. Refer to the document Components and Properties for more information.

  • If the MgcpBehavior equals 2 (Cisco IOS gateway), upon receipt of the 501 error code, the PGW 2200 sets the circuit to a state to prevent further use. Upon receipt of the 502 error code in response to the first Create Connection (CRCX), the PGW 2200 sends the MGCP Delete Connection (DLCX) message, followed by another MGCP CRCX message. If another 502 error code is returned by the Cisco IOS gateway, the call is released. The assumption is that the circuit is again usable. See the document Components and Properties for more information.

PGW 2200 version 9.2(2) and later:

  • If the MgcpBehavior equals 1 (for the VISM and MGX), upon receipt of the 501 error code, the PGW 2200 sets the circuit to a state to prevent further use.

  • If the MgcpBehavior equals 2 (Cisco IOS gateway), upon receipt of the 501 error code, the PGW 2200 sets the circuit to a state to prevent further use. Upon receipt of the 502 error code (for the first MGCP CRCX message), the PGW 2200 sends an MGCP DLCX message followed by another MGCP CRCX message. If the PGW 2200 receives another 502 error code, the call is released. The circuit is set to a state to prevent further use. At the same time, the circuit is included in a list of circuits on which a background (mini) audit is performed. This audit sends a forced MGCP DLCX message for all the circuits in the mini audit list to try to bring the circuit state in synchronization with the PGW 2200.

The MGCP response time-out is treated like a transient failure GW_HELD condition, and the MGCP DLCX message retries every minute. Only the receipt of the Restart in Progress (RSIP) (graceful/forced) message, MGCP error code 500, or one of the special 501/502 error codes causes a permanent failure if the MgcpBehavior property is set appropriately. Be aware that error code 500 always causes a failure, regardless of MgcpBehavior, because it equates to "endpoint unknown."

Note: With PGW 2200 release 9.5(2) and later, the PGW 2200 has implemented MGCP 1.0. This provides more robustness and better error-handling procedures.

Message Cisco IOS Software (5xxx)
CRCX 502
Modify Connection (MDCX) 515
DLCX 250
Notification Request (RQNT) 400
Audit Endpoint (AUEP) 500

The reason for this is because the PGW 2200 has an audit mechanism to synchronize the channel states with the network element, such as a Cisco IOS gateway, with which it communicates. The audit program on the PGW 2200 runs at 4:00 a.m. (0400) every morning and does these actions in accordance with different scenarios:

  • Scenario 1: When the channel state is BUSY on the PGW 2200 as well as the Cisco IOS gateway, there is no action.

  • Scenario 2: When the channel state is IDLE on the PGW 2200 as well as the Cisco IOS gateway, an MGCP DLCX is sent to the Cisco IOS gateway for that endpoint. This clears any hung connection, if it exists.

  • Scenario 3: When the channel state is BUSY on the PGW 2200 and IDLE on the Cisco IOS gateway, the PGW 2200 releases the call and sends a DLCX to the Cisco IOS gateway for the corresponding endpoint to synchronize the Cisco IOS gateway.

  • Scenario 4: When the channel is IDLE on the PGW 2200 and BUSY on the Cisco IOS gateway, the PGW 2200 sends an MGCP DLCX to the Cisco IOS gateway for the corresponding endpoint to synchronize the Cisco IOS gateway. The PGW 2200 and Cisco IOS gateway audit procedure clears the channel on the Cisco IOS gateway.

    If the initial procedure that the Message Definition Language (MDL) invokes fails to bring the circuit to an idle condition, it invokes an engine interface to mark the endpoint as disabled and create an entry for the special hung/stranded endpoint audit mechanism of the engine.

    To change the MgcpBehavior value for the Cisco IOS gateway, change the MgcpBehavior property on the MGCPPATHs to 2.

    mml> prov-sta::srcver="active",dstver="cisco1" 
    mml> prov-ed:sigsvcprop:name="sigmgcpto5xxx",MgcpBehavior="2" 
    mml> prov-cpy

    Note: In some instances, a reload of the Cisco IOS gateway is requested to start from a clean situation again. Before doing this, some detail logging of the Cisco IOS gateway can help to solve the problem.

show Commands

The show commands discussed here can help with the verification and troubleshooting of a hung call.

Certain show commands are supported by the Output Interpreter Tool (registered customers only) , which allows you to view an analysis of show command output.

The show call active voice compact duration more ? command can help to find long-duration calls on the Cisco IOS gateway:

V5xxx-3# show call active voice compact duration more ? 
  <1-2147483647>  time in seconds 
V5xxx-3# 

The show call active voice brief | include duration 4d command can also provide guidelines:

V5xxx-3# show call active voice brief | include duration 4d 
V5xxx-3# show call active voice brief | include duration ? 
LINE    <cr> 

V5xxx-3#

These show commands can help to determine the hung call:

  • show mgcp statistics—Displays MGCP statistics about received and transmitted network messages.

  • show mgcp connection—Displays information for active connections that are controlled by the MGCP.

  • show rtpspi statistics—Displays the Real-Time Transport Protocol (RTP) Service Provider Interface (SPI) statistics.

  • show ip socket—Displays IP socket information.

  • show voice call summary—Displays a summary of all voice ports.

  • show voice port summary—Displays summary configuration information about a specific voice port.

  • show vtsp call fsm—Displays the complete history of all voice telephony service provider (VTSP) finite state machine (FSM) transitions.

  • show csm voice—Displays the information related to the call switching module (CSM). The information is the CSM state that the machine is in for the call associated to that DSP channel, the start time of the call, the end time of the call, and the channel on the controller used by the call.

    Note: If it is an MGCP Signaling System 7 (SS7), then this command is not much use.

  • show spe—Displays the SPE status.

  • show spe voice summary—Displays the SPE voice status.

  • show port operational-status slot/port (for the suspected DSP)—Displays information for all ports on the specified slot and SPE.

  • show port voice log reverse slot/port (for the suspected DSP)—Displays information for all ports on the specified slot and SPE.

The information in the series of show commands that follows references MGCP calls through AS5xxx gateways, which include Call_ID©) information (highlighted in boldface) for this call. This is also important for when you want to troubleshoot. The MGCP endpoint can be found with the Cisco IOS Software debug mgcp packet command or with the Cisco Snooper application.

V5xxx-3# show mgcp connection 
Endpoint  Call_ID©) Conn_ID(I) (P)ort (M)ode (S)tate (CO)dec (E)vent[SIFL] 
(R)esult[EA] 
1. S3/DS1-0/1   C=2F,1,2     I=0x2  P=16628,17204  M=3  S=4,4  
CO=2  E=0,0,0,0  R=0,0 

Note: Check the M status, which is linked to the MGCP mode on Troubleshoot Mute Calls on the Cisco PGW 2200.

The show call active voice brief command provides information on transmit (Tx)/receive (Rx) packet information.

V5xxx-3# show call active voice brief 

Telephony call-legs: 1 
SIP call-legs: 0 
H323 call-legs: 0 
MGCP call-legs: 1 
Multicast call-legs: 0 
Total call-legs: 2 
11DA : 37079hs.1 +-1 pid:0 Originate  connecting 
 dur 00:00:00 tx:1198/189454 rx:113437/18149920 
 IP 10.48.84.217:17204 rtt:0ms pl:16000/1290ms lost:29/34/29 delay:30/25/110ms 
 g711alaw 
 media inactive detected:n media contrl rcvd:n/a timestamp:n/a 
11DA : 37079hs.2 +0 pid:52 Originate  active 
 dur 00:37:50 tx:113437/18149920 rx:1198/189454 
 Tele 3/0:0 (1) [3/0.1] tx:2270655/3000/0ms g711alaw noise:-65 
 acom:90  I/0:-51/-45 dBm 

Telephony call-legs: 1 
SIP call-legs: 0 
H323 call-legs: 0 
MGCP call-legs: 1 
Multicast call-legs: 0 
Total call-legs: 2 

v5xxx-3# 

Issue the show voip rtp connections command to find out the Remote Gateway details. These include the CallId information for that call. (In this case, CallId is 1.)

v5xxx-3# show voip rtp connections 
VoIP RTP active connections : 
No. CallId  dstCallId  LocalRTP RmtRTP LocalIP    RemoteIP 
1         2     1          16628     17204    10.48.84.26  10.48.84.217 
Found 1 active RTP connections 

v5xxx-3# 

The show vtsp call fsm command is a hidden Cisco IOS Software command and is only used for Cisco Technical Support and the Cisco Development team. With this command, you can look for the enclosures with the phrase "Invalid FSM". The show vtsp call fsm command displays the complete history of all VTSP FSM transitions. It is triggered automatically whenever any DSP problem occurs while debug vtsp error command-line interface (CLI) is turned on.

Note: You also can convert CallId = 1 into hex, which gives you id = 0x1.

V5xxx-3# show vtsp call fsm 

0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  
0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0 
id=0x1 state=S_CONNECT chan_id=3/0:0 (1) DSM state=S_DSM_BRIDGED 
Stack 0: 
State Transitions: timestamp (state, event) -> (state, event) ... 
370.796 (S_SETUP_REQUEST, E_TSP_PROCEEDING) -> 
370.796 (S_SETUP_REQ_PROC, E_TSP_CONNECT) -> 
Event Counts (zeros not shown): (event, count) 
(E_TSP_PROCEEDING, 2) :(E_TSP_CONNECT, 2) : 
State Counts (zeros not shown): (state, count) 
(S_SETUP_REQ_PROC, 2) :(S_SETUP_REQUEST, 2) : 
  

--------------------- DSM basic call state information --------------------- 
id=0x1 state=S_DSM_BRIDGED chan_id=0 
Stack 0: 
State Transitions: timestamp (state, event) -> (state, event) ... 
370.796 (S_DSM_INIT, E_DSM_CC_GEN_TONE) -> 
370.796 (S_DSM_INIT, E_DSM_CC_CALL_MODIFY) -> 
370.796 (S_DSM_INIT, E_DSM_CC_BRIDGE) -> 
370.800 (S_DSM_BRIDGING, E_DSM_CC_CAPS_IND) -> 
370.800 (S_DSM_BRIDGING, E_DSM_CC_CAPS_ACK) -> 
475.764 (S_DSM_BRIDGED, E_DSM_CC_GET_LEVELS) -> 
2641.564 (S_DSM_BRIDGED, E_DSM_CC_GET_LEVELS) -> 
Event Counts (zeros not shown): (event, count) 
(E_DSM_DSP_GET_VP_DELAY, 496) :(E_DSM_DSP_GET_VP_ERROR, 496) :(E_DSM_DSP_GET_TX, 
 496) :(E_DSM_DSP_GET_RX, 496) 
(E_DSM_DSP_GET_LEVELS, 2) :(E_DSM_CC_BRIDGE, 1) :(E_DSM_CC_GEN_TONE, 1) :
 (E_DSM_CC_REQ_PACK_STAT, 496) 
(E_DSM_CC_CAPS_IND, 1) :(E_DSM_CC_CAPS_ACK, 1) :(E_DSM_CC_CALL_MODIFY, 1) :
 (E_DSM_CC_GET_LEVELS, 2) 

State Counts (zeros not shown): (state, count) 
(S_DSM_INIT, 3) :(S_DSM_BRIDGING, 2) :(S_DSM_BRIDGED, 2484) : 

v5xxx-3# 

To find out on which DSP the call is being connected, issue the command show tdm mapping and link the details to the endpoint for which you are tracing. In this case, it is S3/DS1-0/1:

v5xxx-3# show tdm mapping 

E1 3/0 is up: 
Loopback: NONE 
DS0      Resource    Call Type 
----------------------------------- 

1          1/0         VOICE 

E1 3/1 is up: 
Loopback: NONE 
DS0      Resource    Call Type 
----------------------------------- 

v5xxx-3# 

This is connected to SPE 1, port 1. Issue the show spe command to find out the Port and Call states.

v5xxx-3# show spe 
Settings  : 
========== 
Country code config : default T1 (u Law) 
Country code setting: e1-default 
History log events  : 50(per port) 
Legend    : 
========== 
Port state: (s)shutdown   (r)recovery  (t)test  (a)active call 
            (b)busiedout  (d)download  (B)bad   (p)busyout pending 
Call type : (m)modem      (d)digital   (v)voice (f)fax-relay       (_)not in use 

Summary   : 
========== 
Ports     : Total   60  In-use     1  Free    59  Disabled     0 
Calls     : Modem    0  Digital    0  Voice    1  Fax-relay    0 

                     SPE          SPE     SPE  SPE   Port         Call 
SPE#    Port #       State        Busyout Shut Crash State        Type 
1/00    0000-0005    ACTIVE             0    0     0 a_____       v_____ 
1/01    0006-0011    ACTIVE             0    0     0 ______       ______ 
1/02    0012-0017    ACTIVE             0    0     0 ______       ______ 
1/03    0018-0023    ACTIVE             0    0     0 ______       ______ 
1/04    0024-0029    ACTIVE             0    0     0 ______       ______ 
1/05    0030-0035    ACTIVE             0    0     0 ______       ______ 
1/06    0036-0041    ACTIVE             0    0     0 ______       ______ 
1/07    0042-0047    ACTIVE             0    0     0 ______       ______ 
1/08    0048-0053    ACTIVE             0    0     0 ______       ______ 
1/09    0054-0059    ACTIVE             0    0     0 ______       ______ 

v5xxx-3# 

In this case, you can find out if packets are still sent in and out on that SPE port if you issue the show port operational-status 1/0 command (for the suspected DSP):

v5xxx-3# show port operational-status 1/0   
Slot/SPE/Port -- 1/0/0 
Service Type                            : Voice service 
Voice Codec                             : G.711 a-law 
Echo Canceler Length                    : 8 ms 
Echo Cancellation Control               : Echo cancellation       - disabled 
                                          Echo update             - enabled 
                                          Non-linear processor    - enabled 
                                          Echo reset coefficients - disabled 
                                          High pass filter enable - disabled 
Digit detection enable                  : DTMF signaling          - enabled 
Voice activity detection                : Enabled 
Comfort noise generation                : Generate comfort noise 
Digit relay enable                      : OOB Digit relay         - enabled 
                                          IB Digit relay          - enabled 
Information field size                  : 20 ms 
Playout de-jitter mode                  : adaptive 
Encapsulation protocol                  : RTP 
Input Gain                              : 0.0 dB 
Output Gain                             : 0.0 dB 
Tx/Rx SSRC                              : 24/0 
Current playout delay                   : 30 ms 
Min/Max playout delay                   : 25/110 ms 
Clock offset                            : 180505398 ms 
Predictive concealment                  : 0 ms 
Interpolative concealment               : 1105 ms 
Silence concealment                     : 0 ms 
Buffer overflow discards                : 19 
End-point detection errors              : 23 
Tx/Rx Voice packets                     : 944/88273 
Tx/Rx signaling packets                 : 0/0 
Tx/Rx comfort noise packets             : 11/0 
Tx/Rx duration                          : 1767250/1767250 ms 
Tx/Rx voice duration                    : 3000/16000 ms 
Out of sequence packets                 : 0 
Bad protocol headers                    : 0 
Num. of late packets                    : 23 
Num. of early packets                   : 28 
Tx/Rx Power                             : -45.2/-51.2 dBm 
Tx/Rx Mean                              : -44.3/-51.0 dBm 
VAD Background noise level              : -65.8 dBm 
ERL level                               : 27.7 dB 
ACOM level                              : 90.1 dB 
Tx/Rx current activity                  : silence/silence 
Tx/Rx byte count                        : 151051/14123360 
ECAN Background noise level             : 0.0 dBm 
Latest SSRC value                       : 4144068239 
Number of SSRC changes                  : 1 
Number of payload violations            : 0 

v5350-3# 

Issue this command several times to provide details on the type of connection that is in combination with the Remote Gateway. Issue this command on the Local/Remote Gateway to find out the status.

If you have a hung call, you can issue the debug vtsp error and debug mgcp packet endpoint S3/DS1-0/1 commands. When you bring the MGCP endpoint down, the result is this debug message:

Apr  9 12:30:18.602: MGCP Packet received from 10.48.84.25:2427- 
DLCX 617 S3/DS1-0/1@v5300-3.cisco.com MGCP 0.1 
C: 1C 
I: 4D 
R: 
S: 
X: 268 
Apr  9 12:30:18.626: 250 617 OK 
P: PS=128, OS=20241, PR=16615, OR=2658400, PL=4, JI=24, LA=0 

These commands are also useful:

v5xxx-3# show voice call summary 
PORT           CODEC    VAD VTSP STATE       VPM STATE 
============== ======== === ==================== 
3/0:0.1            g711alaw  y     S_CONNECT 

v5xxx-3# show voice port summary 
                                     IN       OUT 
PORT      CH   SIG-TYPE   ADMIN OPER STATUS   STATUS   EC 
========= == ============ ===== ==== ======== ======== == 
3/0:0     01    xcc-voice   up   none  none   none     y 

v5xxx-3# 

The show mgcp statistics command also provides details on the failed connection. Try to understand the failed field information. One of causes of the failed MGCP connection is the fact that endpoint reports are in transient mode and are temporarily unavailable when the PGW 2200 sends a CRCX. The PGW 2200 then releases with a temporary failure as a cause and attempts that endpoint again at a later time because it was only in transient mode. These SS7 circuit identification codes (CICs) do not have any MGCP connection. The reason for this situation is that the MGCP on the gateway returns a 400 MGCP error code (temporary failure for new CRCX messages sent by the Cisco IOS gateway).

v5xxx-3# show mgcp statistics 
 UDP pkts rx 306, tx 330 
 Unrecognized rx pkts 0, MGCP message parsing errors 0 
 Duplicate MGCP ack tx 0, Invalid versions count 0 
 CreateConn rx 0, successful 0, failed 0 
 DeleteConn rx 0, successful 0, failed 0 
 ModifyConn rx 0, successful 0, failed 0 
 DeleteConn tx 0, successful 0, failed 0 
 NotifyRequest rx 0, successful 0, failed 0 
 AuditConnection rx 0, successful 0, failed 0 
 AuditEndpoint rx 306, successful 305, failed 1 
 RestartInProgress tx 1, successful 1, failed 0 
 Notify tx 0, successful 0, failed 0 
 ACK tx 305, NACK tx 1 
 ACK rx 0, NACK rx 0 

 IP address based Call Agents statistics: 
 IP address 10.48.84.25, Total msg rx 306, 
                  successful 305, failed 1 
 System resource check is DISABLED. No available statistic 

v5xxx-3#

Diagnose PGW 2200 Hung Calls

This section provides steps to isolate a hung SS7 CIC on the PGW 2200 in the way CIC "x" via the MML command rtrv-tc:all is stuck as call OUT on the PGW 2200. First, issue the MML prt-call command on this CIC.

For example, on an MGCP backhaul connection, if the bearer requested in the SETUP message is not available for that call, the PGW 2200 generates the alarm PRI: B-Channel Not Available and reports CP_ERR_CHAN_NOT_ACQ errors in platform.log. Other error messages can appear in platform.log, depending on the type of call scenario that you are running. For details, refer to the Diagnosing Hung Calls section of the document Troubleshooting the Cisco MGC Node for the PGW 2200.

There are three possible reasons for the nonavailability:

  1. The bearer is not configured.

  2. The bearer is not in service. (For example, it is in an Out-of-Service (OOS) state, it is in a locked/blocked state, or the MGCP disabled the endpoint.)

  3. The bearer is busy (glare condition).

Perform these steps:

  1. Note when the PGW 2200 reports errors for each call.

  2. If you see errors at least three to five times in a single day on the same CIC (bearer), it is suspect.

  3. Check the status of the CIC/bearer with the use of the rtrv-tr:all MML command.

    If it is idle, the CIC is not hung.

  4. If the SS7 CIC is busy, issue the prt-call command on that CIC.

    For more details on the prt-call MML command, issue the command help :prt-call.

    mgc-bru-20 mml> help :prt-call
    �� � � � � � � � � �MGC-01 - Media Gateway Controller 2004-11-29 19:32:35.998 GMT
    � � � � � � � � � � �M� RTRV��� 
    ����� 
    ���������������������������� PRT-CALL -- Print Call
    ���������������������������� ----------------------
          
       Purpose:      Prints diagnostic information about hung calls to a log file.  
                     
       Format:       prt-call:<sigpath>:CIC=<n>|span=<n>[bc=<n>|CID=<n>][,LOG=<logn]
                     [,EVT]
       Input
       Description:  Target parameters are as follows:
                     * sigPath -- Corresponding MML name for any of the 
                       following component types:
                       - Signal path of in-band TDM up to MUX and then 
                         time switched to TDM media and sent to Cisco MGC
                       - Signal path of in-band TDM signaling up to CU 
                         and then encapsulated and sent over IP to the Cisco MGC
    
    <Press 'SPACE' for next page, 'Enter' for next line or 'q' to quit this output>
    

    A print call file with the .prt extension is written in the /opt/CiscoMGC/var/trace directory.

  5. Open the file and search for the string LcmOrigSmState.

    If you see both OrigSmState and TermSmState as RelIdle, you do not have a hung CIC.

    Example:

    VAR LcmOrigSmState: STATE 
    �� { 
    �� OsmRelIdle 
    �� } [8]
    VAR LcmTermSmState: STATE 
    �� { 
    �� TsmRelIdle 
    �� }[8]

    If either OrigSmState or TermSmState is not RelIdle, you have a likely suspect. Here are two examples of hung CIC print calls:

    Example 1:

    VAR LcmOrigSmState: STATE 
    �� { 
    �� OsmRelTerm3wAwaitConnDelInd 
    �� }[8] 
    VAR LcmTermSmState: STATE 
    �� { 
    �� TsmRelTermInit 
    �� }[8] 

    Example 2:

    VAR LcmOrigSmState: STATE 
    �� { 
    �� OsmRelOrigInit 
    �� }[8] 
    VAR LcmTermSmState: STATE 
    �� { 
    �� TsmRelIdle 
    �� }[8] 

    If you reach the next step, you have identified a hung CIC.

  6. Issue the stp-call MML command to clear the hung CIC.

    Issue the grep Osm file_name.prt command. You should get OsmRelIdle.

    Issue the grep Tsm file_name.prt command. You should get TsmRelIdle.

    If you do not see OsmRelIdle and TsmRelIdle, and if this condition persists after you issue another prt-call command (may be part of transient), the CIC is likely hung.

  7. If the issue of the stp-call command fails to clear the problem, issue the kill-call MML command.

    The kill-call command does not clear the connection in the MGCP gateway. Therefore, an MGCP audit is required if you issue the kill-call command. Perform the audit during a low-traffic period. For more details on the kill-call command, issue the help :kill-call command:

    � �PGW2200A mml> help :kill-call
    �� � � � � � � � � � �MGC-01 - Media Gateway Controller 2004-11-29 19:34:52.084 GMT
    � � � � � � � � � � � M� RTRV���� 
    ����� 
    ��������������������� KILL-CALL -- Resolve a Stuck CIC
    ��������������������� --------------------------------
    ����� 
    �� Purpose:����� Resolves a stuck or hung CIC (forcefully releases a bearer channel
    ���������������� associated with a single call instance that cannot be returned to
    ���������������� the idle state with the reset-cic or stp-call command) on the MGC.
    ���������������� Note:� This command only releases bearer channels locally on the
    ���������������� MGC. No SS7 messages are sent to the remote call side (destination
    ���������������� MGW). 
    �� Syntax:������ kill-call:<sigpath_name>|<target>:CID=sip call id,confirm
    ���������������� kill-call:<sigpath_name>|<target>:[span= number,]confirm
    ���������������� kill-call:<sigpath_name>|<target>:[cic=<num>], [RNG=number,]com
    ���������������� kill-call:<dest_mgw>:span=<span>,bc=<bearer channel>,[RNG=numbm
    �� Input�������� * sigpath_name -- MML name of the SS7 or ISDN-PRI signal path
    �� Description:
    
    <Press 'SPACE' for next page, 'Enter' for next line or 'q' to quit this output>
    
  8. Create a service request with Cisco Technical Support and submit the prt-call output for analysis.

Related Information

Updated: Feb 02, 2006
Document ID: 50501