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

This chapter examines the various concepts associated with CoS and CAC and describes how to configure the required components for each.

Now that you have created a basic dial plan, it is time to build on that and create a more complete dial plan. Often you want to allow and disallow access to certain destinations. For example, you might want only a certain group of callers to dial international numbers. This is done by creating a telephony class of service (CoS). In addition, if there are calls traversing limited-bandwidth links, some type of Call Admission Control (CAC) should be deployed to help ensure voice quality. This chapter examines the various concepts associated with CoS and CAC and describes how to configure the required components for each.

Rights and Restrictions

After the dial plan is created and users can place calls to destinations outside the cluster, you might think that you are all set and can sit back and relax. Not quite. After the system is configured to enable calls to be placed outside of the system, you need to start working on how to prevent certain calls from being placed. This chapter touches on how you can use route patterns to block certain destinations, and now you need to move beyond that and discuss how certain destinations can be reachable by some devices, but not by others. To accomplish this, you need to configure Calling Search Spaces (CSS) and partitions. The following sections explain what these are and how they work.

Understanding Call Search Spaces and Partitions

Of all the concepts within a Communications Manager environment, it is believed that the CSS and partitions cause the most confusion. This is rather odd because they are not complex. Simply put, the partition assigned to the destination affects what devices can reach it, and the CSS determines which destinations can be reached. Locks and key rings are good analogies. Think of the partition as a lock and the CSS as the key ring. To place a call to a destination, you must have a key that matches the device's lock. The key ring contains all the keys and therefore determines which destinations you can reach.

Of course, there is more to it than just locks and keys, but by using this analogy, you begin to understand how they work. You take a closer look at this analogy. Figure 5-1 shows five phones. The first four phones have partitions (locks). It is important to point out that the partitions (locks) are not assigned to devices, but rather to patterns and directory numbers (DN). For this example, assume that each phone has only a single line and that the partition (lock) is assigned to that line. Below each phone is a CSS (key ring) that shows to which partitions (locks) the phone has access. CSS (key rings) can be assigned to the device or the line. In this example, assume that they are assigned to the device.

The locks in this figure have different-shaped keyholes, which means that to open a lock, you must have a key ring that has the correct-shape key. Keeping in mind that the locks represent partitions and that the key rings represent CSS, answer the following questions:

• What phones can phone A reach?
• What phones can phone D reach?
• What phone can reach all other phones?
• What phones can reach phone E?
• What phones can phone E reach?

The answers to these questions are as follows:

• Q. What phones can phone A reach?

  A. To determine what phones phone A can reach, you need to look at its CSS (key ring). Phone A has a circular key and a square key on its key ring, which means that it can call itself and phone B. However, because phone E has no lock (partition) assigned to it, any phone can reach it, just as a door with no lock can be opened by anyone.

• Q. What phones can phone D reach?

  A. Because phone D has only a square key, it can dial phone A and, of course, phone E because it has no lock (partition).

• Q. What phone can reach all other phones?

  A. Because phone B has a key ring (CSS) that contains all the keys, it can reach all the devices.

• Q. What phones can reach phone E?

  A. Because phone E has no lock (partition), all phones can reach it.

• Q. What phones can phone E reach?

  A. Because phone E has no keys, it can only reach devices that have no locks. In this example, phone E can only dial itself.

Figure 5-1, along with these questions and answers, should help you begin to understand how partitions and CSS work. Of course, as with any simple concept, it has the potential to become more complicated as the number of CSS and partitions grows. This is where some people begin to become confused, because of an inaccurate base understanding of the concepts. Now look at some of the more interesting aspects of CSS and partitions.

The first misconception that should be dispelled is this: If two devices have the same partition, they can call each other. Having the same partition alone is not enough. Going back to the lock and key ring analogy, if two people have the same locks, keyed the same way on their houses, but they have no keys, can they access each other's houses? Of course they can't, and they cannot even access their own houses. This demonstrates that a device's partition (lock) has no effect on where the device can call. However, if two devices that have the same partition also have a CSS that enables them access to their partitions, they can dial each other.

The next important point is the order of CSS. As demonstrated in the earlier example, CSS can enable access to more than one partition. Now, imagine that a device has a CSS that enables it to match two devices with the same number, but in different partitions. Figure 5-2 offers an example of this situation.

