Cisco Unified Communications Manager and Unity Connection: Configuring Class of Service and Call Admission Control

Implementing Call Admission Control

After you have set up your system to allow calls to be placed to outside destinations and have applied CSS and partitions to restrict access, you need to configure the system to ensure the quality of the calls. Although there are many things that can affect the quality of the call, this book deals only with things that can be configured directly in Communications Manager. The following sections discuss what must be configured to ensure that the Voice over Internet Protocol (VoIP) link is not over subscribed.

When calls are placed between sites using an IP link as the transport, the quality of the call can be affected if more calls are allowed than what the link can support. To prevent this, some type of Call Admission Control must be deployed. How this is accomplished depends on the environment. If the calls are being sent across intercluster trunks, a gatekeeper is required. If calls are being placed to remote sites that are part of the same cluster, locations are used. If both types of calls are taking place, both solutions must be deployed.

Locations are objects that are configured within Communications Manager. A location for each site is created that contains available bandwidth for calls. A closer look at the configuration of locations is offered later in this chapter. Before looking at locations, gatekeepers are examined.

Configuring CAC for a Distributed Deployment

A gatekeeper is a process that runs on a Cisco IOS router. It keeps track of the active calls between clusters and determines whether a call can be placed across an intercluster trunk. In most cases, only one gatekeeper is needed because each can support more than a 100 sites. It is recommended, however, to have a redundant gatekeeper. This can be accomplished by having a second router running Hot Standby Routing Protocol (HSRP) or by implementing gatekeeper clustering. The only requirement for the physical location of a gatekeeper is that all clusters must reach it through an IP path.

When a call is placed across a gatekeeper-controlled H.225 or intercluster trunk, the Communications Manager on the originating side asks the gatekeeper whether the call can be placed. If there is enough bandwidth, the gatekeeper grants admission. If admission is granted, call setup begins, and the Communications Manager on the other side of the call must request admission. If the gatekeeper determines that there is enough bandwidth, admission is granted and the call setup is complete.

A gatekeeper grants admission based upon availability of configured bandwidth. The gatekeeper is configured with the amount of bandwidth that can be used for calls. Each time a call is placed, the gatekeeper removes a certain amount from the available bandwidth. When the call is over, it returns the bandwidth to the available pool.

The amount of bandwidth required for each call depends on which codec is being used. The gatekeeper has the preconfigured amount of bandwidth that each codec requires, and this number cannot be changed. This figure might not be the actual bandwidth the call needs, but is used to ensure that enough bandwidth is available. A gatekeeper running IOS 12.2(2)XA or later assumes that 128 kbps is needed for G7.11 calls and 16 kbps is required for G.729 calls. Although it might seem odd that the gatekeeper might request more or less bandwidth than it needs, it isn't a problem because the amount of available bandwidth is a setting that you configure in the gatekeeper. The gatekeeper does not have the ability to monitor the link and decide whether there is available bandwidth. It relies totally on the number that is configured. It is best to determine the amount of calls you want to allow on the link and the codec that will be used. Then simply multiply the amount of bandwidth the gatekeeper uses for that codec by the number of calls. The result is the amount of bandwidth that should be configured. For example, if the gatekeeper is running IOS version 12.2(2)XA or later and you want to allow ten calls all using the G.729 codec, the formula is 10 x 16 (10 calls x 16 kbps), which means that 160 kbps will be needed.

The gatekeeper can also be configured to provide the destination IP address to which the call should be sent. This feature is sometimes referred to as an anonymous device. An anonymous device is preferred in many environments, especially those with multiple intercluster trunks. When more than two clusters are connected, an intercluster trunk must be created between each cluster if an anonymous device is not used. Figure 5-11 shows that when connecting four clusters, 12 intercluster trunks are required.

Figure 5-11 Intercluster Trunks

The formula used to determine how many intercluster trunks are required is N x (N–1). That is the number of clusters times the number of clusters minus 1. In Figure 5-11, there are four clusters. This means that the total number of intercluster trunks is 4 x (4–1) or 4 x 3, which equals 12. As the number of clusters increases so does the number of required trunks. For example, with four clusters, 12 intercluster trunks are needed, but with eight clusters, 56 intercluster trunks are needed. This is where an anonymous device becomes extremely useful. Instead of creating all the intercluster trunks, just one gatekeeper-controlled intercluster trunk is created, and all calls destined to any of the other clusters are sent to this trunk. When the gatekeeper responds to an admission request, it also provides the IP address of the destination.

