E.164 Number Resolution

Call Admission Control

Call admission control (CAC) is important to the successful implementation of an IP voice network. If the amount of bandwidth required to support active calls exceeds that which is available on the network, voice quality suffers for all calls. Several mechanisms are available to provide CAC services. The methods selected depend heavily on the overall design of the network. Available CAC mechanisms include CallManager location-based CAC and Resource Reservation Protocol (RSVP). You can also configure the Cisco gatekeeper to provide CAC on an H.323 network.

The gatekeeper maintains a record of all active calls so that it can manage the bandwidth in a zone. When calculating whether enough bandwidth is available to accept a call ARQ, the gatekeeper uses the following formula:

Available bandwidth = (Total allocated bandwidth) x (Bandwidth used locally) x (Bandwidth used by all alternates)

If the available bandwidth is sufficient for the call, an ACF is returned; otherwise, an ARJ is sent.

When you configure bandwidth control, you need to consider the coder/decoder (codec) in use for the call, Layer 2 encapsulation, and compression techniques (such as RTP header compression) that are in use.

You can request bandwidth changes if necessary after call setup. As of Cisco IOS Release 12.2(2)XA and later, Cisco voice gateways can request a bandwidth change if the codec in use changes. Prior to this release, calls were always reported to require a bandwidth of 64 Kb, the unidirectional bandwidth for a G.711 codec. Cisco IOS Release 12.2(2)XA and later conform to H.323 Version 3 specification, and the reported bandwidth is bidirectional. Initially, 128 Kb of bandwidth is reserved for the call using a G.711 codec, or 16 Kb for a call using the G.729 codec. If a change in bandwidth is required during the call, the gateway notifies the gatekeeper of a bandwidth change using a BRQ message.

You handle Cisco CallManager CAC for voice calls in the same way that you handle CAC for Cisco IOS voice gateways. A difference is that CallManager also can place video calls. When you are designing a CAC implementation that includes video endpoints such as those on CallManager, you must also take the video bandwidth into account. With CallManager, the bandwidth requested from the gatekeeper for a video call is two times the bit rate of the calla 384-Kb video call counts as 768 Kb, a 512-Kb video call counts as 1024 Kb, and so on. Besides limiting the total available bandwidth, you can limit the maximum bandwidth that a single call can request. This is useful when video is also present on the network. CallManager is discussed more fully later in this chapter.

You can configure the following types of zone bandwidth controls on a Cisco gatekeeper:

• The maximum bandwidth for all traffic between the local zone and a specified remote zone. You can set up this limitation individually for multiple remote zones.
• The maximum bandwidth for all traffic from a zone to all remote zones.
• Perform a check of the destination gateway bandwidth before responding to the ARQ (Cisco IOS Release 12.3(1) and later).
• The maximum bandwidth for a single session within the local zone. As mentioned, this is typically used for video traffic and not voice.

It is important to consider the network topology when planning gatekeeper-controlled CAC implementations.

Figure 16-7 shows an example of an implementation over a simple network topology. In this example, the WAN connection between New York and Boise can only support two calls because of bandwidth limitations. If you are using the G.729 codec, you could configure the gatekeeper to limit the bandwidth to 32 kbps. The first two calls would complete successfully. The third call would exceed the bandwidth limitation and be denied.

Figure 16-7. Simple CAC Implementation

Unfortunately, most networks are not as simple as the one shown in Figure 16-7. A more complex scenario would be to have separate gateways at multiple locations with differing WAN bandwidths between locations. In our sample network, the New York location can handle 24 simultaneous calls; the Boise location can handle two calls; the Leeds location can handle four simultaneous calls.

You could set the bandwidth limits based on the site with the least capacity within the zone. In this example, you would set the gatekeeper to allow only two concurrent calls, based on the capacity at the Boise location. This would ensure good voice quality, but you would place inefficient limits on the other locations that can handle more calls.

A better approach would be to set up multiple gatekeeper zones. If you set up a single zone per site, you could have much more control over the bandwidth allocation. Figure 16-8 depicts the interzone bandwidth limits.

Figure 16-8. Complex Multizone CAC Implementation

The configuration shown limits the traffic in various ways:

• Between New York and Leeds to four calls maximum
• Between New York and Boise to two calls maximum
• Between Leeds and Boise to two calls maximum

In this configuration, you are ensuring good voice quality and making the best use of the available bandwidth at each site. The gatekeepers shown are logical, not physical. You can control the zones from a single physical gatekeeper.

As you can see from this example, when you are designing gatekeeper-based CAC on an H.323 network, it is important to consider all aspects of the network topology: paths to destination; bandwidth to destination; and the number of gateways that can reach the destination. The gatekeeper is not aware of the topology of the network. Decisions about whether or not to admit a call are based solely on static configurations and calculations of available versus used bandwidth. For gatekeeper CAC to function correctly, the network must be laid out in a hub-and-spoke design. Alternate paths are not taken into account. Other CAC mechanisms such as CallManager location-based CAC have the same limitations. Although using these methods is much better than not implementing CAC, RSVP can make dynamic CAC decisions based on currently available bandwidth along the selected path to a destination. If RSVP is available on your network, it can be a better choice for implementation of CAC.