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
15

People constantly have troubles understanding the Gatekeeper-based call routing model. In this post, we are going to discuss the basic call-routing logic. Reader is assumed to understand the most fundamental gatekeeper configuration commands.

Basic Concepts

The first concept is the gatekeeper technology-prefix, which is the core of the gatekeeper dynamic call-routing process. Look at the tech-prefix as a special label used to group together a set of VoIP gateways. The gateways may register their technology prefixes with the gatekeeper dynamically, or you can map the prefixes to the VoIP gateways statically. The gatekeeper looks at the gateways registered under the same tech-prefix to be members of a single “gateway pool”. Now, recall that tech-prefix is just a part of the dialed number. Whether the called number prefix is actually a technology prefix, is decided by the gatekeeper, when it matches the dialed number against the database of the local registered/configured prefixes. There is nothing in the dialed number itself, that designates the part of the dialer string as a technology prefix.

A special instance of tech-prefix is the default-techology prefix. When you have one or more tech-prefixes registered by gateways or configured statically, you can designate one of them as “default”. The gatekeeper will "route" the incoming call to this prefix if it cannot match the incoming call against any registered/configured tech-prefixes. Notice that this happens even though the dialed number prefix does not match any of the local technology prefixes.

The next concept is zone. A zone is a collection of destination numbers (dialing prefixes). Zones could be either local – serviced by this gatekeeper – or remote – serviced by remote gatekeepers. Zones are used for two purposes – admission control and call routing. For every incoming call, the gatekeeper need to determine the zones that the calling and called numbers belong to, in order to perform admission control. Note one important detail here – every gateway registers within a particular zone.

The last concept is zone bandwidth. This is a special attribute that you assign to a zone. When a call is placed between two zones or within the same zone, the gatekeeper first tries to reduce the current zone bandwidth by the bandwidth of the call. If source/target zones both have enough bandwidth, the call is admitted. This constitutes the core of GK-based admission control procedure.

Call Routing Process

Here is a simplified step-by-step description of the call-routing process. Note that it may not strictly follow the actual logic, but rather is outlined in the easy to understand manner.

Step 1:
A gateway sends ARQ to the gatekeeper, requesting admission for given calling and called numbers. The gatekeeper first determines the source zone, as where the calling gateways is registered. Gateways normally register within a zone, so there is no problem finding the source zone.

Step 2:
The gatekeeper tries to match the called number against the list of the registered or manually configured tech-prefixes.

a) If a match is found, the gatekeeper stores the matched tech-prefix.
b) The gatekeeper tries to match the called number with tech-prefix stripped against the list of all zone prefixes. (If the tech prefix was not found , the gatekeeper tries to match the original dialed string against the zone prefix list).

Step 3:
If there is a match found while looking up the zone prefix list, the gatekeeper has found the target zone. If there is no zone-prefix match, then the gatekeeper assumes the target zone to be the source zone, found in Step 1.

Step 4:
At this point gatekeeper attempts to perform a routing decision, based on the information collected: tech-prefix, zone-prefix and target zone.

a) If the target zone is remote-zone, then hop the call off to the remote gatekeeper, sending LRQ. The local GK no longer cares for this call. The call is hopped off as it was received, with unmodified called and calling numbers (including the tech-prefix). NOTE: This step does NOT require the called number to find a match within local tech-prefixes. Thus, if there is a tech-prefix in the called number, it is considered be the part of the number and matched against the zone prefixes.
b) Otherwise, the gatekeeper attempts to route the call locally, based on the tech-prefix. The gatekeeper constructs a pool of the gateways registered under the matched tech-prefix.
b.1) Verify if there are gateways in this pool registered under the target zone (remember, the zone is selected based on dialed prefix!). Only these gateways constitute the set of possible targets. Thus the pool of availale gateways is constructed as intersection of the gateways in the target zone registered under the matched tech-prefix.
b.2) If the called number did not match any tech-prefix at Step 1 try to see if there is a default tech-prefix configured. If there is one, then select the gateways registered with this prefix under the target zone. Note, that this allows call routing without a technology prefix prepended to the dialed number.

Step 5:
At this point the gatekeeper has the set of target gateways to probe for the called number. The gatekeeper will attempt to route the call to each of this gateways in sequence, based their associated priorities as follows. Setting priorities allows for granular selection of gateways within a pool. Look at the following example.

gatekeeper
zone prefix Z_HQ 1... gw-priority 10 GW_HQ_A
zone prefix Z_HQ 1... gw-priority 9 GW_HQ_B
gw-type-prefix 1# default-technology