Because the gatekeeper is going to provide destination information, it must know the destination IP address. This is part of the configuration that must be done on the gatekeeper itself. The bandwidth allowed for calls must also be configured in the gatekeeper to give you an idea of what needs to be configured. The following example shows a partial configuration:

gatekeeper
zone local DTW bgd.com 10.10.12.28
zone prefix DTW 4...
gw-type-prefix 1#* default-technology
bandwidth total zone DTW 256
no shutdown

A complete explanation of this configuration can be found in the article "Configuring H.323 Gatekeepers and Proxies" on Cisco.com. However, to give you an idea of what this configuration is achieving, the third command, "zone prefix DTW 4...," denotes that calls in the 4000 range can be handled by the DTW gatekeeper. The fifth command, "bandwidth total zone DTW 256," means that the total amount of bandwidth available for calls to and from DTW is 256 kbps.

Configuring a Gatekeeper

In addition to the required configuration on the gatekeeper itself, the gatekeeper must also be configured in the Communications Manager. Adding a gatekeeper in Communications Manager is quite simple. The following steps show how this is done:

• Step 1. From within CCMAdmin, select Device > Gatekeeper.
• Step 2. Click the Add New link.
• Step 3. A screen similar to that shown in Figure 5-12 displays. Enter the IP address of the gatekeeper in the Host Name/IP Address field.
  

  Figure 5-12 Gatekeeper Configuration

• Step 4. In the Description field, enter a description that helps to identify this gatekeeper.
• Step 5. The Registration Request Time to Live field should be left at the default. Change this field only if the Cisco Technical Assistance Center (TAC) tells you to do so. This field determines how often the Communications Manager must send a registration keepalive to the gatekeeper.
• Step 6. The Registration Retry Timeout field should be left at the default. Change this field only if TAC tells you to do so. This value determines how long Communications Manager waits before trying to register after a registration attempt fails.
• Step 7. Typically, the Enable Device check box should be left selected. This allows the gatekeeper to register with Communications Manager. When you need to gracefully unregister the gatekeeper, deselect this box.
• Step 8. Click Save.

After a gatekeeper is configured, you must create a gatekeeper-controlled intercluster trunk so that the calls placed across the intercluster trunk request admission from the gatekeeper. This also allows you to take advantage of the anonymous device features if the gatekeeper is configured to provide call-routing information. Creating a gatekeeper-controlled intercluster trunk is similar to creating a nongatekeeper-controlled intercluster trunk.

Configuring a Gatekeeper-Controlled Trunk

The steps required to configure a gatekeeper-controlled H.225 trunk and a gatekeeper-controlled intercluster trunk are similar. The following steps show how to configure a gatekeeper-controlled intercluster trunk and explain its various settings:

• Step 1. From within CCMAdmin, select Device > Trunk
• Step 2. Click the Add New link.
• Step 3. On the next page, select Inter-Cluster Trunk (Gatekeeper Controlled) from the Trunk Type drop-down list.
• Step 4. The Device Protocol field can be left at Inter-Cluster Trunk. No other option is available. Click the Next button.
• Step 5. The Trunk Configuration screen, as shown in Figure 5-13, displays. Enter a functional name for the gateway in the Device Name field.
  

  Figure 5-13 Trunk Configuration