In this example, phones A and D have the same extension of 1001. Phones B and C can reach both phones because their CSS enables access to both the square and triangle partition. So the question is, which phone rings when phone C dials 1001? Often people answer this question with, "It takes the closer match." Because 1001 matches 1001 exactly, both phones are the closest matches. Others assume that both phones ring because phone C has access to both partitions. What actually happens is that when a search for a match is conducted, multiple closest matches are found. Because there are multiple closest matches, the order in which objects appear in the CSS comes into play. When you create a CSS, you prioritize the order in which partitions should be searched. This order determines which partition is used if there are two closest matches. In the example, Figure 5-2 shows that the order of the keys for phone C is square followed by triangle, meaning that when phone C dials 1001, it would first match the 1001 that has the square partition, which is phone A.

To add a little more complexity to this, it is possible to have a CSS on both the device and the line. For example, the phone can have a CSS that grants access to the square partition, and a line on the phone can have a CSS that grants access to the triangle partition. In such a case, the line CSS takes priority. Figure 5-3 shows an example of this. This example moves away from the locks and keys analogy to focus more on the actual terms.

In Figure 5-3, phone A has two lines, 1001 and 1010. 1001 has no CSS, and line 1010 has a CSS that grants access to devices in the executive partition. Phone A also has a CSS at the device level, which enables access to devices in the lobby and employee partitions. Because the 1001 line does not have a CSS of its own, it has access only to devices that can be reached using the device's CSS. Because line 1010 has a CSS of its own, it has access to devices that can be reached using its CSS and the device's CSS. This means that when dialing from line 1001, only devices in the lobby and employee partitions are accessible; but when dialing from line 1010, devices in the lobby, employee, and exec partitions are accessible.

Now, take a look at the other three phones. Phone B has the extension of 1004, and that line is in the employee partition. Phone C has the extension of 1003, and that line is in the lobby partition. Phone D has the extension of 1004, and that line is in the exec partition.

Using what you have learned, answer the following three questions:

• What is the result if 1004 is dialed from line 1001?
• What is the result if 1004 is dialed from line 1010?
• Can line 1010 reach line 1003?

The answers to these questions are as follows:

• Q. What is the result if 1004 is dialed from line 1001?

  A. Because line 1001 has no CSS of its own, it relies solely on the device's CSS. The device's CSS has access to the employee and lobby partitions, so line 1001 can reach only the 1004 on phone B because it is in the employee partition.

• Q. What is the result if 1004 is dialed from line 1010?

  A. Because line 1010 has a CSS, it has access to all devices to which the line and device's CSS grants access. Because it can reach phones B and D and both of them match 1004, the line's CSS takes priority and phone D rings.

• Q. Can line 1010 reach line 1003?

  A. Line 1010 can reach any device to which the line and/or the device's CSS grants access. Because the device's CSS has access to the lobby partition, which is the partition that 1003 is in, it can reach it.

At this point, you should have a good idea of how partitions and CSS work. We now take a look at a real-world, practical example of how CSS and partitions can be used.

The BGD Company has deployed a Communications Manager solution and has configured the route patterns that are shown in Table 5-1. As you can see, the route patterns enable callers to reach anywhere they need to dial with the exception of 1-900 numbers, which are blocked. The problem is that these patterns also enable some callers to make unauthorized calls that the company disapproves of. For example, if a person's job does not require the placement of international calls, the dial plan should not enable the employee's phone to place them.

Table 5-1. BGD's Route Patterns

Pattern	Notes	Matches
9.[2-9]XXXXXX 9.810[2-9]XXXXXX	PreDot Discard PreDot Discard	Local 7- and 10-digit calls
9.810586XXXX 9.810587XXXX	PreDot Discard PreDot Discard	10-digit calls that are not local
9.1[2-9]XX[2-9]XXXXXX	PreDot Discard	Long-distance calls
9.011! 9.011!#	PreDot Discard PreDot Trailing-# Discard	International calls
9.1900[2-9]XXXXXX	Block Pattern	1-900 numbers
911 9.911	Urgent Priority PreDot Discard and Urgent Priority	Emergency service calls

