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

  • Troubleshooting Voice: MGCP — Part 2
  • Call Control Discovery via Service Advertisement Framework — Part 3 of 6
  • Call Control Discovery via Service Advertisement Framework — Part 2 of 6
  • 18 Month Plan Released for CCNA-to-CCIE Voice
  • Now Any Desktop Can Join Cisco Telepresence Video Conference for Free
  • 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.

    3 Responses to “Troubleshooting Voice: MGCP – Part 1”

     
    1. Terrence says:

      Will you break down traces when you go through the series. That is where I see the most problems at, how to setup tracing, capture a call and read through the trace. I have a method down, but i’m sure it can be done more efficient and I would love to see how someone else approches reading traces.

    2. ananth says:

      Great Series Mark. Glad to see great ideas coming up in Voice domain.

     

    Leave a Reply

    Categories

    CCIE Bloggers