• Step 6. In the Description field, enter a description that makes this device easily identifiable.
• Step 7. From the Device Pool drop-down list, select the desired device pool for this gateway.
• Step 8. From the Common Device Configuration drop-down list, select the common device configuration that the trunk will use.
• Step 9. From the Call Classification drop-down list, select whether incoming calls on this device should be considered OnNet or OffNet. This parameter is used to determine whether calls can be transferred and forwarded. This is to help prevent fraud.
• Step 10. The next field is the Media Resource Group List. It determines the accessibility of media resources to a device. These are discussed further in Chapter 6, "Configuring CUCM Features and Services."
• Step 11. Information entered in the Location field is used to prevent WAN links from becoming oversubscribed in centralized deployments. If you have defined locations, select the appropriate one for this device from the drop-down list.
• Step 12. The AAR Group field determines the appropriate association of this device with an AAR group. An AAR group provides the prefix that is assigned when a call fails because of insufficient bandwidth. AAR is discussed in further detail in Chapter 6. Select an AAR group if AAR is being used. If this field is set to None, AAR is, in effect, disabled on this device.
• Step 13. The Tunneled Protocol drop-down list allows you to select Q Signaling (QSIG), which enables intercluster trunk (ICT) to transport non-H.323 protocol information by tunneling it through H.323. Leave this set to None, unless you know that this type of tunneling is required.
• Step 14. The QSIG Variant parameter is only configurable if QSIG is selected as the tunnel protocol. Leave this parameter alone unless Cisco TAC instructs you to change it.
• Step 15. The ASN.1 ROSE OID Encoding parameter is only configurable if QSIG is selected as the tunnel protocol and is beyond the scope of this book.
• Step 16. The next two fields, Packet Capture Mode and Packet Capture Duration, are for troubleshooting purposes only and should not be configured when adding a new trunk.
• Step 17. The Media Termination Point Required check box needs to be selected if the H.323 device does not support features such as hold and transfers.
• Step 18. If the Retry Video Call as Audio box is selected, Communications Manager sets up a voice call if a video calls fails to set up.
• Step 19. The Path Replacement Support check box is automatically selected if you select QSIG from the Tunneled Protocol drop-down list. Otherwise it is left deselected.
• Step 20. If the Transmit UTF-8 for Calling Party Name check box is left deselected, the user locale setting in the device pool will be used to determine whether Unicode information is sent and translated. Typically this can be left at the default.
• Step 21. The Unattended Port check box is used to indicate that the device has unattended ports. This is normally used if the port is used to send calls to an application such as a voicemail server. In most cases, this box should be left deselected.
• Step 22. If you want to allow both secure and nonsecure calls on this gateway, you must select the SRTP Allowed check box. If this is not selected, only nonsecure calls are allowed.
• Step 23. If the H.235 Pass Through Allowed check box is selected, the shared-secret key can pass through a CM, allowing H.323 endpoints to set up a secure connection.
• Step 24. The Use Trusted Relay Point field determines whether a relay point such as a Media Termination Point (MTP) or a transcoder must be labeled trusted to be used by this device. This field is typically only changed in virtualized environments.
• Step 25. If the Cisco Intercompany Media Engine feature is being used and calls through this trunk might reach the PSTN, make sure the that PSTN Access check box is selected.

Intercompany Media Engine

• Step 26. E.164 transformation profiles are used when Intercompany Media Engine (IME) is used. IME enables different companies to automatically learn routes, which enables calls to travel across the Internet instead of the PSTN.

Incoming Calling/Called Party Settings

• Step 27. The Incoming Calling Party Settings and Incoming Called Party Settings are used to globalize numbers. Each calling and called party number has a number type assigned to it. The incoming calling/called part settings are based on the number type assigned. There are four number types: national, international, unknown, and subscriber. The four settings for each of these number types are
  • Prefix: Digit enters are added to the beginning of the number after the specified number of strip digits are removed.
  • Strip Digits: This is the number of digits that should be stripped from the number before the prefix is applied.
  • Calling Search Space: This is the CSS that is used after transformation has occurred.
  • Use Device Pool CSS: When this box is selected, the device pool CSS is used.

  If your environment requires the manipulation of incoming called and calling numbers, configure the appropriate settings for each of these fields.

• Step 28. The next two fields define the Multilevel Precedence and Preemption (MLPP) characteristics of this gateway. If these fields are left blank or set to default, the values set in the device pool are used. The first MLPP field is the MLPP Domain. MLPP grants higher priority only from calls with the same MLPP domain. If MLPP is used, an MLPP domain is needed; otherwise, this field can be left at None.
• Step 29. The second field in this category, MLPP Indication, determines whether tones and indications will be presented when a precedence call is made. If the is field set to Off, no precedence indication is presented. If this field is set to On, indication is used for a precedence call.

Call Routing Information—Inbound Calls

• Step 30. The next set of fields refers to inbound calls. The Significant Digits field determines the number of digits of an incoming dialed number that Communications Manager uses. Communications Manager counts from right to left. So if the number entered in this field is 4 and the digits received are 8105559090, 810555 would be removed. Only 9090 would be used to determine the destination of this call.
• Step 31. A Calling Search Space (CSS) determines the accessible destinations of inbound calls. Choose a CSS from the Calling Search Space drop-down list. If this field is left at None, the dialing privileges of this gateway could be limited.
• Step 32. Automated Alternate Routing (AAR) is used to provide an alternate route if a call fails because of insufficient bandwidth. The AAR CSS can be used to limit the paths a call can use when it is rerouted. Select an AAR CSS from the AAR Calling Search Space drop-down list.
• Step 33. The Prefix DN field defines what digits are added to the front of an incoming destination number. This is applied to the number, after Communications Manager truncates the number, based on the Significant Digits setting.
• Step 34. The Redirecting Number IE Delivery–Inbound check box should be selected if your voicemail system supports redirecting number IE. Otherwise, leave this box deselected.
• Step 35. If the Enable Inbound FastStart check box is selected, FastStart will be used. H.323 FastStart requires only two message exchanges to open logical channels, whereas normal setup requires 12. However, if FastStart is selected, both ends must support and be configured for FastStart.