In this example, BGD has decided that it actually has four classes of users. The first class, the executives, can make any calls they want, other than 1-900 calls. The second class, the administrative assistants, are not allowed to make 1-900 calls or international calls. The third class, standard users, can only reach internal extensions, local numbers, and emergency services. The fourth class, lobby phones, for example, can only make calls internally and to emergency services. To accomplish this, partitions and CSS must be configured and assigned to patterns and devices.

When creating partitions, a common practice is to name them so that the name describes to what the partition is assigned. For example, a partition that is going to be assigned to a pattern that matches a local number can be called Local PT.

In this example, five types of calls are allowed: internal, local, long-distance, international, and emergency. The following is the list of partitions that are needed, and to which patterns they are assigned:

• Internal_PT: Patterns that match internal numbers
• Local_PT: Patterns that match local numbers
• LD_PT: Patterns that match long-distance numbers
• International_PT: Patterns that match international numbers
• Emergency_PT: Patterns that match emergency service numbers

After the partitions are created, CSS are needed. Because BGD has defined four classes of users, four CSS are needed. Just as with partitions, it is recommended that CSS are named so that the name helps identify to which partitions the CSS have access. Table 5-2 shows the CSS and the partitions to which each has access and that are needed for BGD.

Table 5-2. CSS and Associated Partitions

CSS	Partitions
Internal_CSS	Internal_PT Emergency_PT
Internal_Local_LD_CSS	Internal_PT Local_PT Emergency_PT
Internal_CSS	Internal_PT Local_PT LD_PT Emergency_PT
Unlimited_CSS	Internal_PT Local_PT LD_PT International_PT Emergency_PT

Now that partitions and CSS are defined, take a look at what each is assigned to. First, examine the partitions. You need to understand that partitions are assigned to patterns of DNs, not devices. This means that if you want to prevent a device from making long-distance calls, you assign a partition to the patterns that match long-distance numbers, and make sure that the device's CSS does not have access to the partition. Table 5-3 shows the five partitions that have been created and the patterns to which each is assigned.

Table 5-3. Partitions and Patterns

Partitions	Patterns
Internal_PT	DNs of the phones
Local_PT	9.[2-9]XXXXXX 9.810[2-9]XXXXXX
LD_PT	9.810586XXXX 9.810587XXXX 9.1[2-9]XX[2-9]XXXXXX
International_PT	9.011! 9.011!#
Emergency_PT	911 9.911

You might notice that the 9.1900[2-9]XXXXXX pattern has not been assigned to a partition but will still work. Remember, if a pattern does not have a partition explicitly assigned, it falls into the null partition, and all devices have access to the null partition. Because the 9.1900[2-9]XXXXXX pattern is set up so that it blocks all calls that match it, you want all devices to have access to it so that no one can place these types of calls. However, it is recommended to apply partitions to all patterns to ensure that no calls can be placed by phones that do not have the proper CSS. With this is mind, the Internal_PT partition can be applied to the 9.1900[2-9]XXXXXX pattern because all devices can reach that partition.

Now look at how the CSS should be assigned. Remember that CSS can be assigned at both the device and line. For this example, they are assigned at the device level only. Table 5-4 shows the CSS and the types of device to which each is assigned.

Table 5-4. CSS and Assigned Devices

CSS	Devices
Unlimited_CSS	Executive phones
Internal_Local_LD_CSS	Administrative assistant phones
Internal_Local_CSS	Standard users
Internal_CSS	Lobby phones

Now that you understand which CSS and partitions are needed for BGD, and where each is applied, take a look at the big picture. Table 5-5 shows which CSS is assigned to each of the four different classes of phones. Under the CSS heading is a list of the partitions that can be accessed. Under the partitions is a list of patterns. Using this table, it is easy to see what destinations various phones can reach.

Table 5-5. CSS Assigned to Phones and the Patterns They Can Reach

