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

%RELATEDPOSTS%

Jan
25

Over the coming weeks I will be running a new series here on Troubleshooting Voice. I often have students in class that report to me that one of the most difficult parts of their CCIE Voice exam experience was having to deal with the inner workings of some of the protocols and how to read and decipher them accurately. I have also begun to see this more and more across the various mailing lists and forums, and so I decided it was time to start an entire series on these not-to-be-feared topics. Since these protocols are covered quite in-depth in the CCNP Voice course (most specifically in the CVOICE portion), I highly encourage people starting out in Unified Communications, not to skip the lower level courses, and to really dig in at that CCNA Voice and then CCNP Voice level, before going into the CCIE Voice. At each level something is presented that is not explained at the next level, so it really is crucial to go through each progression of the track in a sequential and systematic order. This goes especially for those who might already have a CCIE, and think they understand what the CCIE is all about. They probably understand very well what the exam itself is all about, however the underlying Voice technologies are quite vastly different than the data world they may be used to. In fact, I hear this quite a lot from people making the jump from a R&S IE to the Voice side of the realm - "Man, this Voice stuff is totally different!".

To begin with, we will start out a bit easy, and go over the basics of everyone's favorite client/server gateway protocol - MGCP or "Media Gateway Control Protocol".

MGCP has a series of commands that are exchanged between the client and the server. In the basic Cisco UC world (basic meaning enterprise side of things rather than the carrier side), the client ('gateway') is almost always an IOS voice-enabled router, and the server ('call agent') is always the Unified Communications Manager (UCM).

Here are the basic commands that are used to exchange messages between call-agent and gateway:

Connection Commands

  • CRCX = CReate Connection
  • DLCX = DeLete Connection
  • MDCX = MoDify Connection

Audit Commands

  • AUEP = AUdit EndPoint
  • AUCX = Audit Connection

Request Command

  • RQNT = Request for Notification

Endpoint Command

  • EPCF = EndPoint ConFiguration

Notify Command

  • NTFY = Notify

Restart Command

  • RSIP = ReStart In Progress

 

Now, let's look at each command in a bit more detail.

Connection Commands

Three messages are used by a call-agent to manage an RTP connection on a media gateway

CRCX = CReate Connection

  • In this message the call-agent instructs the gateway to establish a connection with an endpoint. The parameters in the CReateConnection provide the what is necessary to build an understanding of each connection. The parameters include the codec, packetization period, QoS marking, usage of echo cancellation, silence suppression, gain control, RTP security, and resource reservations.
DLCX = DeLete Connection
  • This message informs the recipient to delete a connection. The call agent or the gateway can issue the command. The gateway or the call agent issues the command to advise that it no longer has the resources to sustain the call. As a side effect, the call agent collects statistics on the execution of the connection. The statistics include number of packets sent, received, and lost, interarrival jitter, and average transmission delay.
MDCX = MoDify Connection
  • This message instructs the gateway to update its connection parameters for a previously established connection. The call agent issues the command. The parameters used are the same as in the CreateConnection command, with the addition of a ConnectionID that identifies the connection within the endpoint.


Audit Commands

Two messages are used by a call-agent to query the status of a media gateway

AUEP = AUdit EndPoint
  • This message requests the status of an endpoint. Information that can be audited with this command includes RequestedEvents, DigitMap, SignalRequests, RequestIdentifier, QuarantineHandling, NotifiedEntity, ConnectionIdentifiers, DetectEvents, ObservedEvents, EventStates, BearerInformation, RestartMethod, RestartDelay, ReasonCode, PackageList, MaxMGCPDatagram, and Capabilities. The response will include information about each of the items for which auditing info was requested.

AUCX = Audit Connection

  • This message simply requests the status of a connection.

Request Command

One message is used by a call-agent to request a notification of events on a media gateway

RQNT = Request for Notification

  • This message instructs the media gateway to watch for events on an endpoint and the action to take when they occur, such as fax tones. The call-agent may then decide to specify use of a different type of encoding method should be used and instruct the gateway to change with a ModifyConnection command.

 

Endpoint Command

One message is used by a call-agent to manage a media gateway