Call Routing Information—Outbound Calls

• Step 36. Called party transformation enables you to change the number that is dialed. Select the Called Party Transformation CSS that contains the called party transformation patterns that should be applied to calls routed through the trunk. You can also leave this set to None and use the Called Party Transformation CSS assigned to the device pool by selecting the Use Device Pool Called Party Transformation CSS check box.
• Step 37. Calling party transformation enables you to change the caller ID. Select a Calling Party Transformation CSS that contains the calling party transformation pattern that is assigned to the device. You can also leave this set to None and use the Calling Party Transformation CSS assigned to the device pool by selecting the Use Device Pool Calling Party Transformation CSS check box.
• Step 38. The Calling Party Selection field determines what number is sent for outbound calls. The choices are
  • Originator: The directory number of the device that placed the call.
  • First Redirect Number: The directory number of the first device to redirect the call.
  • Last Redirect Number: The directory number of the last device to redirect the call.
  • First Redirect Number (External): The external directory number of the first device to redirect the call.
  • Last Redirect Number (External): The external directory number of the last device to redirect the call. Select the desired value for this field.
• Step 39. The Calling Line ID Presentation field determines whether Communications Manager sends caller ID information. To send caller ID information, select Allowed from the drop-down list. To block caller ID, select Restricted from the drop-down list.
• Step 40. Cisco recommends that the next four fields remain set to the default of Cisco CallManager. The four fields are
  • Called party IE number type unknown
  • Calling party IE number type unknown
  • Called Numbering Plan
  • Calling Numbering Plan

  These fields deal with dial plan issues and should be changed only when advised to do so by Cisco or an experienced dial plan expert. The need to change these usually occurs when installing Communications Manager internationally.

• Step 41. The Caller ID DN field is used to determine what caller ID is sent out of this gateway. A mask or a complete number can be entered in this field. For example, if the mask 55536XX is entered in this field, Communications Manager sends 55536 and the last two digits of the calling number.
• Step 42. If the Display IE Delivery check box is selected, the calling and called party name information is included in messages.
• Step 43. The Redirecting Number IE Delivery-Outbound check box should be selected when integrating with a voicemail system that supports redirecting number IE. Otherwise, leave it deselected.
• Step 44. If the Enable Outbound FastStart check box is selected, FastStart will be used. H.323 FastStart requires only two message exchanges to open logical channels, whereas normal setup requires 12. However, if FastStart is selected, both ends must support and be configured for FastStart.
• Step 45. If the Enable Outbound FastStart check box is selected, you must select the codec that is to be used. This is selected from the Codec for Outbound FastStart drop-down list.

Gatekeeper Information

• Step 46. From the Gatekeeper Name drop-down list, select the desired gatekeeper.
• Step 47. The Terminal Type field specifies the type of devices this trunk controls. Choose Gateway for normal trunks.
• Step 48. The Technology Prefix field enables you to assign a prefix that matches the prefix in the gatekeeper. By assigning a matching prefix, you can avoid having to add the IP address of each Communications Manager in the gatekeeper on the gw-type-prefix line. It is recommended that you use 1#* in both this field and the gatekeeper configuration. The value entered in this field must exactly match what is configured in the gatekeeper.
• Step 49. The Zone field determines which zone this Communications Manager registers with on the gatekeeper. If this field is left blank, the gatekeeper's zone subnet command is used to determine to what zone the Communications Manager registers. If you enter a zone name in this field, it must match exactly with what is configured in the gatekeeper (this includes capitalization).

Geolocation Configuration

• Step 50. The geolocation information can be used to determine the logical partition of a device. If you are using the geolocation feature, select the appropriate geolocation from the Geolocation drop-down list.
• Step 51. There are 17 configurable geolocation fields. Geolocation filters enable you to choose which fields are used to create a geolocation identifier. If you use the geolocation feature, select the appropriate geolocation filter from the Geolocation Filter drop-down list.
• Step 52. Click Save.

After the gatekeeper-controlled intercluster trunk is configured, you can add it to a route group. Then configure a pattern that matches calls that should be routed over this trunk. The pattern should point to a route list that contains the route group of which this trunk is a member.

Configuring CAC for a Centralized Deployment

