PGW 2200 Softswitch Error Resolution for MGCP Hung Calls
Available Languages
Download Options
Bias-Free Language
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.
Contents
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:
-
The bearer is not configured.
-
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.)
-
The bearer is busy (glare condition).
Perform these steps:
-
Note when the PGW 2200 reports errors for each call.
-
If you see errors at least three to five times in a single day on the same CIC (bearer), it is suspect.
-
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.
-
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.
-
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.
-
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.
-
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>
-
Create a service request with Cisco Technical Support and submit the prt-call output for analysis.
Related Information
Revision History
| Revision | Publish Date | Comments |
|---|---|---|
1.0 |
02-Feb-2006 |
Initial Release |
Feedback