blog
    Troubleshooting Voice: MG ...
    19 March 12

    Troubleshooting Voice: MGCP - Part 2

    Posted byMark Snow
    facebooktwitterlinkedin
    news-featured

    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

    %RELATEDPOSTS%

    Hey! Don’t miss anything - subscribe to our newsletter!

    © 2022 INE. All Rights Reserved. All logos, trademarks and registered trademarks are the property of their respective owners.
    instagram Logofacebook Logotwitter Logolinkedin Logoyoutube Logo