Cisco IOS Voice Troubleshooting and Monitoring -- MGCP Overview

From DocWiki

(Difference between revisions)
Jump to: navigation, search
(Added required metadata template)
(added metadata)
 
Line 1: Line 1:
{{Template:Required Metadata}}
{{Template:Required Metadata}}
 +
<meta name="keywords" content="mgcp, voice, IOS, troubleshooting"></meta>
Two basic MGCP constructs are endpoints and connections. An endpoint is a source or sink for call data (RTP/IP) that is flowing through the gateway. A common type of endpoint is found at the physical interface between the POTS or PSTN service and the gateway; this type of endpoint might be an analog voice port or a digital DS0 group. There are other types of endpoints as well, and some are logical rather than physical. An endpoint is identified by a two-part endpoint name that contains the name of the entity on which it exists (for example, an access server or router) and the local name by which it is known (for example, a port identifier).
Two basic MGCP constructs are endpoints and connections. An endpoint is a source or sink for call data (RTP/IP) that is flowing through the gateway. A common type of endpoint is found at the physical interface between the POTS or PSTN service and the gateway; this type of endpoint might be an analog voice port or a digital DS0 group. There are other types of endpoints as well, and some are logical rather than physical. An endpoint is identified by a two-part endpoint name that contains the name of the entity on which it exists (for example, an access server or router) and the local name by which it is known (for example, a port identifier).

Latest revision as of 17:17, 16 October 2012

Two basic MGCP constructs are endpoints and connections. An endpoint is a source or sink for call data (RTP/IP) that is flowing through the gateway. A common type of endpoint is found at the physical interface between the POTS or PSTN service and the gateway; this type of endpoint might be an analog voice port or a digital DS0 group. There are other types of endpoints as well, and some are logical rather than physical. An endpoint is identified by a two-part endpoint name that contains the name of the entity on which it exists (for example, an access server or router) and the local name by which it is known (for example, a port identifier).

Guide Contents
Troubleshooting Cisco IOS Voice Overview
Debug Command Output on Cisco IOS Voice Gateways
Filtering Troubleshooting Output
Cisco VoIP Internal Error Codes
Troubleshooting Cisco IOS Voice Telephony
Troubleshooting Cisco IOS Voice Protocols
Troubleshooting Cisco IOS Telephony Applications
Monitoring the Cisco IOS Voice Network
Cause Codes and Debug Values

Contents

Call Agents

Call agents manage call flow using standard MGCP commands that are sent to the endpoints under their control. The commands are delivered in standard ASCII text, and can contain session descriptions transmitted in Session Description Protocol (SDP), a text-based protocol. These messages are sent over IP/UDP.

Call agents keep track of endpoint and connection status through the gateway's reporting of standard events that are detected from endpoints and connections. Call agents also direct gateways to apply certain standard signals when a POTS/PSTN connection expects them. For example, when someone picks up a telephone handset, an off-hook event is detected on an endpoint on the residential gateway to which the telephone is connected. The gateway reports the event to a call agent, which orders the gateway to apply the dial-tone signal to the endpoint reporting the off-hook event. The person picking up the handset hears dial tone.

Figure: MGCP Network Model shows a hypothetical MGCP network with both residential and trunking gateways. The residential gateway has telephone sets connected to the gateway's FXS voice ports. MGCP or NCS over IP/UDP is used for call control and reporting to the call agent, and Real-time Transmission Protocol (RTP) is used to transmit the actual voice data.

Figure: MGCP Network Model also shows two trunking gateways with T1 (or E1) connections to the PSTN. Incoming time-division multiplexing (TDM) data is sent through the gateway into the packet network through the use of RTP. MGCP or TGCP over IP/UDP is used for call control and reporting to the call agent. Signaling System 7 (SS7) data travels a different route, however, bypassing the trunking gateway entirely in favor of a specialized signaling gateway, where the signaling data is transformed to ISUP/IP format and relayed to the call agent. Communication between two signaling gateways in the same packet network can be done with ISUP/IP, H.323, or Session Initiation Protocol (SIP).

Figure: MGCP Network Model

62067.jpg

MGCP Gateway Call Flow

The following example shows an MGCP call flow. The network topology is shown in Figure: MGCP Call Flow Topology . In this example, the FXS port is registered as an endpoint to Cisco CallManager.

Figure: MGCP Call Flow Topology

103636.jpg

User Access Verification

In this example, the show log command is used to show the MGCP packets sent between the Cisco gateway and Cisco CallManager.