Device	CSS>Partition>Patterns
Executive phones	Unlimited_CSS Internal_PT All Internal Phones Local_PT 9.[2-9]XXXXXX 9.810[2-9]XXXXXX LD_PT 9.810586XXXX 9.810587XXXX 9.1[2-9]XX[2-9]XXXXXX International_PT 9.011! 9.011!# Emergency_PT 911 9.911
Administrative assistant phones	Internal_Local_LD_CSS Internal_PT All Internal Phones Local_PT 9.[2-9]XXXXXX 9.810[2-9]XXXXXX LD_PT 9.810586XXXX 9.810587XXXX 9.1[2-9]XX[2-9]XXXXXX Emergency_PT 911 9.911
Standard user phones	Internal_Local_CSS Internal_PT All Internal Phones Local_PT 9.[2-9]XXXXXX 9.810[2-9]XXXXXX Emergency_PT 911 9.911
Lobby phones	Internal_CSS Internal_PT All Internal Phones Emergency_PT 911 9.911

Up to this point, only the assigning of CSS to phones and lines has been discussed. CSS are assigned to devices, which include gateways. A CSS is assigned to a gateway so that inbound calls can reach internal destinations. In the example of BGD, all the internal phones are placed in the Internal_PT partition. If the gateways do not have access to this partition, no incoming calls are allowed. So you can see that not only must phones have CSS, but gateways require them as well. In the case of BGD, the Internal_CSS can be assigned to the gateways, which would grant outside calls access to all internal phones.

In the BGD example, all internal phones were in the Internal_PT partition, meaning that because all devices had a CSS that granted access to the Internal_PT partition, all phones could be reached. In some cases, this is undesirable. Sometimes there are certain numbers that should be reached only by certain devices. An example often used is that of an executive's phone. Often it is desired that only the executive's assistant be able to reach the executive. To accomplish this, the executive's phone is placed in a separate partition, to which only the assistant's phone has access.

Now that you have a good idea of what CSS and partitions are, move on to discussing how they are created and configured.

Creating Calling Search Spaces and Partitions

Creating CSS and partitions is much easier than understanding and properly applying them. Before you move on to the process of creating them, you should make sure that you have taken the time to determine the different classes of users your environment has, and what destinations each user will be allowed to call. After you have done this, create a list of the partitions that are required. Next, create a CSS that defines what partitions are accessible. After you have created this, you can begin to create the partitions and CSS. Because CSS are created by choosing partitions to which they will have access, the partitions must be created first. The following steps show how to create partitions:

• Step 1. From within CCMAdmin, select Call Routing > Class of Control > Partition.
• Step 2. Click the Add New link.
• Step 3. A screen displays that offers an area in which you can enter the name of the partition followed by a description. You must place a comma (,) between the name and description. If you do not enter a description, the name of the partition will be used as the description. You can create up to 75 partitions at a time on this screen by placing each on a new line. Figure 5-4 shows an example of adding five partitions at one time.
  

  Figure 5-4 Creating Partition Configurations

• Step 4. After you enter all the desired partitions, click Save.

As you can see, the creation of partitions is a simple task. Now that partitions are added, you can start to create CSS by working through the following steps:

• Step 1. From within CCMAdmin, select Call Routing > Class of Control > Calling Search Space.
• Step 2. Click the Add New link.
• Step 3. A screen similar to that shown in Figure 5-5 displays.
  

  Figure 5-5 Creating CSS

• Step 4. Enter a name in the Calling Search Space Name field. Remember that the name should help identify the purpose of this CSS.
• Step 5. Enter a description in the Description field.
• Step 6. A list of partitions displays in the Available Partitions box. If you have a large number of partitions, you can limit the partitions that display in this list by entering the appropriate search criteria in the Find Partitions Where fields and clicking Find.
• Step 7. Highlight the first partition to which you want the CSS to have access, and click the Down Arrow below this box. This causes that partition to display in the Selected Partitions box.
• Step 8. Repeat Step 7 for each partition to which you want the CSS to have access. These should be added in the order you want to have them searched.
• Step 9. After all the partitions have been added, you can change the order in which they display. Remember, the order in which they display determines which partition is used if multiple partitions within the same CSS contain exact matches for a dialed number. To change the order, highlight the partition you want to move, and click the Up or Down Arrow to the right of the box. Figure 5-6 shows what the screen looks like when adding the Internal_Local_CSS, which was used in the previous example.
  

  Figure 5-6 Example CSS

• Step 10. After all desired partitions are listed in the correct order in the Selected Partitions box, click Save.

You need to repeat these steps to add all the CSS that your environment requires. After all the partitions and CSS are added, it is time to apply them. Adding partitions and CSS have absolutely no effect on call processing until they are applied to patterns and devices.

