Numeric Addresses

To reach internal endpoints such as IP phones, fax machines, and applications, such as voicemail systems, auto-attendants, and conferencing systems, an engineer must assign at least one directory number to each endpoint. In addition, directory URIs can be added as aliases to directory numbers. Calling a configured directory number or directory URI will allow a user to reach the corresponding device.

The first decision an engineer must make is the length of the internally used extension. The number of required extensions influences whether the engineer will choose longer or shorter extensions. Four-digit extensions allow up to 10,000 endpoints to be addressed within a single enterprise deployment. Typically, the phones should also be reachable from the PSTN. Internal endpoint addressing can be mapped to PSTN numbers for off-net connectivity in two ways:

• Two-Stage Dialing: With two-stage dialing, all endpoints share a single PSTN number. When a PSTN user wants to call an internal endpoint, the PSTN user calls the PSTN number of the target company. The communications system, such as the Cisco Unified Communications Manager, accepts the call either by routing the call to an attendant’s extension or by answering the call with an IVR script that allows the caller to then enter the extension of the desired internal user.

• Direct Inward Dialing (DID): With DID, each internal phone has its own PSTN number. Ideally, the least significant digits of the external DID range match the internally used extension numbers (1:1 mapping). If a corresponding DID range is not available and your PSTN provider assigns different external numbers to you, you must map each external number to an internal extension and translate the number accordingly.

The E.164 number format is used in the PSTN environment. E.164 numbers start with a country code, and they can have a maximum of 15 digits. International phone numbers are usually written with a plus sign (+) before the phone number to indicate that the number is in international E.164 format. Such numbers are referred to as +E.164 numbers. H.323 does not support +E.164 dialing. To actually dial a PSTN number from a normal fixed-line phone, you must use the appropriate access code. Every country has both a national access code, which is used to dial a national number without the country code, and an international access code, which is used to dial out of the country. To indicate that an IP call should be sent to the PSTN from an IP PBX, such as the Cisco Unified Communications Manager, instead of being routed within the enterprise network, a PSTN access code is often configured and must be dialed first to reach an outside line. Calls within an enterprise IP network are referred to as on-net calls. Calls that leave the IP network and traverse the PSTN network are referred to as off-net calls. Figure 18-3 illustrates how 4-digit internal directory numbers are mapped 1:1 to external +E.164 numbers.

Alphanumeric Addresses

Directory numbers are assigned to a phone line, and then directory URIs are assigned to a directory number. Therefore, a directory URI cannot exist unless a directory number exists first. The format of a standard URI is different from the format of a URI in the Cisco Unified Communications Manager. A standard URI takes the form host@<Fully_Qualified_Domain_Name>, such as [email protected]. Email addresses are a common use of standard URIs where the domain must be qualified against an authoritative server, such as the mail server. A directory URI on the Cisco Unified Communications Manager has the same look as a standard URI, but it takes the form user@domain or user@ip_address. Because a directory URI is not assigned to a phone, the “domain” portion of the alias does not have to be qualified. The behavior of a directory URI is also slightly different on the Cisco Unified Communications Manager than standard URIs in a typical networked environment. Cisco has renamed the components that make up a directory URI. The domain portion of the directory URI is also referred to as the “host” portion within the Cisco Unified Communications Manager.