Router#
Router#show log
Syslog logging: enabled (0 messages dropped, 1 messages rate-limited, 0 flushes,
 0 overruns, xml disabled)
    Console logging: level debugging, 280 messages logged, xml disabled
    Monitor logging: level debugging, 109 messages logged, xml disabled
    Buffer logging: level debugging, 69 messages logged, xml disabled
    Logging Exception size (4096 bytes)
    Count and timestamp logging messages: disabled
    Trap logging: level informational, 39 message lines logged
Log Buffer (10000000 bytes):


The FXS port goes off hook and notifies the CallAgent of the status through observed event. Here, the MGCP packet is sent by the gateway.

*Mar  1 02:16:29.399: send_mgcp_msg, MGCP Packet sent to 172.6.104.54 
*Mar  1 02:16:29.399: NTFY 186 aaln/S1/SU0/0@Router MGCP 0.1
X: 1b
O: L/hd

Here, the gateway receives the response from the CallAgent.

*Mar  1 02:16:29.399: MGCP Packet received from 172.6.104.54-
200 186

The CallAgent directs the port to provide the dial tone and requests a notification if there is any change of events such as a port disconnect or digits received.

*Mar  1 02:16:29.411: MGCP Packet received from 172.6.104.54-
RQNT 40 AALN/S1/SU0/0@Router MGCP 0.1
X: 1c
R: L/hu, D/[0-9ABCD*#]
S: L/dl
Q: process,loop
*Mar  1 02:16:29.419: send_mgcp_msg, MGCP Packet sent to 172.6.104.54 

The FXS port (endpoint) notifies the Call Agent about the digits that it received.

*Mar  1 02:16:29.419: 200 40 OK
*Mar  1 02:16:33.595: send_mgcp_msg, MGCP Packet sent to 172.6.104.54 
*Mar  1 02:16:33.595: NTFY 187 AALN/S1/SU0/0@Router MGCP 0.1
X: 1c
O: D/1
*Mar  1 02:16:33.599: MGCP Packet received from 172.6.104.54-
200 187
*Mar  1 02:16:33.603: MGCP Packet received from 172.6.104.54-
RQNT 41 AALN/S1/SU0/0@Router MGCP 0.1
X: 1d
R: L/hu, D/[0-9ABCD*#], L/hf
S:
Q: process,loop
*Mar  1 02:16:33.607: send_mgcp_msg, MGCP Packet sent to 172.6.104.54
*Mar  1 02:16:33.607: 200 41 OK
*Mar  1 02:16:35.655: send_mgcp_msg, MGCP Packet sent to 172.6.104.54 
*Mar  1 02:16:35.655: NTFY 188 AALN/S1/SU0/0@Router MGCP 0.1
X: 1d
O: D/0
*Mar  1 02:16:35.659: MGCP Packet received from 172.6.104.54-
200 188
*Mar  1 02:16:37.275: send_mgcp_msg, MGCP Packet sent to 172.6.104.54 
*Mar  1 02:16:37.275: NTFY 189 AALN/S1/SU0/0@Router MGCP 0.1
X: 1d
O: D/0
*Mar  1 02:16:37.279: MGCP Packet received from 172.6.104.54-
200 189
*Mar  1 02:16:38.815: send_mgcp_msg, MGCP Packet sent to 172.6.104.54 
*Mar  1 02:16:38.815: NTFY 190 AALN/S1/SU0/0@Router MGCP 0.1
X: 1d
O: D/1
<--- 
*Mar  1 02:16:38.819: MGCP Packet received from 172.6.104.54-
200 190
*Mar  1 02:16:38.839: MGCP Packet received from 172.6.104.54-
CRCX 42 AALN/S1/SU0/0@Router MGCP 0.1
C: A00000000200001d
X: 1e
M: inactive
R: L/hu
Q: process,loop
*Mar  1 02:16:38.851: send_mgcp_msg, MGCP Packet sent to 172.6.104.54 
*Mar  1 02:16:38.851: 200 42 OK
I: 4
v=0
c=IN IP4 172.16.13.41
m=audio 19156 RTP/AVP 0 8 99 101 102 2 15 103 4 104 105 106 107 18 100
a=rtpmap:99 G.729a/8000
a=rtpmap:101 G.726-16/8000
a=rtpmap:102 G.726-24/8000
a=rtpmap:103 G.723.1-H/8000
a=rtpmap:104 G.723.1-L/8000
a=rtpmap:105 G.729b/8000
a=rtpmap:106 G.723.1a-H/8000
a=rtpmap:107 G.723.1a-L/8000
a=rtpmap:100 X-NSE/8000
a=fmtp:100 200-202
a=X-sqn:0
a=X-cap: 1 audio RTP/AVP 100
a=X-cpar: a=rtpmap:100 X-NSE/8000
a=X-cpar: a=fmtp:100 200-202
a=X-cap: 2 image udptl t38
<---
*Mar  1 02:16:38.855: MGCP Packet received from 172.6.104.54-
RQNT 43 AALN/S1/SU0/0@Router MGCP 0.1
X: 1f
R: L/hu
S: G/rt
Q: process,loop


At this time the call is sent to the IP Phone. The CA directs the IP Phone to start playing ringbacks.

*Mar  1 02:16:38.859: send_mgcp_msg, MGCP Packet sent to 172.6.104.54 
*Mar  1 02:16:38.859: 200 43 OK
<---
*Mar  1 02:16:46.159: MGCP Packet received from 172.6.104.54-
MDCX 44 AALN/S1/SU0/0@Router MGCP 0.1
C: A00000000200001d
I: 4
X: 20
L: p:20, a:PCMU, s:off
M: recvonly
R: L/hu
Q: process,loop
*Mar  1 02:16:46.167: send_mgcp_msg, MGCP Packet sent to 172.6.104.54 
*Mar  1 02:16:46.167: 200 44 OK
<---
*Mar  1 02:16:46.171: MGCP Packet received from 172.6.104.54-
RQNT 45 AALN/S1/SU0/0@Router MGCP 0.1
X: 21
R: L/hu, D/[0-9ABCD*#], L/hf
S:
Q: process,loop
*Mar  1 02:16:46.175: send_mgcp_msg, MGCP Packet sent to 172.6.104.54 ---> </nowiki>
*Mar  1 02:16:46.175: 200 45 OK
*Mar  1 02:16:46.179: MGCP Packet received from 172.6.104.54-
MDCX 46 AALN/S1/SU0/0@Router MGCP 0.1
C: A00000000200001d
I: 4
X: 22
L: p:20, a:PCMU, s:off
M: sendrecv
R: L/hu, L/hf, D/[0-9ABCD*#]
S:
Q: process,loop
v=0
o=- 4 0 IN EPN AALN/S1/SU0/0@Router
s=Cisco SDP 0
t=0 0
c=IN IP4 10.17.179.33
m=audio 28390 RTP/AVP 96
a=rtpmap:96 PCMU
*Mar  1 02:16:46.187: send_mgcp_msg, MGCP Packet sent to 172.6.104.54 
*Mar  1 02:16:46.191: 200 46 OK

Now the call is answered. Note that media is cut in both directions.After about 12 seconds the called party on the IP Phone drops the call.

*Mar  1 02:16:58.355: MGCP Packet received from 172.6.104.54-
MDCX 47 AALN/S1/SU0/0@Router MGCP 0.1
C: A00000000200001d
I: 4
X: 23
M: recvonly
R: L/hu
Q: process,loop
*Mar  1 02:16:58.359: send_mgcp_msg, MGCP Packet sent to 172.6.104.54 
*Mar  1 02:16:58.359: 200 47 OK
*Mar  1 02:16:58.379: MGCP Packet received from 172.6.104.54-
DLCX 48 AALN/S1/SU0/0@Router MGCP 0.1
C: A00000000200001d
I: 4
X: 24
R: L/hu
S:
Q: process,loop
*Mar  1 02:16:58.383: send_mgcp_msg, MGCP Packet sent to 172.6.104.54 
*Mar  1 02:16:58.383: 250 48 OK
P: PS=608, OS=97280, PR=604, OR=96640, PL=0, JI=64, LA=0
*Mar  1 02:17:01.403: MGCP Packet received from 172.6.104.54-
RQNT 49 AALN/S1/SU0/0@Router MGCP 0.1
X: 25
R: L/hu, D/[0-9ABCD*#]
S: L/dl
Q: process,loop

Since this call was made from an FXS phone the calling party hears a dial tone

*Mar  1 02:17:01.411: send_mgcp_msg, MGCP Packet sent to 172.6.104.54 
*Mar  1 02:17:01.411: 200 49 OK
*Mar  1 02:17:03.135: send_mgcp_msg, MGCP Packet sent to 172.6.104.54 
*Mar  1 02:17:03.135: NTFY 191 AALN/S1/SU0/0@Router MGCP 0.1
X: 25
O: L/hu
*Mar  1 02:17:03.139: MGCP Packet received from 172.6.104.54-
200 191
*Mar  1 02:17:03.143: MGCP Packet received from 172.6.104.54-
RQNT 50 AALN/S1/SU0/0@Router MGCP 0.1
X: 26
R: L/hd
S:
Q: process,loop
*Mar  1 02:17:03.147: send_mgcp_msg, MGCP Packet sent to 172.6.104.54 
*Mar  1 02:17:03.147: 200 50 OK

Troubleshooting Guidelines

The following suggestions help with troubleshooting:

  • Reset the MGCP statistical counters with the clear mgcp statistics command.
  • If RTP traffic is not getting through, make sure IP routing is enabled. Use the show rtp statistics command, then turn on the debug ip udp command and track down the MGCP RTP packets.
Router# show rtp statistics 
RTP Statistics info: 
No. CallId Xmit-pkts Xmit-bytes Rcvd-pkts  Rcvd-bytes Lost pkts  Jitter Latenc 
1   17492  0x8A      0x5640     0x8A       0x5640     0x0        0x0      0x0  
Router# show rtp statistics 
RTP Statistics info: 
No. CallId Xmit-pkts Xmit-bytes Rcvd-pkts  Rcvd-bytes Lost pkts  Jitter Latenc 
1   17492  0xDA      0x8840     0xDB       0x88E0     0x0        0x160    0x0  
  • If an RSIP message is not received by the call agent, make sure that the mgcp call-agent command or the MGCP profile call-agent command is configured with the correct call agent name or IP address and UDP port. Use the show mgcp command or the show mgcp profile command to display this information:
Router# show mgcp 
MGCP Admin State ACTIVE, Oper State ACTIVE - Cause Code NONE 
MGCP call-agent: 172.29.248.51  Initial protocol service is MGCP, v. 1.0 
... 
MGCP gateway port: 2727, MGCP maximum waiting delay 3000 
... 
Router# show mgcp profile 
MGCP Profile nycprofile 
Description: NY branch office configuration 
Call-agent: 10.14.2.200 Initial protocol service is MGCP, v. 1.0 
... 
  • To verify connections and endpoints, use the show mgcp command:
Router# show mgcp connection 
Endpoint  Call_ID(C) Conn_ID(I) (P)ort (M)ode (S)tate (C)odec (E)vent[SIFL] (R)esult[EA] 
1. S0/DS1-1/5      C=F123AB,5,6  I=0x3  P=16506,16602  M=3  S=4  C=1 E=2,0,0,2  R=0,0 
2. S0/DS1-1/6      C=F123AB,7,8  I=0x4  P=16602,16506  M=3  S=4  C=1 E=0,0,0,0  R=0,0 
Router# show mgcp endpoint  
T1/0 ds0-group 0 timeslots 1-24 
T1/1 ds0-group 0 timeslots 1-24 
T1/2 ds0-group 0 timeslots 1-24 
T1/3 ds0-group 0 timeslots 1-24 
  • If an MGCP message is rejected, it might be because the remote media gateway does not support SDP mandatory parameters (the o=, s=, and t= lines). If this is the case, configure the mgcp sdp simple command to send SDP messages without those parameters.
  • If you notice problems with voice quality, make sure that the cptone (voice-port configuration) command is set for the correct country code. Capturing RTP packets from the sniffer might help to debug the problem; you can decide such questions as whether the payload type or timestamps are set correctly.
  • To check operation of interfaces, use the show interface command.
  • To view information about activity on the T1 or E1 line, use the show controllers command. Alarms, line conditions, and other errors are displayed. The data is updated every 10 seconds; and every 15 minutes, the cumulative data is stored and retained for 24 hours.
  • When necessary, you can enable debug traces for errors, events, media, packets, and parser. The command debug mgcp packets can be used to monitor message flow in general. Note that there is always a performance penalty when using debug commands. The sample output below shows the use of the optional input-hex keyword to enable display of hexadecimal values.
Router# debug mgcp {all | errors | events | packets {input-hex}| parser} 
Router# debug mgcp packets input-hex  
Media Gateway Control Protocol input packets in hex value debugging is on 
MGCP Packet received - 
DLCX 49993 * MGCP 0.1 
MGCP Packet received in hex - 
44 4C 43 58 20 34 39 39 39 33 20 2A 20 4D 47 43 50 20 30 2E 31 A 
send_mgcp_msg, MGCP Packet sent ---> </nowiki> 
250 49993

Rating: 3.7/5 (3 votes cast)

Personal tools