Troubleshooting Voice: MGCP - Part 1
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:
- CRCX = CReate Connection
- DLCX = DeLete Connection
- MDCX = MoDify Connection
- AUEP = AUdit EndPoint
- AUCX = Audit Connection
- RQNT = Request for Notification
- EPCF = EndPoint ConFiguration
- NTFY = Notify
- RSIP = ReStart In Progress
Now, let's look at each command in a bit more detail.
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.
- 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.
- 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.
Two messages are used by a call-agent to query the status of a media gateway
- 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.
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.
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.
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.
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.