Let’s assume that both GW_HQ_A and GW_HQ_B registered the same tech-prefix 1#, and the called number matches the zone prefix. When the gatkeeper tries to select the next gateway to handle the call, it picks up the one with the highest priority for the prefix. The default priority value is 5, and by setting the priority to zero you effectively exclude this gateway as being a potential target for this prefix. You may need this in situation where you have multiple gateways in the same zone sharing the same tech-prefix. Per default behavior, the gatekeeper simply tries the gateways in round-robin fashion based on the default priority value for every subsequent call attempt.

Step 6:
If there called number did not match any tech-prefix AND there is no default-tech prefix configured the gatekeeper tries to match the called number against the list of registered E.164 endpoints (terminals). If there is a match, the call is routed to the endpoint.

Step 7:
If the call is routable, the gatekeeper performs admission control procedure, based on the source/target zone bandwidth settings and the call bandwidth. If there is enough bandwidth, the call is admitted and the calling gateway receives the target IP address.

Example 1:
One local zone, one tech-prefix (1#), two gateways (GW_BR1, GW_BR2) in the pool.

R1:
gatekeeper
zone local Z_ZONE cisco.com
no shutdown

R2:
gateway
!
interface Loopback0
ip address 177.10.254.2 255.255.255.255
h323-gateway voip interface
h323-gateway voip id Z_ZONE ipaddr 177.10.254.1 1719
h323-gateway voip h323-id GW_BR1
h323-gateway voip bind srcaddr 177.10.254.2
h323-gateway voip tech-prefix 1#
!
dial-peer voice 100 voip
destination-pattern .T
session target ras

R3:
gateway
!
interface Loopback0
ip address 177.10.254.3 255.255.255.255
h323-gateway voip interface
h323-gateway voip id Z_ZONE ipaddr 177.10.254.1
h323-gateway voip h323-id GW_BR2
h323-gateway voip bind srcaddr 177.10.254.3
h323-gateway voip tech-prefix 1#
!
dial-peer voice 100 voip
destination-pattern .T
session target ras

Place a call from R3 (GW_BR2):

R1#debug gatek main 10

R3#debug h225 q931
H.225 Q931 IE Details debugging is on

R3#csim start 1000
csim: called number = 1000, loop count = 1 ping count = 0

csim err csimDisconnected recvd DISC cid(13)
csim: loop = 1, failed = 1
csim: call attempted = 1, setup failed = 1, tone failed = 0

As we can see, GW_BR2 did not even attempt to start a new call. The gatekeeper debugs reveal the following:

R1#
rassrv_get_addrinfo: (1000) Tech-prefix match failed.
rassrv_get_addrinfo: (1000) unresolved zone prefix, using source zone Z_ZONE
gk_rassrv_get_ingress_network: ARQ non-std ingress network = 1
rassrv_arq_select_viazone: about to check the source side, src_zonep=0x4797D0D0
rassrv_arq_select_viazone: matched zone is Z_ZONE, and z_invianamelen=0
rassrv_arq_select_viazone: about to check the destination side, dst_zonep=0x4797D0D0
rassrv_arq_select_viazone: matched zone is Z_ZONE, and z_outvianamelen=0
rassrv_get_addrinfo: No tech prefix

rassrv_get_addrinfo: Alias not found

rassrv_get_addrinfo: (1000) unknown address and no default technology defined.

In this case we ended up with no tech-prefix, source zone=target zone=Z_ZONE.

Now place a call prepended by the tech-prefix:

R3#csim start 1#1000
csim err csimDisconnected recvd DISC cid(14)

Q931 Message IE Decodes
Protocol Discriminator : 0x08
CRV Length : 2
CRV Value : 0x000E
Message Type : 0x05: SETUP
[snip]

R1#
rassrv_get_addrinfo: (1#1000) Matched tech-prefix 1#
rassrv_get_addrinfo: (1#1000) unresolved zone prefix, using source zone Z_ZONE
gk_rassrv_get_ingress_network: ARQ non-std ingress network = 1
rassrv_arq_select_viazone: about to check the source side, src_zonep=0x4797D0D0
rassrv_arq_select_viazone: matched zone is Z_ZONE, and z_invianamelen=0
rassrv_arq_select_viazone: about to check the destination side, dst_zonep=0x4797D0D0
rassrv_arq_select_viazone: matched zone is Z_ZONE, and z_outvianamelen=0
gk_rassrv_get_ingress_network: ARQ non-std ingress network = 1

As we can see, now the tech-prefix has matched, and the gatkeeper returns a gateway in ACF. GW_BR2 tries to place a call to the first gateway in sequence, as seen from Q931 debugging output. Every time you place another call, the gatekeeper will return a new gateway in sequence.

Example 2

Two local zones, two zone prefix, two tech-prefixes, two gateways.

R1:
gatekeeper
zone local Z_BR1 cisco.com
zone prefix Z_BR1 2...
zone local Z_BR2 cisco.com
zone prefix Z_BR2 3...
no shutdown

R2:
gateway
!
interface Loopback0
ip address 177.1.254.2 255.255.255.255
h323-gateway voip interface
h323-gateway voip id Z_BR1 ipaddr 177.1.254.1 1719
h323-gateway voip h323-id GW_BR1
h323-gateway voip bind srcaddr 177.1.254.2
h323-gateway voip tech-prefix 2#
!
dial-peer voice 100 voip
destination-pattern .T
session target ras

R3:
gateway
!
interface Loopback0
ip address 177.1.254.3 255.255.255.255
h323-gateway voip interface
h323-gateway voip id Z_BR2 ipaddr 177.1.254.1
h323-gateway voip h323-id GW_BR2
h323-gateway voip bind srcaddr 177.1.254.3
h323-gateway voip tech-prefix 3#
!
dial-peer voice 100 voip
destination-pattern .T
session target ras

We run the same debugs as in the first example.

First, we try placing a call using the tech-prefix registered in Z_BR1 and calling the prefix in Z_BR2:

R3#csim start 3#2001
csim: called number = 3#2001, loop count = 1 ping count = 0

csim err csimDisconnected recvd DISC cid(3)
csim: loop = 1, failed = 1
csim: call attempted = 1, setup failed = 1, tone failed = 0

The call fails, since the gatekeeper selects the gateway with tech-prefix in Z_BR2 and with the zone prefix in Z_BR1. Here is the gatekeeper output:

R1#
rassrv_get_addrinfo: (3#2001) Matched tech-prefix 3#
rassrv_get_addrinfo: (3#2001) Matched zone prefix 2 and remainder 001
gk_rassrv_get_ingress_network: ARQ non-std ingress network = 1
rassrv_arq_select_viazone: about to check the source side, src_zonep=0x469FCCC4
rassrv_arq_select_viazone: matched zone is Z_BR2, and z_invianamelen=0
rassrv_arq_select_viazone: about to check the destination side, dst_zonep=0x46D050D4
rassrv_arq_select_viazone: matched zone is Z_BR1, and z_outvianamelen=0
gk_rassrv_get_ingress_network: ARQ non-std ingress network = 1
rassrv_get_addrinfo: (3#2001) tech-prefix gateway selection failed.

Now, if you use the tech-prefix 2#, the call will go just fine:

R1#
rassrv_get_addrinfo: (2#2001) Matched tech-prefix 2#
rassrv_get_addrinfo: (2#2001) Matched zone prefix 2 and remainder 001
gk_rassrv_get_ingress_network: ARQ non-std ingress network = 1
rassrv_arq_select_viazone: about to check the source side, src_zonep=0x469FCCC4
rassrv_arq_select_viazone: matched zone is Z_BR2, and z_invianamelen=0
rassrv_arq_select_viazone: about to check the destination side, dst_zonep=0x46D050D4
rassrv_arq_select_viazone: matched zone is Z_BR1, and z_outvianamelen=0

R3#csim start 2#2001
csim: called number = 2#2001, loop count = 1 ping count = 0

csim err csimDisconnected recvd DISC cid(7)
Q931 Message IE Decodes
Protocol Discriminator : 0x08
CRV Length : 2
CRV Value : 0x0007
Message Type : 0x05: SETUP
Bearer Capability: Length Of IE=3

Example 3

Two gatekeepers (R1 and R3); local and remote zone; two tech-prefixes; two gateways (R2 and R3);

R1:
gatekeeper
zone local Z_BR1 cisco.com
zone prefix Z_BR1 2...
zone remote Z_BR2 cisco.com 177.1.254.3
zone prefix Z_BR2 3*
no shutdown

R2:
gateway
!
interface Loopback0
ip address 177.1.254.2 255.255.255.255
h323-gateway voip interface
h323-gateway voip id Z_BR1 ipaddr 177.1.254.1 1719
h323-gateway voip h323-id GW_BR1
h323-gateway voip bind srcaddr 177.1.254.2
h323-gateway voip tech-prefix 2#
!
dial-peer voice 100 voip
destination-pattern .T
session target ras

R3:
gatekeeper
zone local Z_BR2 cisco.com 177.1.254.3
zone prefix Z_BR2 3...
zone remote Z_BR1 cisco.com 177.1.254.1
zone prefix Z_BR1 2*
no shutdown
!
gateway
!
interface Loopback0
ip address 177.1.254.3 255.255.255.255
h323-gateway voip interface
h323-gateway voip id Z_BR2 ipaddr 177.1.254.3
h323-gateway voip h323-id GW_BR2
h323-gateway voip bind srcaddr 177.1.254.3
h323-gateway voip tech-prefix 3#
!
dial-peer voice 100 voip
destination-pattern .T
session target ras

When we call 3#3001 from R2, the gateway first asks R1 – its gatekeeper. The gatkeeper could not match this call against any tech-prefix, but it matches against the remote zone prefix 3*. The call is then hopped off to R2.

R2#csim start 3#3001

R1#
rassrv_get_addrinfo: (3#3001) Tech-prefix match failed.
rassrv_get_addrinfo: (3#3001) Matched zone prefix 3 and remainder #3001
gk_rassrv_get_ingress_network: ARQ non-std ingress network = 1
rassrv_arq_select_viazone: about to check the source side, src_zonep=0x46D050D4
rassrv_arq_select_viazone: matched zone is Z_BR1, and z_invianamelen=0
rassrv_arq_select_viazone: about to check the destination side, dst_zonep=0x469F7B38
rassrv_arq_select_viazone: matched zone is Z_BR2, and z_outvianamelen=0
rassrv_get_addrinfo: No tech prefix

rassrv_get_addrinfo: Alias not found

rassrv_put_remote_zones_from_zone_list: zone Z_BR2
send_lrq: seq_lrq 1, use_be 0, rzone_cnt 1
send_lrq: lrq array index 7, lap 476A807C
send_lrq: sent lrq - zonecount 1

Now LRQ reaches R3. This gatekeeper tries the usual call-routing procedure, matching the called number against the list of registered tech-prefixes. Then a match for the zone prefix is found in local zone. The gatekeeper only has to select the gateway from the pool.

R3#
gk_rassrv_lrq: (3#3001) Matched tech-prefix 3#
gk_rassrv_lrq: (3#3001) Matched zone-prefix 3
gk_rassrv_lrq: checking the source of the LRQ. source_endptp=0x0
gk_rassrv_lrq: srcvia found gkname of source zone. looking up Z_BR1 in zone list
gk_rassrv_lrq: about to check the source side, src_zonep=0x673FC104
gk_rassrv_lrq: matched zone is Z_BR1
gk_rassrv_lrq and z_invianamelen=0
gk_rassrv_lrq: about to check the destination side, zonep=0x650C63D0
gk_rassrv_lrq:matched zone is Z_BR2
gk_rassrv_lrq and z_outvianamelen=0

Now try making a call to 2#3001. In this situation, R1 should block the call for the tech-prefix and the zone prefix are in different zones. However, this rule only works for local zone. When the zone prefix match in remote zone, the gatekeeper immediately hops the call off, even if the tech prefix is registered locally.

R1#
rassrv_get_addrinfo: (2#3001) Matched tech-prefix 2#
rassrv_get_addrinfo: (2#3001) Matched zone prefix 3 and remainder 001
gk_rassrv_get_ingress_network: ARQ non-std ingress network = 1
rassrv_arq_select_viazone: about to check the source side, src_zonep=0x46D050D4
rassrv_arq_select_viazone: matched zone is Z_BR1, and z_invianamelen=0
rassrv_arq_select_viazone: about to check the destination side, dst_zonep=0x469F7B38
rassrv_arq_select_viazone: matched zone is Z_BR2, and z_outvianamelen=0
rassrv_put_remote_zones_from_zone_list: zone Z_BR2

send_lrq: seq_lrq 1, use_be 0, rzone_cnt 1
send_lrq: lrq array index 9, lap 476A810C
send_lrq: sent lrq - zonecount 1

R3#
gk_rassrv_lrq: (2#3001) Tech-prefix match failed.
gk_rassrv_lrq: (2#3001) Matched zone-prefix 2
gk_rassrv_lrq: checking the source of the LRQ. source_endptp=0x0
gk_rassrv_lrq: srcvia found gkname of source zone. looking up Z_BR1 in zone list
gk_rassrv_lrq: about to check the source side, src_zonep=0x673FC104
gk_rassrv_lrq: matched zone is Z_BR1

The call still fails, since R3 can not match the called number against any local tech-prefix.

Summary

As we can see, the core of the gatekeeper call-routing is using tech-prefixes for gateway pooling and using zones and zone prefixes to partition the pools. We omitted some advanced details, such as RAI and hop-off tech-prefixes for clarify. However, the general process looks as described above.

Further Reading

Understanding Cisco IOS Gatekeeper Call Routing
VoIP with Gatekeeper
Basic Two Zone Cisco Gateway-to-Gatekeeper Configuration
Zone Prefix Processing with Dots Versus Asterisks

Subscribe to INE Blog Updates

New Blog Posts!