EPCF = EndPoint ConFiguration

  • The EndpointConfiguration command can be used to specify the encoding of the signals that will be received by the endpoint, such as A-law or mu-law. The call-agent can use the EndpointConfiguration command to pass this information to the media gateway.


Notify Command

One message is used by the media gateway to notify the call-agent about an event which the call-agent requested notification about

NTFY = Notify

  • This message informs the call-agent of an event for which a notification was requested. A single notification message may carry an entire list of events that the gateway detected and accumulated.


Restart Command

One message is used by the media gateway to tell the call-agent that it is in the process of restarting

RSIP = ReStart In Progress

  • This message tells the call-agent that the gateway and its endpoints are removed from service or are being placed back in service. The message carries an EndPointId to identify the endpoint(s) that are put in-service or out-of-service. The RestartMethod parameter specifies the type of restart.
  • The various RestartMethods are defined as:
    • "Graceful" restart method indicates that the specified endpoints will be taken out-of- service after the specified delay.
    • "Forced" restart method indicates that the specified endpoints are taken abruptly out- of-service. The established connections, if any, are lost.
    • "Restart" method indicates that service will be restored on the endpoints after the specified "restart delay,"that is, the endpoints will be in-service. The endpoints are in their clean default state and there are no connections that are currently established on the endpoints.
    • "Disconnected" method indicates that the endpoint has become disconnected and is now trying to establish connectivity. The "restart delay" specifies the number of seconds the endpoint has been disconnected. Established connections are not affected.
    • "Cancel-graceful" method indicates that a gateway is canceling a previously issued "graceful" restart command. The endpoints are still in-service.

 

Here is a brief visual aid I quickly put together to help put some of these commands into a bit of perspective as to when each is sent and what function it serves:
In our next post, we will explore how these messages interact in a much more in-depth fashion, between the call-agent and the gateway, with the aid looking at debug output from a live UCM and IOS MGCP gateway.Throughout this series, we will be taking a look at virtually every protocol that is used in the Cisco UC network, so be sure to check back regularly for the complete set.

Troubleshooting MGCP Part II here

 

Related Posts

%RELATEDPOSTS%

Jan
27

The Cisco Unified Communications feature called Mobile Connect (also familiarly referred to as Single Number Reach) is truly a great feature of Unified Communications Manager, and can provide us with many efficiencies both in being able to be reachable just about anywhere, and in being able to be easily identified when placing inbound calls from our mobile phones into the CUCM cluster to our colleagues. As admins, we know that if we wish to have our users place calls from their mobile phones inbound to their colleagues inside the CUCM cluster, that we need to match up all or at least part of their inbound calling party number (CLID) to their CUCM Remote Destination. But what happens when what the carrier is sending CLID digits inbound to our IOS voice gateways that differs significantly from our Remote Destinations in CUCM, especially if we have truly embraced Cisco's push toward true Globalization in v7.0, v8.0 & v8.5?

The fact is that many, if not most European carriers (as well as many more all over the world) send CLID in through an ISDN PRI into the enterprise gateway with a preceding "0" as a courtesy  digit for easy recognition and ease in dialing back out, since this "0" is very commonly used as a carrier-recognized national dialing prefix. If we were speaking of the US and Canada, this "0" we are speaking of would be akin to dialing a "1" prior to the national number. Now in the US and Canada, if a carrier in the US sent CLID into a gateway with a "1" preceding any 10 digit number, this would work fine since the US/Canada country code also happens to be "1". However, the "0" preceding a variable length number is not valid in a true E.164 number format (e.g. If you dialed the phone number from outside of whatever country we were talking about, you would omit that preceding 0 from your dialed digits).

So what are we to do to get our inbound CLID to match our RD's?

That is exactly what we will explore here today in video format, as you watch a very small excerpt from our video-based solutions to one of the many new labs we will have in our new CCIE Voice Volume I & II workbooks.

Click here for the 25 minute video discussion on "The Trouble with European MGCP Gateways and Mobile Connect Inbound Calling Party Matching".

(BTW, if the video starts off with a bit of an echo, just hit CTRL-R to refresh the stream. And then stay tuned to this blog for some very exciting announcements about new formats for video solutions in the very near future)

Happy Labbing,

Mark

Subscribe to INE Blog Updates

New Blog Posts!