Mar
19

I just finished up 2 weeks of a really great CCNP Voice bootcamp, covering all 5 of the latest 8.0 version exams from Cisco (CVOICE, CIPT1, CIPT2, CAPPS, & TVOICE). All in all we ended up with 62 completely brand-new hours of informative video that we are sure you will be excited to watch when they are posted to our streaming and download sites here in probably just about a week. We went fairly in-depth on most every topic, one of them being MGCP during our TVOICE section of class.

BTW, with this new 62 hours of CCNP Voice video, this brings INE to 320 hours of total CCNA-to-CCIE Voice video-on-demand training. Far, far more than any other vendor. And it is all up-to-date and taught by me, not by subcontracted instructors.

You may recall that in my last post related to MGCP Troubleshooting, we took a basic look at the MGCP commands that a Call-Agent (server) instructs a Gateway (client) to preform – something the RFC refers to as “verbs”.

In this post, we are going to take a look at the output of the “debug mgcp packets” command for a single call, and then break down each section of the output into “transactions” (i.e. Command and Response).


So to begin with, here is the complete output a of single call from “debug mgcp packet”:



ISDN Se0/0/0:23 Q931: RX <- SETUP pd = 8  callref = 0x00FF
        Bearer Capability i = 0x8090A2
                Standard = CCITT
                Transfer Capability = Speech
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA18381
                Preferred, Channel 1
        Progress Ind i = 0x8583 - Origination address is non-ISDN
        Display i = 'Seattle US Phone'
        Calling Party Number i = 0x4180, '2065015111'
                Plan:ISDN, Type:Subscriber(local)
        Called Party Number i = 0xC1, '2065011002'
                Plan:ISDN, Type:Subscriber(local)