Applying Calling Search Spaces and Partitions

You are now ready to start applying the partitions and CSS to devices and patterns. After a partition is added to a pattern, only devices that have the correct CSS can reach that pattern. For this reason, you might want to assign CSS to the devices before assigning partitions. Assigning partitions before assigning CSS is similar to putting a lock on a door and not giving anyone a key. Until the keys are handed out, no one can get in.

CSS are applied to devices and lines. When applied to both, the line's CSS has priority but does not nullify the devices. This means a line that has its own CSS has access to partitions that both the line's CSS and the device's CSS allow.

Now take a look at how a CSS is assigned to a phone, a line on the phone, and a gateway.

Assigning a CSS to a Phone

The steps that follow show how to assign a CSS to a phone:

• Step 1. From within CCMAdmin, Select Device > Phone.
• Step 2. Enter search criteria in the search field to limit the results and click Find.
• Step 3. Select the phone to which you want to assign a CSS from the list that is generated.
• Step 4. The Phone Configuration screen displays. To assign a CSS to the phone, select a CSS from the Calling Search Space drop-down list, as shown in Figure 5-7.
  

  Figure 5-7 Assigning a CSS to a Phone

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

Assigning a CSS to a Line

The steps that follow show how to assign a CSS to a line on a phone:

• Step 1. From within CCMAdmin, select Device > Phone.
• Step 2. Enter search criteria in the search field to limit the results and click Find.
• Step 3. Select the phone that contains the desired line from the list of phones that is generated.
• Step 4. Click the desired line on the left side of the screen.
• Step 5. On the Directory Number Configuration page, select the desired CSS from the Calling Search Space drop-down list, as shown in Figure 5-8.
  

  Figure 5-8 Assigning a CSS to a Line

• Step 6. Click Save.

Assigning a CSS to a Gateway or Trunk

The steps that follow show how to assign a CSS to a gateway or a trunk. Because the steps are so similar for both components, they have been combined.

• Step 1. From within CCMAdmin, select Device > Gateway or Device > Trunk.
• Step 2. Enter search criteria in the search field to limit the results, and click Find.
• Step 3. From the list that is generated, select the gateway/trunk to which you want to assign a CSS.

  NOTE

  When configuring CSS for Session Initiation Protocol (SIP) trunks, additional CSSs are configured. In the Inbound Call section, select the desired AAR CSS from the AAR Calling Search Space drop-down list. Under the Outbound Calls section, select the desired CSS from the Called Party Transformation CSS and Calling Party Transformation CSS drop-down lists. Under the SIP Information section, there are additional CSSs that should be configured. These included the Rerouting Calling Search Space, Out-Of-Dialog Refer Calling Search Space, and SUBSCRIBE Calling Search Space.

• Step 4. Select the CSS from the Calling Search Space drop-down list.

  NOTE

  For some gateways such as Media Gateway Control Protocol (MGCP), you need to navigate to the subunit configuration page to assign a CSS.

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

Now that you have assigned CSS, you can assign partitions. Partitions are assigned to patterns of directory numbers. Examples of how to assign them to CSS and partitions follow.

Assigning a Partition to a Line (Directory Number)

The following steps show how to assign a partition to a line:

• Step 1. From within CCMAdmin, select Device > Phone.
• Step 2. Enter search criteria in the search field to limit the results and click Find.
• Select the phone that contains the desired line from the list of phones that is generated.
• Step 3. Click the desired line on the left side of the screen.
• Step 4. On the Directory Number Configuration page, select the desired partition from the Route Partition drop-down list, as shown in Figure 5-9.
  

  Figure 5-9 Assigning a Partition to a Line

• Step 5. Click Save.

Assigning a Partition to a Pattern

• Step 1. From within CCMAdmin, select Call Routing > Route/Hunt > Route Pattern.
• Step 2. To limit the results, enter search criteria in the search field and click Find.
• Step 3. Select the route pattern from the list that displays.
• Step 4. Select the partition from the Route Partition drop-down list, as shown in Figure 5-10.
  

  Figure 5-10 Assigning a Partition to a Route Pattern

• Step 5. Click Save.

After the partitions are applied, you can begin testing the system to ensure that allowed calls can be placed, and those that are not allowed cannot be placed.