To accomplish CAC for environments that have remote sites, locations are configured in Communications Manager. Locations define the amount of bandwidth that can be used to place calls to and from the remote sites. After locations are configured, they must be assigned to devices such as phones, trunks, and gateways. You can accomplish this by assigning them to a device pool. This process enables the phones, trunks, and gateways' device pool to determine the location. When a call is placed across the IP WAN, Communications Manager uses the location information to determine whether there is enough available bandwidth for the call. By deducting available bandwidth for each call that is active on the WAN, Communications Manager can determine availability. When using locations, Communications Manager assumes that the following bandwidth is required for each codec:

• A G.711 call uses 80 kbps.
• A G.722 call uses 80 kbps.
• A G.723 call uses 24 kbps.
• A G.728 call uses 16 kbps.
• A G.729 call uses 24 kbps.
• A GSM call uses 29 kbps.
• A wideband call uses 272 kbps.

To better understand locations, now look at the steps required to create and apply them.

Creating Locations

The following steps show how to create a location:

• Step 1. From within CCMAdmin, select System > Location.
• Step 2. Click the Add New link.
• Step 3. A screen similar to that shown in Figure 5-14 displays. Enter the name of the location in the Name field.
  

  Figure 5-14 Location Configuration

• Step 4. In the Audio Bandwidth field, enter the amount of bandwidth available for voice calls to and from this location. If you select the Unlimited radio button, no limit is placed on voice calls. To determine the value to enter here, take the bandwidth that Communications Manager used for each call based on the codec that is being employed, and multiply it by the number of calls that you know can safely traverse the link. For example, if you use G.729 and you know that ten calls can traverse the link, multiply 24 kbps by 10. This tells you that 240 should be entered in this field. The bandwidth that Communications Manager assumes for each codec is listed earlier in this section.
• Step 5. In the Video Bandwidth field, enter the amount of bandwidth available for video calls to and from this location. If you select the Unlimited radio button, no limit is placed on video calls. You can also select the None radio button, which prohibits video calls.

  NOTE

  Video bandwidth is in increments of the video codec. If video codec is 384 and two video calls are allowed, the bandwidth should be set to 768.

• Step 6. Resource Reservation Protocol (RSVP) can be used to reserve bandwidth for calls. The RSVP settings can be determined by highlighting a location in the Modify Setting(s) to Other Locations section and selecting the desired RSVP setting from the RSVP Setting drop-down list.
• Step 7. Click the Save. The location has been added when the status line reads Insert Completed.

Assigning a Location to Devices

After locations are added, you must assign them to devices. As stated earlier, it is recommended that the location information be assigned to the device pool. The following steps show how to assign a location to a device pool:

• Step 1. From within CCMAdmin, navigate to System > Device Pool.
• Step 2. To limit the results, enter search criteria in the search field, and click Find.
• Step 3. Select the device pool to which you want to assign a location from the list that is generated.
• Step 4. Select a location from the Location drop-down list.
• Step 5. Click Save.
• Step 6. The device pool must be reset. Click Reset.
• Step 7. A new window will appear; click Reset in the new window.
• Step 8. Close the Device Reset window.

If you want to assign the location at the device level, follow these steps. The steps to add a location to a phone, trunk, or gateway are all similar. The following steps can be used to add a location to any of these devices:

• Step 1. The path you select from within CCMAdmin depends on which type of device you are assigning a location. To assign a location to a phone, select Device > Phone. To assign a location to an ICT, select Device > Trunk. To assign a location to a gateway, select Device > Gateway.
• Step 2. To limit the results, enter search criteria in the search field, and click Find.
• Step 3. Select the device to which you want to assign a location from the list that is generated.
• Step 4. If configuring an MGCP gateway, select the endpoint to which you want to assign a location. If you are not configuring an MGCP gateway, skip this step.
• Step 5. The Device Configuration screen displays. Select a location from the Location drop-down list, as shown in Figure 5-15. Figure 5-15 shows a phone configuration screen, but the screen should be similar regardless of the device that you are configuring.
  

  Figure 5-15 Assigning a Location to a Device

• Step 6. Click Save.
• Step 7. A window displays informing you that you must click the Apply Config button for the change to take affect. Click OK.
• Step 8. Click Apply Config.
• Step 9. A window displays warning you that when you apply the configuration, the device might go through a restart. Click OK.

That's all there is to it. Unlike gatekeeper, no additional configuration is required outside of Communications Manager. Communications Manager handles all the CAC functions itself when locations are used for remote sites.