MGCP Packet received from 177.1.10.12:2427--->
CRCX 256 S0/SU0/DS1-0/3@corphq.voice.ine.com MGCP 0.1
C: D0000000028182cf000000F500000015
X: 3
L: p:20, a:G.729, s:off, t:b8, fxr/fx:t38
M: recvonly
R: D/[0-9ABCD*#]
Q: process,loop
<---

MGCP Packet sent to 177.1.10.12:2427--->
200 256 OK
I: 31

v=0
o=- 49 0 IN IP4 177.1.254.1
s=Cisco SDP 0
c=IN IP4 177.1.254.1
t=0 0
m=audio 18714 RTP/AVP 18 100
a=rtpmap:18 G.729/8000
a=fmtp:18 annexb=no
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
<---

ISDN Se0/0/0:23 Q931: TX -> CALL_PROC pd = 8  callref = 0x80FF
        Channel ID i = 0xA98381
                Exclusive, Channel 1

ISDN Se0/0/0:23 Q931: TX -> ALERTING pd = 8  callref = 0x80FF
        Progress Ind i = 0x8088 - In-band info or appropriate now available

MGCP Packet received from 177.1.10.10:2427--->
RQNT 257 S0/SU0/DS1-0/1@Branch2 MGCP 0.1
X: 1
R: D/[0-9ABCD*#]
S: G/rt
Q: process,loop
<---

MGCP Packet sent to 177.1.10.10:2427--->
200 257 OK
<---

ISDN Se0/0/0:23 Q931: TX -> CONNECT pd = 8  callref = 0x80FF
ISDN Se0/0/0:23 Q931: RX <- CONNECT_ACK pd = 8  callref = 0x00FF

MGCP Packet received from 177.1.10.12:2427--->
MDCX 258 S0/SU0/DS1-0/3@corphq.voice.ine.com MGCP 0.1
C: D0000000028182cf000000F500000015
I: 31
X: 3
L: p:20, a:PCMU, s:off, t:b8, fxr/fx:t38
M: sendrecv
R: D/[0-9ABCD*#], FXR/t38
S:
Q: process,loop

v=0
o=- 49 0 IN EPN S0/SU0/DS1-0/3@corphq.voice.ine.com
s=Cisco SDP 0
t=0 0
m=audio 18214 RTP/AVP 0
c=IN IP4 177.1.11.26
a=X-sqn:0
a=X-cap:1 image udptl t38
<---

MGCP Packet sent to 177.1.10.12:2427--->
200 258 OK
<---

ISDN Se0/0/0:23 Q931: RX <- DISCONNECT pd = 8  callref = 0x00FF
        Cause i = 0x8290 - Normal call clearing

MGCP Packet received from 177.1.10.12:2427--->
MDCX 259 S0/SU0/DS1-0/3@corphq.voice.ine.com MGCP 0.1
C: D0000000028182cf000000F500000015
I: 31
X: 3
M: recvonly
R: D/[0-9ABCD*#]
Q: process,loop
<---

MGCP Packet sent to 177.1.10.12:2427--->
200 259 OK
<---

MGCP Packet received from 177.1.10.12:2427--->
DLCX 260 S0/SU0/DS1-0/3@corphq.voice.ine.com MGCP 0.1
C: D0000000028182cf000000F500000015
I: 31
X: 3
S:
<---

MGCP Packet sent to 177.1.10.12:2427--->
250 260 OK
P: PS=974, OS=155840, PR=981, OR=156960, PL=1, JI=3, LA=0
<---

 
 
So now just looking at the first transaction, we see an Inbound call (thanks to the inclusion of the 'debug isdn q931' output) and that the call-agent (UCM) instructs the gateway to "CRCX" or "CreateConnection", and the Gateway responds with very simple "200 OK", while also including the SDP (IETF Session Description Protocol) pertaining to such things as audio codec and DTMF. Notice how after each call-agent instructed verb (command) and gateway response there is a 3 digit number that corresponds. This is the transaction number, and use of it essentially ensures that the response is specific to the command (as there may be many commands and responses being issued on a heavily populated MGCP gateway). We can clearly see in this initial command that the call-agent is instructing the use of the "a:G.729" audio codec on the "L" line, and the gateway is obliging with the SDP response that will use the RTP/AVP (Audio Video Profile) codec number 18, G.729 without Annex B. More on this line reveals other things about the call such as "p" being the packet or sampling size of 20ms, "s" being VAD, "t" being the RFC 2474 ToS/DSCP bits (b8 is hex for 10111000 or DSCP EF), and fax capabilities. You also might note that the gateway was instructed to "M: recvonly" or as far as the "connectionMode" is concerned, that the gateway should only Receive packets, not send them. The "C" line is the global CallID and the "X" line is essentially the local callID. The "R" line is the supported DTMF.


MGCP Packet received from 177.1.10.12:2427--->
CRCX 256 S0/SU0/DS1-0/3@corphq.voice.ine.com MGCP 0.1
C: D0000000028182cf000000F500000015
X: 3
L: p:20, a:G.729, s:off, t:b8, fxr/fx:t38
M: recvonly
R: D/[0-9ABCD*#]
Q: process,loop
<---

MGCP Packet sent to 177.1.10.12:2427--->
200 256 OK
I: 31

v=0
o=- 49 0 IN IP4 177.1.254.1
s=Cisco SDP 0
c=IN IP4 177.1.254.1
t=0 0
m=audio 18714 RTP/AVP 18 100
a=rtpmap:18 G.729/8000
a=fmtp:18 annexb=no
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
<---

 
 
The next transaction shows us the ISDN is telling us the phone out on the PSTN is now alerting (ringing) and the MGCP Request Notify tells the gateway with the "S" line to play the "rt" or ringback tone.


ISDN Se0/0/0:23 Q931: TX -> ALERTING pd = 8  callref = 0x80FF
        Progress Ind i = 0x8088 - In-band info or appropriate now available

MGCP Packet received from 177.1.10.10:2427--->
RQNT 257 S0/SU0/DS1-0/1@Branch2 MGCP 0.1
X: 1
R: D/[0-9ABCD*#]
S: G/rt
Q: process,loop
<---

MGCP Packet sent to 177.1.10.10:2427--->
200 257 OK
<---

 
 
In this next transaction we see the ISDN output showing that the call is now connecting and the MGCP output that the call-agent us informing the gateway to "MDCX" or "ModifyConnection" again, this time to change its RTP connectionMode to send and receive packets "M: sendrecv". This is where the call was answered, and audio now commences.


ISDN Se0/0/0:23 Q931: TX -> CONNECT pd = 8  callref = 0x80FF
ISDN Se0/0/0:23 Q931: RX <- CONNECT_ACK pd = 8  callref = 0x00FF

MGCP Packet received from 177.1.10.12:2427--->
MDCX 258 S0/SU0/DS1-0/3@corphq.voice.ine.com MGCP 0.1
C: D0000000028182cf000000F500000015
I: 31
X: 3
L: p:20, a:PCMU, s:off, t:b8, fxr/fx:t38
M: sendrecv
R: D/[0-9ABCD*#], FXR/t38
S:
Q: process,loop

v=0
o=- 49 0 IN EPN S0/SU0/DS1-0/3@corphq.voice.ine.com
s=Cisco SDP 0
t=0 0
m=audio 18214 RTP/AVP 0
c=IN IP4 177.1.11.26
a=X-sqn:0
a=X-cap:1 image udptl t38
<---

MGCP Packet sent to 177.1.10.12:2427--->
200 258 OK

 
 
In this next transaction we see from the ISDN output that the call is being disconnected and the call-agent is informing the gateway to "MDCX" or "ModifyConnection" again, this time to change its RTP connectionMode back to receive only. This is the call-agent prepping the gateway that the call is being torn down.


ISDN Se0/0/0:23 Q931: RX <- DISCONNECT pd = 8  callref = 0x00FF
        Cause i = 0x8290 - Normal call clearing

MGCP Packet received from 177.1.10.12:2427--->
MDCX 259 S0/SU0/DS1-0/3@corphq.voice.ine.com MGCP 0.1
C: D0000000028182cf000000F500000015
I: 31
X: 3
M: recvonly
R: D/[0-9ABCD*#]
Q: process,loop
<---

MGCP Packet sent to 177.1.10.12:2427--->
200 259 OK
<---

 
 
In this final (and immediately following the previous) section, we see the call-agent instructing the gateway to "DLCX" or "DeleteConnection". The gateway obliges, and also provides some useful statistics (ConnectionParameters to be specific) about the call, namely "P: PS=974, OS=155840, PR=981, OR=156960, PL=1, JI=3, LA=0". (PS=PacketsSent, OS=OctetsSent, PR=PacketsReceived, OR=OctetsReceived, PL=PacketsLost, JI=Jitter, LA=Latency). BTW, if we had anything such as no audio or a one-way audio issue, we could clearly see that by either both PS & PR or in the case of only one-way audio only PS or PR having a value of 0 (no packets sent and/or received).


MGCP Packet received from 177.1.10.12:2427--->
DLCX 260 S0/SU0/DS1-0/3@corphq.voice.ine.com MGCP 0.1
C: D0000000028182cf000000F500000015
I: 31
X: 3
S:
<---

MGCP Packet sent to 177.1.10.12:2427--->
250 260 OK
P: PS=974, OS=155840, PR=981, OR=156960, PL=1, JI=3, LA=0
<---

 
 
Seeing as we have just covered SDP, it will only make sense to move on to looking as SIP, as it uses SDP for audio information as well.

 

Related Posts

  • Troubleshooting Voice: MGCP -- Part 1
  • Call Control Discovery via Service Advertisement Framework -- Part 3 of 6
  • Call Control Discovery via Service Advertisement Framework -- Part 2 of 6
  • Voice Toll-Fraud Caveats -- No VoIP Traffic by Default!
  • 18 Month Plan Released for CCNA-to-CCIE Voice
  • About Mark Snow, CCIE #14073:

    Mark Snow has been actively working with data and traditional telephony as a Network Consulting Engineer since 1995, and has been working with Cisco Call Manager and voice-over technology since 1998. Mark has been actively teaching and developing content for the CCIE Voice track since 2005, and the Security track since 2007. Mark's story with both data and voice technology started out quite young, as he began learning around the age of five from his father who was a patented inventor and a research scientist at AT&T Bell Laboratories. Mark started out on Unix System V and basic analog telephony, and went on from there to large data networking projects with technologies such as Banyan Vines, IPX and of course IP, and large phone systems such as Nortel 61c, Tadiran Coral, Avaya Definity and of course Cisco Unified Communications Manager in both enterprise and 911 PSAP environments across the US and internationally. Mark is also an accomplished pilot and punched his ticket in 2001. When Mark isn't learning, labing, consulting or teaching, he can be found either piloting or possibly jumping out of a perfectly good airplane, hanging off a rock somewhere or else skiing out west. He also might just be enjoying a quiet day at the beach with his wife and two wonderful young kids, Ryleigh and Judah.

    Find all posts by Mark Snow, CCIE #14073 | Visit Website


    You can leave a response, or trackback from your own site.

    12 Responses to “Troubleshooting Voice: MGCP – Part 2”

     
    1. Anestis Koukis says:

      Hello Mark,

      thank you for this helpful post.
      Also I’ m very interesting for the CCIE Voice troubleshooting bootcamp but for the record version of it.

      Best Regards

      Anestis

    2. Fae Benbenek says:

      I’ve thought about writing something about this on my site. Good job!

    3. Terrence says:

      the CCIE V troubleshooting bootcamp would be great. I would deff watch it as I prefer to go at my own speed when watching videos.

    4. s1else says:

      What direction you’re calling. I found something weird. If I call from IP Phone to PSTN Phone the MDCX(sendrecv) will come before PSTN phone answered. Can you explain it?

    5. [...] by Mark Snow, CCIE #14073 in CCIE Voice,CCNP Voice TweetI will shortly be resuming the series I began on troubleshooting, but in the interim I have been getting a lot of emails from people regarding one of the newest [...]

    6. Asad Yaseen says:

      Thanks mark …..appreciated great efforts….

    7. Kasamasi says:

      Hi Mark,

      Nice post on MGCP and Thanks much! Can you post the next session on breaking down each section of the output into “transactions” (i.e. Command and Response).

      Thanks.

    8. Edgar says:

      Excellent!! Excellent!!

     

    Leave a Reply

    Categories

    CCIE Bloggers