Adding CSS and partitions after the system is in place can require a lot of work. Remember that you can use the the Bulk Admin Tool (BAT) to quickly apply or change a CSS or partition on a large number of objects.

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.

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.

Special Services Configuration

There are certain types of calls that should always be given priority and availability to be dialed from all phones. The first call of this type is 911. When a 911 call is placed, it is important that the call gets through. Not only is it necessary to make the call possible, but you also need to ensure that it goes to the right destination. The following sections discuss some of the issues that can arise with these services.

Special Services Overview

Depending on your local service, various special services might be available. For example, the following is a list of special service numbers that are commonly available in North America. Check with your local phone company to see which of these are valid in your area.

• 311: Nonemergency police services
• 411: Directory assistance
• 511: Travel information
• 611: Phone equipment repair
• 711: Telecommunications Device for the Deaf (TDD) operator
• 911: Emergency

After you determine which services are available, you must configure route patterns that will match these calls. The most important of these calls is 911. Because in an emergency, a person might not think to dial 9 before dialing 911; patterns should be created that enable the call to go out regardless of whether 9 is dialed first. This means that two patterns need to be created, 911 and 9.911. PreDot discard instructions must be applied to the 9.911 pattern so that only 911 is sent out the public switched telephone network (PSTN).

When there are remote locations, things become a little more complicated. Imagine that you have an office in San Jose and a remote office in San Francisco. When callers dial 911 from San Francisco, the call must be routed to the local emergency service, not the service in San Jose. Although this seems obvious, it is sometimes overlooked. To accomplish this, multiple 911 and 9.911 patterns must be created. Partitions and CSS are used to allow phones in each location to match only the pattern that routes the call to the correct location.

For all other special services, the 9.X11 pattern should be sufficient. Once again, be sure to create patterns for each remote location so that the call is routed to the local PSTN.

Another concern when dealing with 911 calls is that some local legislation requires that more detailed location information be sent than just the street address. These laws normally apply to buildings that are over a certain size. Typically the floor and room number are required in addition to the street address. This requirement is referred to as an E911 or enhanced 911. Imagine that someone dialed 911 from a 20-story building and all that was sent was the street address. This would make it difficult to determine which floor, let alone which office, it came from. The solution is to have a database that contains the detailed address information for each phone number in your company. This database is typically maintained by an outside company and is accessible by the emergency service.

Another issue that arises with Communications Manager is that because a phone can be moved so easily, the information in the database can become outdated rather quickly. In addition to this, a feature known as extension mobility makes the Communications Manager system even more nomadic. To deal with these issues, Cisco offers an Emergency Responder product. This product ensures that the correct detailed information is sent when a 911 call is placed. For more details on this product, refer to the "Cisco Emergency Responder Administration Guide" on Cisco.com.

Configuring Special Services Route Patterns

To ensure that special services numbers are accessible, you must create route patterns for them. As mentioned previously, it is recommended that you create at least three patterns for each location. The first two are for 911 services and should be 911 and 9.911. If your location does not use a leading 9 for PSTN access, the first 9 in the 9.911 pattern should be replaced with whatever number is used for PSTN access. The third pattern is 9.X11. This pattern will match all other special services numbers.

The 9.911 and 911 patterns should be marked Urgent Priority so that as soon as the number is dialed, it is sent. If this pattern is not marked Urgent Priority, delays could occur before the call is sent, and this should never happen.

As often happens, one solution creates another problem. I have heard people say that they do not use the 911 pattern because people often dial it by mistake. What happens is that a person dials 9 for an outside line, then presses one to begin a long distance call, and then mistakenly presses one again. This, of course, matches 911 and routes the call to emergency services. It is never recommended that you not include the 911 pattern. Although people misdialing 911 is problematic, it is gravely problematic if 911 cannot be dialed during an emergency. I have heard of many ways people have fixed this problem, but I would not recommend any of them because they all result in either the failure or delay of the call.

An overview of the tasks required to create patterns to allow access to special services numbers follows. Refer to Chapter 4, "Implementing a Route Plan," for detailed steps on how to create route patterns.

