Contents

Introduction

Prerequisites

Requirements

Components Used

Conventions

Resolve MGCP Hung Call Errors

show Commands

Diagnose PGW 2200 Hung Calls

Related Information

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:

- Cisco Media Gateway Controller Software Release 9 Documentation

- Release Notes for the Cisco Media Gateway Controller Software Release 9.3(2)

- Release Notes for the Cisco Media Gateway Controller Software Release 9.4(1)

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

- Cisco PGW 2200 Softswitch Troubleshooting TechNotes

- Cisco Signaling Controllers Product Support

- Voice Technology Support

- Voice and IP Communications Product Support

- Troubleshooting Cisco IP Telephony

- Technical Support & Documentation - Cisco Systems