This document provides troubleshooting information for voice calls that
are muted in one direction on the Cisco PGW 2200 PSTN Gateway (Cisco PGW 2200).
The information in this document applies specifically to the Cisco PSTN Gateway
Solution using Media Gateway Controller (MGC) and Cisco AS5x00 gateways in
combination with the Cisco PGW 2200.
The information presented in this document was created from devices in
a specific lab environment. All of the devices used in this document started
with a cleared (default) configuration. If you are working in a live network,
ensure that you understand the potential impact of any command before using
Note: When the call is busy or there is some sort of announcement to play
to the caller, there is no reason to open the voice path in both directions. If
you think you have a reported mute call, issue a debug mgcp
packet command on the Originating and Terminating Gateway in
combination with a show call history voice command
linked to the messages with a zero sent packet count, a show call
history voice brief command, and a Cisco Message Definition
Language (MDL) trace on the PGW 2200 to understand the problem. A snooper trace
will also help you to understand the problem. The MDL trace provides a complete
SS7 and Media Gateway Control Protocol (MGCP) call flow.
The following conditions cause the PGW 2200 to flag mute calls (during
Delete Connection [DLCX]) and detection in platform.log. These logs contain a
call ID which has the gateway information and CIC information.
PGW 2200 is configured in Fault Tolerant mode.
Call was answered (the call was successfully
250 OK message was received with (P:) in response to
Either Packet Sent (PS) equals 0 or Packet Received (PR) equals 0 in
Field descriptions of the show mgcp
connection command for VoIP are shown below.
Endpoint—The endpoint for each call, shown in the
digital endpoint naming convention of slot number (S0) and digital line (DS1-0)
Call_ID(C)—The MGCP call ID sent by the call agent,
the internal Call Control Application Programming Interface (CCAPI) call ID for
this endpoint, and the CCAPI call ID for the peer call legs. CCAPI is an API
that provides call control facilities to applications.
Conn_ID(I)—The connection ID generated by the
gateway and sent in the ACK message.
(P)ort—The ports used for this connection. The first
port is the local User Datagram Protocol (UDP) port. The second port is the
remote UDP port.
(M)ode—The call mode, where:
0—Indicates an invalid value for mode.
1—Indicates that the gateway should only send
2—Indicates that the gateway should only receive
3—Indicates that the gateway can send and receive
4—Indicates that the gateway should neither send nor receive
5—Indicates that the gateway should place the circuit in loopback
6—Indicates that the gateway should place the circuit in test
7—Indicates that the gateway should use the circuit for network
access for data.
8—Indicates that the gateway should place the connection in network
9—Indicates that the gateway should place the connection in network
continuity test mode.
10— Indicates that the gateway should place the connection in
(S)tate INFO—Example: S=4,4 The fist integer shows
the local MGCP call state and the second integer shows the remote MGCP call
= 0, Idle
= 1, Incoming call from PSTN
= 2, MGCP CRCX received
= 3, Call connected, await conf
= 4, Conference created
= 5, Destroying conference
= 6, Conf destroyed, disconnect call
= 7, Call in inactive mode
= 8, Creating telephony call leg only
= 9, Telephony call leg created
= 10, Destroying conf
=11, Conf destroyed, no call discon
= 12, Connecting TDM hairpin call leg
= 13, One HP call leg connected
= 14, Conferencing TDM Hairpin call leg
= 15, TDM hairpining active state
= 16, Conf destroyed, make HP call
= 17, Call in error state
= 18, Creating inactive connection
= 19, Conf destroy inactive conn
= 20, AAL2/IP continuity test (xrbk)
= 21, Waiting for setup information
= 22, Wait for NSE event to be sent
= 23, TWC call active
= 24, App is waiting for call control
= 25, App is grabbing back the control
= 26, Disconnect call, E&M endpoints
(C)odec INFO—Example: C=1
1 = G.711 mu-law
2 = G.711 A-law
3 = G.726 32K
4 = G.726 24K
5 = G.726 16K
6 = G.729
7 = G.729-A
8 = G.729-B
9 = G.729-B
10 = G.728
11 = G.723.1 High Rate
12 = G.723.1 Annex A High Rate
13 = G.723.1 Low Rate
14 = G.723.1 Annex A Low Rate
15 = GSM full rate
16 = GSM half rate
17 = GSM enhanced full rate
18 = GSM enhanced half rate
MGCP_CLEAR_CHANNEL = 128,
128 = Nx64 clear channel
MGCP_NSE = 129
(E)vent—Example: E=3,0,2,3 The event field is read
as: E=last_successful_mgcp_event, last_successful_internal_event,
MGCP_APP_EV_ACK = -1,
MGCP_APP_EV_CREATE_CONN = 0,
MGCP create connection msg
MGCP delete connection msg
MGCP modify connection msg
MGCP notify request msg
CCAPI alert event
CCAPI call connect event
CCAPI conference ready
CCAPI conference destroyed
CCAPI call disconnect
CCAPI call proceeding
CCAPI off-hook/call setup ind
CCAPI on-hook/call disconnected
MGCP Media Events
MGCP Internal Events
CCAPI Call modify done ev
Voice Cut-thru has happened
CCAPI NSE events
Handoff Call to some other app
(R)esult—Example: R=0,0 The result field is
interpreted as: R=Event_result,(boolean) do we need to send ACK?
Mute calls may be linked to software problems or other issues. Use the
following steps to begin to troubleshoot mute calls on the Cisco PGW
Understand the customer's problem description. Mute calls can be
related to other items which are not linked to software errors such as IP
routing and Layer 1 problems. The solution of each root cause often exposes
additional lower-level problems that need to be fixed first.
Calculate the ratio of failed calls to mute calls at customer
location per 24-hour monitoring.
Avoid defining exactly what percentage of calls are
Try to reproduce this situation to understand the real cause of the
To check CPU load on the PGW 2200, issue the following command:
This command displays the following type of information:
MGC-01 - Media Gateway Controller 2003-02-14 15:36:50.788 GMT
"Machine Congestion Level = MCL 0 (No Congestion)"
"Current in progress calls = 83, call attempts = 2 cps"
"CPU 0 Utilization = 1 % CPU 1 Utilization = 0 %"
"CPU 2 Utilization = 2 % CPU 3 Utilization = 0 %"
"Memory (KB):3715344 Free virtual, 8390328 Total virtual, 4194304
"Filesystem kbytes used avail capacity Mounted on"
"/dev/dsk/c0t0d0s0 494235 47099 397713 11% /"
"/dev/dsk/c0t0d0s4 10678328 5494165 5077380 52% /opt"
Check the Calls Per Second (CPS) information and try to calculate this
in combination with the gateways you are using. Maybe some gateways have a high
CPU load due to the amount of calls coming in. The following result display
into platform.log also can explain the status of the system.
Fri Nov 13 10:18:28:119 2002 CET | engine (PID 14488) <Error>engMclMgrImpl::updateSystemMcl:
System Mcl = 1, MclName = cpu, Load = 84 AvgLoad = 68
Note: In this example, there was a CPU overload condition due to high
traffic which abated in a few minutes. This is as a result of peak hour period.
At that point, try to link this information with mute calls.
To obtain a status over a certain amount of time, issue the following
as5xxx-1> show proc cpu history
A high CPU load can be caused by one of the items being linked to
process switching. To check this, issue the show running-config |
incl route command.
as5xxx-1> show running-config | incl route
To avoid a high CPU load on the gateway, do not
have the following commands in your configurations:
no ip route-cacheno ip route-cache cef
Note: The ip route-cache or ip
route-cache cef command should be configured on the gateways.
If you see any of the above, you are most likely process switching
instead of fast switching and the system load will be extremely high, calls may
be lost, and the voice quality will be poor. Additionally, the MGCP message may
not be Acknowledged (ACK) or generated.
Depending on the way the ip host command is
configured on the gateways, it will not send RSIP messages on the secondary
Ethernet. The reason the gateway is trying to send to the first IP address for
a second round of tries before failing over to the second IP address is linked
to the Cisco IOS® Software configuration. This forces a DNS lookup (which looks
at an ip host command when no ip
domain-lookup command is configured). When this happens, the
first IP address is returned and used again. To avoid this behavior, use the
following command in the MGCP profile:
as5xxx-1> mgcp profile
as5xxx-1> no max1 lookup
Note: You need to reload the router for the no max1
lookup command configuration to take effect.
as5xxx-1 > show call active voice brief | incl Call_ID
Tele 0/0:0 (call_id): tx:0/0/0ms None noise:0 acom:0 i/0:0/0 dBm
At this point, you can find the information from the
show call active voice command, linked on Conn_ID to
find Tx packets, Tx bytes, Rx packets, and Rx bytes information. This
information can tell you the numbers of packets being sent and received.
In this case, you can find the Local and Remote Gateway
as5xxx-1 > show voip rtp connections
VoIP RTP active connections :
No. CallId dstCallId LocalRTP RmtRTP LocalIP RemoteIP
1 3334374 3334373 19544 18424 188.8.131.52 184.108.40.206
Determine if a larger percentage of the mute calls occur during
In rare situations, packets sent by the Cisco AS5400 may not be
received by the Cisco AS5300 TDM interface. If this occurs, the Cisco AS5400
DLCX ACK shows Tx packets, but the Cisco AS5300 does not show any Rx packets.
Loopback interface is important for the MGCP connection in combination with the
mgcp bind command.
Note: MGCP implementation uses the best available IP address on the MGC as
a source address to communicate with the call agent. The media stream uses the
loopback address if configured, otherwise the best available IP address as its
source address. There is no defined way to change this behavior. The
bind command allows more flexibility for choosing
source address for both control and media packets.
Listed below are a few situations which explain the behavior of the
command. For all of these cases, appropriate warning message will be displayed
depending on the situation.
When there are active MGCP calls on the gateway, the
bind command will be rejected for both control and
If the bind interface is not up, then the command is accepted, but it
does not take affect until interface comes up.
If the IP address is not assigned on the bind interface, the
bind command is accepted but it takes effect only
after valid IP address is assigned, during this time if MGCP calls are up, the
bind command is removed.
When the bound interface goes down, either because of a manual shut
on the interface or because of an operational failure, bind activity is
disabled on that interface.
When bind is not configured on the MGC, the IP address used for
sourcing MGCP control and media is best available IP
One of the criteria that the PGW 2200 uses to flag a mute call is that
the call should be in Answer state, which means that the ANM message should
have been sent by the PGW 2200 to the originating SS7 switch. Before sending
the ANM message to the originating SS7 switch, the PGW 2200 transmits the MDCX
to the GW to set the Mode to Send-Recv. If the MDCX is not acknowledged by the
GW due to connectivity or other issues, the call does not reach the Answer
state, hence it is not tracked as a mute call. At that point, an Error log will
be sent to the platform.log file at opt/CiscoMGC/var/log.
MGCP Command Resent
If MGCP command message (CRCX, DLCX, MDCX) is resent due to a time-out
(for example PGW 2200 sent MDCX [sendrecv] four times), but the gateway did not
ACK it, the call fails and it is not considered a mute call by the PGW 2200.
PGW 2200 flags a mute call (mute-message into platform.log) during DLCX if:
The call was answered, and
a 250 OK message had connection parameter (P:), and
Either PS or PR was 0 in (P:)
Note: This can be linked to other items not linked as a real mute call. For
example, if the calling party hangs up when the called party answers, you see
this message and it is correct. But this is not a mute call. For hairpin calls
(hairpinning is the name given to calls that originate and terminate on the
same router or gateway), the 250 OK message in response to DLCX does not have
connection parameter (P:). These calls are are not flagged as mute.