• Step 1. Create a 911 route pattern.
• Step 2. Assign a partition to this pattern that all phones in the location can dial. If there are remote locations, a separate pattern must be created and placed in a partition that only phones in that location can reach. This pattern must then point to a route list that will send the call out the local PSTN. Figure 5-16 shows an example of this.
  

  Figure 5-16 Routing 911 Calls for Multiple Locations

  WARNING

  When configuring 911 patterns in environments that include remote locations, it is imperative that you create a route plan that will send the call to the proper 911 operator. For example, if the Communications Manager cluster is in Chicago and a remote location is in San Jose, you must make certain that when a user in San Jose dials 911, the call reaches the San Jose 911 operator, not the Chicago 911 operator. The responsibility to ensure that this works properly is solely upon you. If you are uncertain how to properly implement this, you should seek additional help from an individual with proven experience in this field.

• Step 3. Select a gateway or route list that will send this pattern out the local PSTN gateway.
• Step 4. Select the Urgent Priority and OffNet Pattern (and Outside Dial Tone) check boxes.

  NOTE

  Although it is not necessary to provide an outside dial tone for this pattern, if you do not, the outside dial tone will not be played for any number that begins with 9, until enough digits are dialed so that the number does not match 911. That means, in most cases, when dialing a long-distance number, the outside dial tone is not heard until three digits are dialed. For this reason, it is recommended that you select the OffNet Pattern (and Outside Dial Tone) check box.

• Step 5. Create a 9.911 route pattern. If your location does not use a leading 9 for PSTN access, the first 9 in the 9.911 pattern should be replaced with whatever number is used for PSTN access.
• Step 6. Assign a partition to this pattern that all phones in the location can dial. If there are remote locations, a separate pattern must be created and placed in a partition that only phones in that location can reach. The pattern must then point to a route list that will send the call out the local PSTN. Figure 5-16 shows an example of this.

  WARNING

  When configuring 9.911 patterns in environments that include remote locations, it is imperative that you properly create a route plan that will send the call to the proper 911 operator. For example, if the Communications Manager cluster is in Chicago and a remote location is in San Jose, you must make certain that when a user in San Jose dials 9.911, the call reaches the San Jose 911 operator, not the Chicago 911 operator. The responsibility to ensure that this works properly is solely upon you. If you are uncertain as to how to properly implement this, you should seek additional help from an individual with proven experience in this field.

  WARNING

  Special emergency call routing considerations must be made when deploying device mobility or extension mobility. Since device mobility and extension mobility allow the user to change physical locations you must ensure that the call will be routed based on the physical location of the user. The techniques used to ensure this are beyond the scope of this book. If you are unsure as to how this should be configured you should enlist the assistance of a experienced Cisco voice engineer. The responsibility to ensure all call routing, which includes emergency call routing, works properly is solely upon you.

• Step 7. Select a gateway or route list that will send the pattern out the local PSTN gateway.
• Step 8. Select the Urgent Priority and OffNet Pattern (and Outside Dial Tone) check boxes.
• Step 9. Set the discard digits to PreDot.
• Step 10. Create a 9.X11 route pattern.
• Step 11. Assign a partition to the pattern that all phones in the location can dial. If there are remote locations, a separate pattern must be created and placed in a partition that only phones in that location can reach. The pattern must then point to a route list that can send the call out the local PSTN.
• Step 12. Select a gateway or route list that will send the pattern out the local PSTN gateway.
• Step 13. Set the discard digits to PreDot.
• Step 14. Select the OffNet Pattern (and Outside Dial Tone) check box.

It is essential that after you have created patterns for these services, you make test calls to ensure that the call is routed properly. The steps provided previously are only general practices; additional configuration might be required. There is no guarantee that the previous steps will work in each situation. It is your responsibility to make sure that you test these services thoroughly before the system goes live.

Summary

This chapter explored how certain calls can be restricted by applying CSS and partitions to devices and patterns. Because it is often required that different devices have access to various destinations, the steps for creating and applying CSS and partitions are provided.

When deploying VoIP solutions, ensuring the quality of the call is essential. To accomplish this, CAC was discussed. Detailed steps were provided that show how to configure a gatekeeper that provides CAC for calls between clusters. Steps were also included to show how to configure locations for CAC, for calls to and from remote sites.

Finally, special services, such as 911, were discussed in this chapter. An overview of the required steps for the proper configuration of these services was given.