Out of the box, the user portion of a directory URI is case sensitive. This has to do with the characters that are considered digits within the Cisco Unified Communications Manager. Any digit 0–9; plus special characters question mark (?), dollar sign ($), exclamation mark (!), percent sign (%), ampersand (&), underscore (_), tilde (~), equal sign (=), backslash (), brackets ([ ]), plus sign (+), dash (-), caret (^), asterisk (*), comma (,), dot (.), forward slash (/), and pound sign (#); and the capital letters A–D are all considered to be of numeric value. Under Cisco Unified Communications Manager Administration, in the Enterprise Parameters Configuration menu, there is a parameter called URI Lookup Policy. The default value to this setting is Case Sensitive, which is what makes the letters A–D represent numbers. Changing this setting to Case Insensitive changes the user portion of the directory URI so that it’s case insensitive, therefore also changing the letters A–D away from numeric status.

The host, or domain, portion of the directory URI is always case insensitive. Acceptable characters in the host portion of the directory URI include the letters a–z, A–Z, numbers 0–9, hyphens, and dots. The host portion must contain at least two characters, it cannot start or end with the hyphen character, nor can it contain two consecutive dots. Table 18-3 identifies all the characters that are supported in both the user and domain portions of a directory URI.

There are two ways to place calls to URIs from endpoints that support URI dialing. The first method is by dialing a full directory URI. This method of dialing uses both the user and domain portions of the URI address and is always supported. This method is required when calling the URI of an endpoint outside of the enterprise domain, such as Webex.com. The second method of dialing by URI is by dialing only the user portion. The Cisco Unified Communications Manager will not allow URIs to be dialed by only the user portion unless the organization top-level domain (OTLD) is configured under the enterprise parameters. This is where the case sensitivity setting comes into play. If a user were to dial BAD2003, and the URI Lookup Policy was set to Case Sensitive, the Cisco Unified Communications Manager would see this alias as a directory number, not a directory URI, and no domain would be appended to it. This may impact call routing if the alias only existed within a directory URI. However, changing the URI Lookup Policy to Case Insensitive would allow this alias to be routed as a directory URI. The domain that existed in the OTLD would be appended, and the call would be routed providing a match was found. Ideally, all URIs that are applied to endpoints of a Cisco Unified Communications Manager cluster use the same, globally unique host portion. If you use the same host portion in different clusters, calls between these clusters work only if you implement URI synchronization. URI synchronization is an application of the ILS and GDPR.

As mentioned before, URIs are not directly applied to a phone or phone line, but they are associated with a directory number. When a call is placed to a locally configured URI, the Cisco Unified Communications Manager routes the call to the associated directory number. There are two places where directory URIs can be configured in the Cisco Unified Communications Manager. Directory URIs are assigned at the Directory Number configuration page or at the End User configuration page. Directory URIs set at the End User configuration page will be placed automatically in the Device URI partition, which is a default partition that exists within the Cisco Unified Communications Manager, and this setting cannot be changed. URIs set at the Directory Number configuration page allow you to set the partition to anything, including the None partition, and you can change this setting at any time. You can also set up to five directory URIs per directory number, as long as one of the directory URIs is set as the primary.

Directory numbers can be individually managed under Cisco Unified Communications Manager Administration by navigating to Call Routing > Directory Number. Search for a specific directory number or click Find to view all the available entries. Click the Add New button to configure a new directory number.

After the directory number has been configured, whether with the provisioned phone, end user, or manually, other line settings can now be configured. Many of these settings will be discussed as this chapter progresses. Scroll down to the Directory URIs section. Enter a full URI address in the URI box, and select a partition from the Partition drop-down box. Click on the Add Row button when finished. A new line appears, but the directory URI is added to this directory number. Click Save when finished.

To add a directory URI to an end user, navigate to User Management > End User. Select the end user to be modified, whether this is an LDAP synchronized user or not. In the User Information section, locate the directory URI setting and enter the appropriate value in the box beside it. Click Save after the setting has been configured. Figure 18-4 illustrates where to configure the directory URI settings on the Cisco Unified Communications Manager.

Partitions and Calling Search Spaces

A partition is a group of dialable patterns with identical accessibility. A calling search space (CSS) defines which partitions are accessible to a particular device. Another way of looking at partitions and CSSs is that partitions affect inbound called numbers, whereas CSSs affect outbound calling devices. A device can call only those call-routing table entries that are in partitions included in the CSS of the device. Partitions are assigned to call-routing targets—that is, any entry of the call-routing table, including voicemail ports, directory numbers, route patterns, and translation patterns. CSSs are assigned to the sources of call-routing requests, such as phone lines, gateways, trunks, voicemail ports, and applications. By default, all entities that can be configured with a partition are automatically in the <None> partition, also referred to as the null partition, and all entities that can be configured with a CSS are automatically assigned the <None> CSS. The <None> partition allows access to any call-routing sources regardless of the CSS of that call-routing source, and the <None> CSS provides access to no partitions except the <None> partition. By default, no partitions or CSSs are assigned, and all entities are associated with the null partition and <None> CSS. Therefore, all calls are possible for all calling sources by default. Figure 18-6 illustrates how partitions and CSSs operate within the Cisco Unified Communications Manager environment.

Several analogies have been created over the years to try to explain the relationship between partitions and CSSs. None have conveyed this information as well as the analogy of locks and key rings, as illustrated in Figure 18-6. The locks represent partitions that an administrator has applied to phone lines. The key rings represent the CSSs. Each key on a key ring represents a different partition associated with that CSS and therefore provides access to that partition. CSSs can be applied to either the phone line or to the phone itself.

In Figure 18-6, Phone 1 is configured as a member of the P1 partition, Phone 2 is in the P2 partition, and Phone 3 and Phone 5 are in the P3 partition. Phone 4 remains in the <none> partition because this phone has not been assigned to any other partition. Following the analogy of locks and keys, there are three different locks (P1, P2, and P3). Locks are a great symbol for partitions because when a phone is assigned to a partition, that phone is secured so that no other phone can call it without appropriate permission. With only the partitions (locks) in place, none of the phones can contact any of the other phones except for Phone 4, which is in the <none> partition. Any device in the <none> partition can be contacted by any other device under any circumstance. Even though Phone 3 and Phone 4 are in the same partition, they cannot call one another because neither phone has permission to call P3. To assign calling privileges, CSSs must also be assigned to each phone.

The CSSs are represented as key rings. Each key on a key ring represents the partition that key ring can access. Phone 1 has a key ring with P2 and P3 keys. Phone 2 has a key ring with P1 and P3 keys. Phone 3 has a key ring with only one key to P2. Phone 4 has a key ring with only one key to P1, and Phone 5 has no keys. As a result of this implementation of partitions and CSSs, the following effective permissions apply:

• Phone 1: Phone 1 has access to all devices in the <none> partition, which includes Phone 4 from this example. In addition, Phone 1 can access devices in the P2 and P3 partitions because it has the appropriate keys. Therefore, Phone 1 can access Phone 2, Phone 3, Phone 4, and Phone 5. However, Phone 1 cannot access any other devices in the P1 partition if any existed.

• Phone 2: Like Phone 1, Phone 2 has access to all devices in the <none> partition, which includes Phone 4 from this example. In addition, Phone 2 can access devices in the P1 and P3 partitions because it has the appropriate keys. Therefore, Phone 2 can access Phone 1, Phone 3, Phone 4, and Phone 5. However, Phone 2 cannot access any other devices in the P2 partition if any existed.

• Phone 3: Like all other phones, Phone 3 has access to all devices in the <none> partition, which includes Phone 4 from this example. In addition, Phone 3 can access devices in the P2 partition because it has the appropriate key. Therefore, Phone 3 can access Phone 2 and Phone 4. However, Phone 3 cannot access any devices in the P1 or P3 partitions.

• Phone 4: Like all other phones, Phone 4 has access to all devices in the <none> partition, which includes itself from this example. In addition, Phone 4 can access devices in the P1 partition because it has the appropriate key. Therefore, Phone 4 can access Phone 1 and itself, which is of no practical importance because phones don’t usually place a call to themselves.

• Phone 5: Like all other phones, Phone 5 has access to all devices in the <none> partition, which includes Phone 4 from this example. Phone 5 cannot access any other partitions because it is still part of the <none> CSS. Therefore, Phone 5 can access only Phone 4.

To summarize the analogy that is used in Figure 18-6: partitions are like locks, which can be unlocked only by an appropriate key. CSSs are like key rings that include the specified keys for the appropriately assigned partitions. If no partition (lock) is applied to a device, all other devices can access that device. If no CSS (key ring) is present, only devices that do not have a partition (lock) assigned can be accessed.

Now that we’ve established a basic understanding of partitions and CSSs, it is important to understand how these COS mechanisms affect call-routing decisions within the Cisco Unified Communications Manager. Assume a phone has a CSS containing two partitions called Chicago and San Jose. The Chicago Partition contains a phone with the directory number 3001 assigned to Phone 2-1. The San Jose partition contains a phone with the directory number 2001 assigned to Phone 1-1. When the user with the CSS assigned to it places a call to directory number 3001, which is the directory number of Phone 2-1, the Cisco Unified Communications Manager performs a call-routing lookup of the number 3001 through the partitions that are configured in the CSS of the calling phone: Chicago and San Jose. The Cisco Unified Communications Manager finds a match in the Chicago partition because the directory number 3001 of Phone 2-1 is assigned to this partition. Because no other matches exist, routing is complete, and Phone 2-1 rings. This example is pretty straightforward and in line with how call routing has been explained up to this point.

A CSS is an ordered list of partitions from the top down. The partition that is listed first has higher priority over a partition that is listed later. When the Cisco Unified Communications Manager performs a call-routing lookup, all accessible entities are considered by best-match logic. Accessible entities include all targets that reside in a partition that is listed in the CSS of the calling phone and all targets that do not have an applied partition (the <none> partition). Multiple identical entities can exist in the call-routing table, but they must be in different partitions. One exception to this rule is phone directory numbers. When two or more devices share the same directory number within the same partition, the directory number is called a shared line. If no single best match is found, the Cisco Unified Communications Manager uses the entry of the call-routing table whose partition is listed first in the CSS of the calling device. So, the call-routing table entry is chosen based on the following order:

1. The best match is chosen.

2. If multiple equally qualified matches exist, the order of the partition in the CSS of the calling device is the tiebreaker. In other words, if there is no single best match, the match that is found in the earlier listed partition in the device CSS is chosen.

On most sources of a call-routing request, such as a trunk, gateway, or translation pattern, only one CSS can be configured. On IP phones, however, a CSS can be applied per line and once at the device level. If both line and device CSSs are configured, the CSS of the line from which the call is placed is considered first. In other words, the CSS that is used is composed of the partitions that are listed in the line CSS, followed by the partitions of the device CSS. The exception to this rule is on CTI ports, where the line CSS and the device CSS are placed in reverse order. The partitions of the device CSS are placed before the partitions of the line CSS. Figure 18-7 illustrates the typical order of line CSSs being listed before device CSSs.

In the example from Figure 18-7, the line CSS of the calling phone includes the San Jose and Chicago partitions, and the device CSS of the calling phone includes the Atlanta partition. Route pattern 300X is in the San Jose partition, directory number 3001 is used at Phone 2-1 in the Chicago partition, and the same directory number 3001 is used at Phone 3-1 in the Atlanta partition. If the calling phone dials 3001, the Cisco Unified Communications Manager interprets the dialed digits and searches for the closest match.

The route pattern 300X represents 10 possible numbers and is therefore not a “closest match,” as compared to the two directory numbers of 3001. Out of the two equally matched directory numbers, the number of Phone 2-1 is used to extend the call because it is in the partition that is listed first from the line CSS. Based on this current configuration, Phone 3-1 can never be reached from the phone with these CSSs. Site codes would be needed in order to reach Phone 3-1.

The importance of this example is to illustrate that the line CSS has higher priority over the device CSS. If the line CSS and device CSS were reversed, the call would be sent to Phone 3-1. Although route pattern 300X matches the dialed number and is listed in the first partition, it is not used to route the call in this example. The first priority for the call-routing decision is the best match; the order of partitions is important only if multiple best matches exist.

A common misunderstanding is that the first matching pattern found when searching through the partitions in the order that is specified in the CSS is used for call routing, regardless of the quality of the match. If this scenario were true, subsequent partitions of the CSS would be looked at only if no match was found in the earlier partitions. However, all partitions are immediately considered for best-match logic. The partition order is relevant only if multiple best matches exist.

When you are creating partitions and CSSs, you should always create partitions first. Use the following steps to configure partitions and CSSs on the Cisco Unified Communications Manager:

Step 1. Create partitions.

1. From Cisco Unified Communications Manager Administration, navigate to Call Routing > Class of Control > Partition.

2. Click Add New and enter a name for the partition.

   Note

   To enter multiple partitions, use one line for each partition entry. You can enter up to 75 partitions; the names and descriptions can have up to a total of 1475 characters. The partition name cannot exceed 50 characters. Use a comma (,) to separate the partition name and description on each line. If a description is not entered, Cisco Unified Communications Manager uses the partition name as the description.

3. Click Save when finished.

4. Once partitions have been created, they can be assigned to dialable patterns such as directory numbers, route patterns, or translation patterns.

Step 2. Create CSSs.

1. Navigate to Call Routing > Class of Control > Calling Search Space.

2. Choose one of the following options:

   Note

   Several CSSs exist by default in the Cisco Unified Communications Manager. After partitions have been configured, the administrator may choose to modify an existing CSS or create new ones.

   Click Add New to add a new calling search space.

   Click Find and select an existing CSS.

3. From the Calling Search Space Configuration page, enter a Name and optionally a Description for the CSS.

4. From the Available Partitions box, select the partitions to be added to this CSS, and then click the down arrow. These partitions will be searched based on the order they are listed. Use the up- and down-arrow keys to the right of the Selected Partitions box to change the order of any selected partition.

5. Click Save once the CSS has been configured.

6. Once all the CSSs have been configured, assign the appropriate CSS to entities that can request lookups to the call-routing table to route a call. Examples of such entities are phones and phone lines, trunks, gateways, and translation patterns.

A translation pattern can support both a partition as a called entity and a CSS as the calling entity. The translation pattern is a dialable pattern in the call-routing table as the target of a call-routing request. If matched, the pattern invokes a new call-routing request for the translated pattern. The partition at the translation pattern specifies who can match the pattern. The partition is required in the CSS of the calling device. The CSS at the translation pattern specifies the entries of the call-routing table that the translation pattern can see for its call-routing request when trying to find the translated pattern in the call-routing table.

Time of Day (ToD) Routing

Time of day (ToD) routing is a practical means of controlling when calls across a PSTN are allowed, in addition to who is allowed to place those calls. For example, a company noticed its phone bill increased significantly during recent months. Upon closer investigation, the staff realized that multiple international calls were being placed after closing hours during the week. That company had recently contracted a new cleaning company to come in after hours to clean the office. The cleaning personnel were making international calls during their shifts. The Collaboration administrators were able to resolve this issue and prevent after-hours calls from being made by simply introducing ToD routing to the existing network.

You can use ToD routing to define time periods. You can define a start time and an end time, and also specify repetition intervals either as days of the week or a specified date on the yearly calendar. The following steps outline how to configure ToD routing in the Cisco Unified Communications Manager:

Step 1. Configure a time period.

1. From Cisco Unified Communications Manager Administration, navigate to Call Routing > Class of Control > Time Period.

2. Click Add New and configure the following fields in the Time Period Configuration window:

   Name: Enter a name for the time period.

   Time of Day Start: Choose a start time from the drop-down menu.

   Time of Day End: Choose an end time from the drop-down menu.

   Repeat Every: Optionally choose a start and end date based on weeks or years.

3. Click Save.

Step 2. Configure a time schedule. The time periods that were configured in the preceding step are building blocks for this schedule. Time periods can be assigned to multiple schedules.

1. Navigate to Call Routing > Class of Control > Time Schedule.

2. Click Add New and enter a Name for the new time schedule.

3. Click Save.

4. In the Time Schedule Configuration window, the Time Period Information box will appear. Select the time periods that should be added to this time schedule from the Available Time Periods box and use the down-arrow key to move them to the Selected Time Periods box. This is an ordered list from top down, so the order can be changed using the up- and down-arrow keys to the right of the box.

5. Click Save.

Step 3. Associate time schedules with partitions to determine where calling devices search when they are attempting to complete a call during a particular time of day.

1. Navigate to Call Routing > Class of Control > Partition.

2. Click Find, and select a partition to modify from the list.

3. From the Partition Configuration page, use the Time Schedule drop-down list to choose a time schedule to associate with this partition. The time schedule specifies when the partition is available to receive incoming calls. If you choose <None>, the partition remains active at all times.

4. Click Save.

Location-Based CAC Bandwidth Requirements

An enterprise network uses bandwidth for many different purposes, and all IP-based communication usually crosses the same network edge. You could have voice and video traffic crossing the WAN, while large files are being transferred to an FTP server at a remote location, while other devices are accessing email or other services in the cloud. The result is that each device is competing for bandwidth across the company’s network. Individual sites of a multisite deployment are usually interconnected by an IP WAN. Bandwidth on WAN links is limited and relatively expensive. Therefore, the goal is to use the available bandwidth as efficiently as possible. You should discourage unnecessary traffic, such as social media sites and personal use, and consider implementing methods for bandwidth optimization. Figure 18-8 illustrates the dichotomy of an unmanaged enterprise network across a WAN.

Implementing QoS policies will certainly help during high congestion times across the network, but QoS will not prevent overutilization of bandwidth. Imagine a scenario where a corporate WAN can handle up to 1 Mbps total bandwidth. If two endpoints place an audio-only call using the G.711 codec for audio, they will consume 87.2 kbps: 64 kb are for the payload, and 23.2 kb are for headers. That means that this WAN link can support up to roughly 11 audio-only calls, assuming there is no other network traffic consuming bandwidth at the time of the calls. Now imagine what happens when the eleventh call attempt is placed. The call isn’t dropped. Rather, this call leg will begin barrowing bandwidth from the other existing calls, and everyone will suffer quality loss during their calls, even if proper QoS has been implemented. This is where Call Admission Control (CAC) comes into the picture.

Cisco has several Call Admission Control mechanisms that can be implemented to control how bandwidth is used across your network. Using CAC in the Cisco Unified Communications Manager allows administrators to control the codec used on a per-call basis depending on the sites between which calls are placed, as well as the overall bandwidth used when calls are placed across the WAN.

Regions are the first settings on the Cisco Unified Communications Manager that an administrator should configure for Call Admission Control. Regions, which were discussed in previous chapters, control the codecs used between endpoints when calls are set up. There is a specific bandwidth allocation associated with each audio codec, so you can easily plan and predict how much bandwidth is going to be consumed. G.711 is an uncompressed codec and consumes 87.2 kbps per call with average audio quality. G.729 is a compressed audio codec that consumes only 31.2 kbps but suffers from poorer quality. Other codecs can be compressed or uncompressed and will have varying levels of quality accordingly.

Compression involves utilizing encoding algorithms to reduce the size of digital data. Compressed data must also be decompressed before it can be used. This extra processing imposes computational or other costs into the transmission hardware. Lossless and lossy are descriptive terms used to describe whether or not the data in question can be recovered exactly bit-for-bit when the file is uncompressed or whether the data will be reduced by permanently altering or eliminating certain bits, especially redundant bits. Lossless compression searches content for statistically redundant information that can be represented in a compressed state without losing any original information. By contrast, lossy compression searches for nonessential content that can be deleted to conserve storage space.

By contrast to audio, video is very greedy and bursty when it comes to bandwidth consumption. Video codecs do not have a specific set bandwidth rate to them like audio codecs. You can place a video call using 480p30 resolution at 384 kbps or at 2 Mbps. However, using a higher codec can provided better efficiency and thus consume less bandwidth. Therefore, when you are configuring regions in the CUCM, you do not select a codec specifically; rather, you set the per-call bandwidth rate that is allowed between each site. There are two fields to configure video bit rates in the Regions settings page. The Video Calls column has to do with UC endpoints that can place video calls, such as 8845 and 8865 IP video phones and the Cisco Jabber client. The Immersive Video Calls column has to do with any Cisco Telepresence video endpoint, such as the DX80, MX700, SX80, or Webex endpoints.

Whereas regions deal more with a per-call bandwidth, locations control total bandwidth consumption. The following three locations are predefined in the Cisco Unified Communications Manager:

• Hub_None: This is a sample location that typically serves as a hub linking two or more locations. It is configured by default with the Unlimited intra-location bandwidth allocations for audio, video, and immersive bandwidth, but you can specify bandwidth allocations for each of these. By default, devices not assigned to other locations are assigned to Hub_None automatically.

• Phantom: This location specifies unlimited bandwidth for audio, video, and immersive calls. Specify this location to allow successful Call Admission Control for calls across inter-cluster trunks that use the H.323 or SIP trunks to certain destinations that support the earlier location CAC feature.

• Shadow: This is a system location created for inter-cluster enhanced location CAC. To pass locations across clusters, the SIP inter-cluster trunk (ICT) must be assigned to the Shadow system location.

An administrator can create custom locations as well. When setting up locations, remember that the bandwidth rate is total bandwidth, not per call. Also, overhead is not calculated automatically, so you will have to include overhead when setting the bandwidth limitations. For video calls, add 20 percent to each call rate and then multiply by the number of calls allowed. If the call rate is 384 kb, add 20 percent to give a total of 460 kbps. If you wanted to support 10 calls, then 460 × 10 = 4600 kbps.

Use the following steps to configure location-based CAC on the Cisco Unified Communications Manager. Figure 18-9 illustrates the Location Configuration window.

Step 1. Configure locations on the Cisco Unified Communications Manager.

1. From Cisco Unified Communications Manager Administration, navigate to System > Location Info > Location.

2. Click Add New and enter the following information in the Location Configuration window.

   • Name: Enter a name for the location.

   • Location: Select a location from the list.

   • Weight: Enter the relative priority of this link in forming the effective path between any pair of locations. The effective path has the least cumulative weight of all possible paths. Valid values are 0–100.

   • Audio Bandwidth: Enter the maximum amount of audio bandwidth in kbps that is available for all audio calls on the link between this location and other locations. For audio calls, the audio bandwidth includes overhead.

   • Video Bandwidth: Enter the maximum amount of video bandwidth in kbps that is available for all video calls on the link between this location and other locations. For video calls, the video bandwidth does not include overhead.

   • Immersive Video: Enter the maximum amount of immersive video bandwidth in kbps that is available for all immersive video calls on the link within this location. For video calls, the immersive video bandwidth does not include overhead.

3. Click Save when finished.

Locations can be assigned to phones directly, or they can be added to device pools, which is the recommended method. Each phone is automatically assigned the Hub_None location. However, location settings in the device pool override location settings on the phone.

Step 2. Assign locations to device pools.

1. Navigate to System > Device Pool.

2. Choose one of the following options:

   • Click Add New to add a new device pool.

   • Click Find and choose a device pool from the resulting list to modify the settings for an existing device pool.

3. On the Device Pool Configuration page, under the Roaming Sensitive Settings section, locate the Locations menu option and use the drop-down list to select the appropriate location.

4. Click Save. If an existing device pool has been modified, click the Apply Config button so that the changes will be pushed to any phones already configured with this device pool.

Hunting

The Cisco Unified Communications Manager call hunting implementation is composed of four main components. They are hunt pilots, hunt lists, line groups, and line group members. A user can dial a hunt pilot number, which will direct the call to a hunt list, that in turn selects a line group, which contains a prioritized list of line group members. Though this is the order of operation for hunting in the Cisco Unified Communications Manager, the order of configuration for each of these components must be in the reverse order. Figure 18-10 illustrates the order of operation for hunting on the Cisco Unified Communications Manager.

Hunt Lists

A hunt list is an ordered list of line groups that are used for call coverage. Hunt lists have the following characteristics:

• Multiple hunt pilots can point to the same hunt list.

• Multiple hunt lists can contain the same line group.

• A hunt list is a prioritized list of line groups; line groups are hunted in the order of their configuration in the hunt list.

• A hunt list does not perform digit manipulation.

Hunt lists are assigned to hunt pilots. Figure 18-11 illustrates the configuration menus for hunt lists on the Cisco Unified Communications Manager.

Line Groups

Line groups are assigned to hunt lists and are composed of a list of line group members. A hunt list can have one or more line groups. At the line group, hunt options and distribution algorithms can be specified to define how call hunting should be performed for the members of a line group. Line groups control the order in which a call is distributed, and they have these characteristics:

• The RNA Reversion Timeout specifies how long the hunting algorithm rings a member of the line group before proceeding to hunt according to the Line Group No Answer hunt option setting.

• Line groups are configured with hunt options, which describe how hunting should be continued after trying the first member of the line group. The hunt options are configured based on per-hunt failure events, such as No Answer, Busy, or Not Available.

• Line groups are configured with a global distribution algorithm, which is used to select the next line group member for hunting. The algorithm options include the following:

  • Try Next Member; Then Try Next Group in Hunt List

  • Try Next Member, but Do Not Go to Next Group

  • Skip Remaining Members, and Go Directly to Next Group

  • Stop Hunting

• Line groups point to specific extensions, which are typically IP phone extensions or voicemail ports.

• The same extension may be present in multiple line groups.

Figure 18-12 shows the configuration options for line groups.

Hunt Pilots

Hunt pilots are dialable patterns, such as route patterns and directory numbers, in the call-routing table. The hunt pilot points directly to a hunt list. Hunt lists point to line groups, which point to endpoints. A hunt pilot can be called directly, such as to provide a certain service to customers. Alternatively, an IP phone can be configured to forward unanswered or busy call attempts that it receives to the hunt pilot to provide call coverage.

If the directory number of the phone is dialed directly and the call is busy or not answered, the forwarding configuration of the line (CFB or CFNA setting) can forward the call to a hunt pilot. However, while hunting, the forwarding configuration of line group members is ignored. If the hunting algorithm rings a phone and the call is not answered, the CFNA setting of that phone is ignored. The hunting algorithm goes on to the next line group member.

At the hunt list, digit manipulation can be configured to transform the calling and called number before the call is passed on to line group members. Calls can also be redirected to a final destination when the hunting fails because of one or both of these reasons:

• All hunting options have been exhausted and the call still is not answered.

• A maximum hunt timer that is configured at the hunt list has expired.

This call redirection is configured in the Hunt Call Treatment Settings section of the Hunt Pilot Configuration page, and the destination for this redirect can be either of these options:

• Forward Unanswered Calls to Destination or Forward Busy Calls to Destination: A specific destination that is configured globally at the hunt pilot.

• User Forward Settings of Line Group Member: A personal preference that is configured at the phone line of the originally called number, when hunting on behalf of that number fails. The personal preference is configured by using the Call Forward No Coverage (CFNC) settings at the phone line.

You can implement the personal preferences option. To do so, configure a user phone so that the Forward No Answer field redirects the call to a hunt pilot, which searches for someone else to answer the call. If call hunting fails because all the hunting options are exhausted or because a timeout period expires, the call can be sent to a personalized destination for the person who was originally called. For example, if you set the Forward No Coverage field in the Directory Number Configuration page to a voicemail number, the call will be sent to the voice mailbox of that person if hunting fails.

These considerations apply to calls that are processed by hunt pilots:

• Call Pickup and Group Call Pickup are not supported on calls that a hunt pilot distributes. A member of the line group cannot pick up a hunt pilot call that is offered to another member in the line group, even if both members belong to the same Call Pickup group.

• The hunt pilot can distribute calls to any of its line group members, regardless of the calling privileges implementation of the line group members. If line group members are configured with a partition, the hunt pilot overcomes all partitions and CSS restrictions.

Call Hunting Operation and Call Flow

Now that you have a basic understanding of the components involved with call hunting, a description of the call hunting operation is in order. The call hunting flow in the Cisco Unified Communications Manager call hunting configuration is as follows:

1. Either a direct call is placed to the hunt pilot number, or a call is forwarded from a phone to the hunt pilot number.

2. The hunt pilot that is configured with the appropriate hunt pilot number starts the maximum hunt timer to monitor the overall hunting time. If the timer expires, hunting stops. The hunt pilot is associated with a hunt list.

3. The hunt list that is associated with the hunt pilot sends the call to the first line group that is configured in the hunt list.

4. The line group sends the call to the first line group member, based on the distribution algorithm that is configured for the line group. The possible distribution methods are as follows:

   • Top down

   • Circular

   • Longest idle time

   • Broadcast

5. If the line group member (or members, in case of broadcast) that the distribution algorithm selects does not answer the call, the hunt option specifies how hunting should continue. The hunt option is configured independently, per hunt failure reason, for the line group. Possible hunt failure reasons are No Answer, Busy, and Not Available. In hunt failures that result in No Answer, assumedly the RNAR timer that is configured for the line group has expired.

   • If the hunt option that is configured for the appropriate hunt failure reason is Stop Hunting, hunting stops.

   • If the hunt option that is configured for the appropriate hunt failure reason is Skip Remaining Members and Go Directly to Next Group, and there are no more line groups, hunting stops. If there are additional line groups, the process continues with the next line group (step 4).

   • If the hunt option that is configured for the appropriate hunt failure reason is Try Next Member Then Try Next Group in Hunt List, and there are additional line group members, the process continues with the next line group member (step 4). If there are no additional line group members, the next line group is used. If there are additional line groups, the process continues with the next line group (step 4). If there are no more line groups, hunting stops.

     When hunting stops, the following are possible reasons:

   • Stop Hunting is the hunt option that was applied after a call was not accepted by the last attempted line group member.

   • After hunting tried the last line group member, there were no other line group members or other line groups to be used. This reason is known as hunt exhaustion.

   • The maximum hunt timer that is configured for the hunt pilot expired.

     Once the process has exhausted all hunting options, the hunt pilot continues with the following actions.

6. Review the hunt pilot configuration for its final forwarding settings. If the hunt pilot is not configured for final forwarding, the call fails and a reorder tone is played.

7. Review the final forwarding destination settings that are configured for the hunt pilot:

   • If a Final Forwarding number is specified for the hunt pilot, route the call to the specified number.

   • If Use Personal Preference is selected, route the call to the number that is configured for CFNC on the phone line that invoked the call to the pilot number.

Figure 18-13 illustrates the call hunting flow on the Cisco Unified Communications Manager.

Call Queuing Settings

Call queuing allows hunt pilot callers to be held in a queue while they wait for an agent to become available. Call queuing is based on the existing call distribution capabilities that are provided by hunt lists and hunt pilots. It enables calls to a hunt pilot to be redirected to a queue if all agents that are associated with the hunt pilot are busy, logged out, unregistered, or do not answer. In call queuing, a line group member may be referred to as an agent. However, call queuing does not support an agent desktop application, routing based on agent skills, or similar contact center features. Agents can be part of multiple hunt pilots in which queuing is enabled. When an agent does not answer an offered call, the agent is automatically logged out of the hunt group. This action also applies to shared line appearances. The auto-logout occurs after expiration of the RNAR timer. An agent becomes idle after logging in to a hunt group or after finishing a call. When an agent becomes idle, the following process occurs:

• The Cisco Unified Communications Manager checks all queues to which the agent is currently subscribed for waiting callers.

• Out of these queued callers, the caller that has been waiting the longest is routed to the agent.

Call queuing supports announcements while calls are queued. The Cisco Unified Communications Manager has preinstalled announcements in U.S. English, but custom announcements can be uploaded. Uploading custom announcements is similar to uploading custom Music On Hold (MOH) audio files. Announcements are configured at the MOH Audio Source configuration page. The announcement to be played is chosen by referring to an MOH audio source at the Hunt Pilot Configuration page. Two different announcement types are available through the Cisco Unified Communications Manager:

• Initial announcement: This announcement is played once at the beginning of the call. It can be configured to be played before or after the call is queued.

• Periodic announcement: This announcement is played at a configurable interval while the call is held in the queue.

You can configure an agent phone with the Queue Status IP phone feature button. If pressed, this feature button provides information about the hunt pilot number, the number of queued calls, and the longest waiting time. For call queuing to work over SIP trunks, PRACK must be enabled on the SIP trunk.

The actual hunting process can stop because of hunt exhaustion, expiration of the hunt list maximum hunt timer, or because of running into a configured stop-hunting condition. Queuing can be enabled as another option for call management after the Cisco Unified Communications Manager stops hunting. The other two previously existing options—attempt final forwarding to a configured number or disconnect the call—are still configurable, but they are mutually exclusive. In other words, only one option can be chosen per hunt pilot. Figure 18-14 illustrates the call queuing process on the Cisco Unified Communications Manager.

When a caller is to be placed into a queue, the Cisco Unified Communications Manager first checks whether any hunt members are logged in or registered. If no hunt members are logged in or registered, the caller is not put into the queue of the called hunt pilot. Then the Cisco Unified Communications Manager checks whether the queue of the hunt pilot is already full. The Maximum Number of Callers Allowed in Queue hunt pilot configuration setting is used to decide whether the new caller can be added to the queue. If both checks are passed successfully, the caller is added to the queue. A timer is started to monitor the time that this caller spends in the queue. If the queued call cannot be delivered to an agent before expiration of the configured Maximum Wait Time in Queue, the call is removed from the queue at expiration of the timer.

If a call is not queued at all or is removed from the queue, a final call management option must be configured. A call is not queued if there are no logged-in or registered agents or if the maximum number of queued calls is reached. A call is removed from the queue at the expiration of the maximum wait timer. The default is to disconnect the call. This setting can be changed independently according to the individual scenario by specifying a secondary destination to which the call should be routed. This secondary destination is similar to the final forwarding configuration at the hunt pilot when call queuing is not enabled. A secondary destination can be a directory number, a voicemail number, a shared line, or another hunt pilot that may or may not have queuing enabled. Be aware that sending the call to another queuing-enabled hunt pilot can result in long queuing times. This situation is especially important when cascading multiple hunt pilots.

The Maximum Number of Callers Allowed in Queue parameter is configurable from 1 to 100, and the default is 32. The Maximum Wait Time in Queue parameter is configurable from 0 to 3600 seconds, and the default for this setting is 900. Each value is configurable per hunt pilot. Call queuing supports the playing of announcements once at the beginning of a call and periodically while a call is held in a queue. Figure 18-15 illustrates the configuration procedures for hunt call treatment and queuing settings.

Exam Preparation Tasks

As mentioned in the section “How to Use This Book” in the Introduction, you have a couple of choices for exam preparation: the exercises here, Chapter 32, “Final Preparation,” and the exam simulation questions in the Pearson Test Prep Software Online.