Call Hunting Constructs

Call hunting constructs is a somewhat awkward name that attempts to indicate that the function of these constructs is to serially or simultaneously offer calls not to a single device but to a set of devices. CallManager supports two integrated call hunting constructs.

Hunt lists allow you to serially offer calls to groups of IP phones placed in line groups. Line groups, in turn, permit you to simultaneously or serially offer calls to lines that they contain. Hunt lists and line groups provide you a fairly rich toolset for disposing of calls; in addition to provisioning different hunt algorithms, you can instruct CallManager how to treat calls when an endpoint in a line group doesn't answer or is busy. The section "Hunt Lists and Line Groups" covers hunt lists.

Route lists allow you to serially offer calls to groups of gateways or IP trunks placed in route groups. Route lists provide a couple of search algorithms and support number transformation capabilities. The section "Route Lists and Route Groups" covers route lists.

Hunt Lists and Line Groups

Although the capability to offer a call directly from one user to another is a beautiful thing, often users are closely tied together into groups. For instance, you might have a group of receptionists who handle inbound calls to a particular department or even a particular store, whose job it is to route callers to an appropriate person to answer their questions. Or you might have a phone at a main desk that should accept all inbound calls but which you would like to ring in a back room after a short delay if the front desk cannot take the call because the receptionist had to step away for a moment.

Hunt lists and line groups provide you a way to associate a group identity with a set of phones, and they allow you to set up some fairly complex criteria for the routing of inbound calls.

Hunt lists and line groups work together to handle an inbound call, and they provide slightly different algorithms for treating a call. The basic workflow for setting up call hunting is as follows:

Put simply, a hunt pilot is an address that points to a hunt list. A hunt list contains a list of line groups. Line groups contain a list of directory numbers. When a caller dials digits that match the hunt pilot, the routing algorithms on the hunt list and line groups determine the order in which CallManager offers the call to destinations. Figure 2-19 illustrates the relationships between hunt pilots, hunt lists, and line groups.

Figure 2-19. Hunt List Composition

Figure 2-19 depicts three pairs of phones. Each pair belongs to a single line group. Each line group uses a different hunting algorithm. Line group 1 searches in a top-down order, line group 2 searches in a circular order, and line group 3 uses a broadcast search. (The section "Line Groups" provides specific information about the line group distribution algorithms.)

Each line group is contained in either one or two hunt lists. Hunt list 1 contains line groups 1, 2, and 3. Hunt list 2 contains line groups 2 and 3. Hunt lists always distribute calls in top-down order to the line groups that they contain.

Each hunt list is assigned its own hunt pilot. (You can assign multiple pilots to a single hunt list.) Hunt pilot 8888 points to hunt list 1, and the final disposition for hunt list 1, if no one in the hunt answers the call is to forward to hunt pilot 8889. Hunt pilot 8889 points to hunt list 2, and its final disposition is to forward the call according to personal call coverage settings. (The section "Hunt Pilots" discusses hunt pilot specific settings in more detail.)

Each line group in the hunt list contains the default Hunt Option Try next member; then try next group in hunt list for the No Answer, Busy, and Not Available conditions. Other options permit the following:

• To continue searching within the line group but not to proceed to the next line group within the list
• To immediately skip to the next line group within the list
• To stop hunting entirely

When a caller dials 8888, CallManager performs the following steps:

The following sections discuss the options for line groups, hunt lists, and hunt pilots in more detail.

Line Groups

Line groups permit you to set the following options:

• A distribution algorithm, which allows you to dictate the order in which CallManager rings the phones in the line group. Line groups support the following four distribution algorithms:

  Top Down, which causes CallManager to always ring available phones within the groups in strict list order, starting with the first directory number contained in the line group and ending with the last directory number contained in the line group.

  Circular, which causes CallManager to, on successive calls to the line group, start the hunt with successive lines within the group. For instance, in a line group with the circular distribution algorithm, the first call handled by the line group begins by ringing the first directory number within the line group and ending with the last directory number contained in the line group. The next call handled by the line group begins by ringing the second directory number within the line group and proceeding to the last number in the line group, whereupon the hunting returns to the first directory number in the line group and continues hunting until all available lines have been offered the call.

  Longest Idle, which causes CallManager to monitor the status of directory numbers within the group and order them based on how recently they were active on a call. CallManager offers calls to available lines within the group starting with the least recently used directory numbers and proceeding to the most recently used.

  Broadcast, which causes CallManager to offer the call simultaneously to all available directory numbers within the line group.

• Hunt options, which work along with the RNA (Ring no answer) Reversion Timeout. Hunt options allow you to specify the treatment of calls when CallManager offers the call to a directory number within the group but that directory number does not answer, is busy, or is unavailable (possibly unregistered).

The following list describes these conditions in more detail:

The Not Available condition describes how the line group should treat the call when it encounters an endpoint that is not in service or whose status is unknown. The Not Available setting takes effect only when the distribution algorithm you've selected is Circular or Top Down. If you select the Longest Idle or Broadcast algorithms, the line group always uses the hunt option associated with the No Answer condition to treat the call.

The Busy condition describes how the line group should treat the call when it encounters an endpoint that is actively engaged in another call. The Busy setting takes effect only when the distribution algorithm you've selected is Circular or Top Down. If you select the Longest Idle or Broadcast algorithms, the line group always uses the hunt option associated with the No Answer condition to treat the call.

The No Answer condition describes how the line group should treat the call when it encounters an endpoint that does not answer the call. The line group rings a non- responsive phone until either the T301 service parameter (which defines the maximum call alerting time) for the system expires or until the RNA Reversion Timeout on the line group expires. The No Answer setting takes effect for all distribution algorithms.

The preceding list describes the conditions for which a hunt list option can be set. The following list describes the available options:

Try next member; then, try next group in Hunt List is the standard distribution command. When the hunt list encounters the appropriate condition on one of its members, it simply proceeds to the next member within the group. If all members within the group have been offered the call, then the hunt continues to the next line group within the hunt list. When the Broadcast algorithm is selected, the line group has no next member to select, so setting this value tells the hunt list to simply proceed to the next line group in the hunt list.

Try next member, but do not go to next group causes the line group to proceed to the next member within the group. However, if all members within the group have been offered the call, then the hunt list ceases hunting and disposes of the call as if the hunt list were exhausted. When the Broadcast algorithm is selected, the line group has no next member to select, so setting this value tells the hunt list to simply provide a busy signal to the caller.

Skip remaining members, and go directly to next group causes the hunt to immediately proceed to the next line group in the hunt list, even if the current line group has not offered the calls to all of its members. When the Broadcast algorithm is selected, the line group has no next member to select, so setting this value tells the hunt list simply to proceed to the next line group in the hunt list. Why would you use this option? Because the line group can respond to multiple conditions. For instance, you might want to fully search through a group when a given directory number is busy. But if one or more group members are away from the phone, you might not want a caller to have to wait for the RNA Reversion Timeout to expire for each member in the group. By setting the Skip remaining members, and go directly to next group for the No Answer condition, you can direct the caller to a voice mail system using the forwarding options on the hunt list.

Stop hunting causes CallManager immediately to stop hunting. When set on the busy condition, CallManager disposes of the call as if the hunt list had been exhausted; when set on the not available option, the caller hears the reorder signaling; and when set on the no answer condition, the call rings on the selected directory number (or directory numbers in the case of the Broadcast distribution algorithm) until the T301 service parameter expires.

In addition to the call treatment options, line groups allow you to temporarily bring members in and out of service by administratively moving them from the Selected DN/Route Partition list box to the Removed DN/Route Partition list box, and vice versa.

Hunt Lists

Hunt lists themselves offer no meaningful call distribution algorithms. Hunt lists always offer calls to line groups in sequential order, starting from the first line group listed in the Selected Groups list box and proceeding to the final line group listed.

You can administratively move line groups in and out of service within the displayed hunt list by moving them from the Selected Groups list box to the Removed Groups list box, and vice versa.

Furthermore, you can temporarily enable or disable an entire hunt list by using the Enable this Hunt List check box.

Hunt Pilots

Hunt pilots are really just fancy route patterns (and you thought they couldn't get any fancier!) As such, they exhibit most of the same characteristics of route patterns. For instance, they

• Belong in partitions
• Support pattern notation
• Support route filters
• Belong in numbering plans
• Allow the setting of MLPP precedence
• Support routing or blocking or calls
• Can provide outside dial tone to the caller
• Can bypass the interdigit timer (by setting the Urgent Priority flag)
• Support transformations of the calling and called parties
• Support presentation settings for the calling and called parties

Hunt pilots differ from route patterns in that they support forwarding options, which enable you to specify a final disposition for a call handled by a hunt list. You can also use this disposition to route calls to other hunt lists, phones, gateways, and so onbasically anywhere you could forward a call.

Hunt pilots support the following forwarding options:

• The Forward Hunt Busy option enables you to specify where the call should route when all endpoints within the line groups that the associated hunt list contains were unable to take the call because they were busy.
• The Forward Hunt No Answer option enables you to specify where the call should route when at least one endpoint within the line groups that the associated hunt list contains was offered the call. Forward Hunt No Answer triggers either when the associated hunt list is completely exhausted or when the Maximum Hunt Timer, which you configure on the hunt list, expires without one of the endpoints in the hunt list having answered the call.

Hunt lists allow you to set up two types of forwarding options.

• You can forward calls that exhaust the list to a fixed destination by setting a specific Destination and Calling Search Space in the appropriate field.
• You can forward the list to a destination associated with the previous target of the call who has forwarded the call to the hunt list by checking the Use Personal Preferences check box.

When you select the Use Personal Preferences check box, CallManager treats the call based on the Forward No Coverage settings that you configure on the original destination for the call.

For instance, hunt lists can be provisioned to provide some "backup" for an individual user. Suppose that you are a member of a particular highly regarded team. If a caller attempts to reach you, you could set your forwarding options to send the call to voice mailbut this approach means that a caller, who might have had an urgent question or one that could be quickly answered by your team, must wait for you to check your voice messages before receiving help. By setting the forward no answer on your phone and creating a hunt list that contains the other members of your group, you can direct the caller to your group.

The possibility exists, however, that none of your group is currently available to take your call. In this case, you'd like to be able to direct the call to voice mail or perhaps to your personal cell phone. Simply using the static Destination in the hunt list doesn't quite suffice. If all members of your team wanted to treat calls the same way, you'd have to set up one hunt list per team member, which would be administratively painful. By specifying a Forward No Coverage destination on your phone and selecting the Use Personal Preferences check box, when the hunt list is exhausted it forwards to your personally selected destination, not to a general, fixed destination.

A personal destination takes effect only if the call was originally placed to a destination (currently, an IP phone) that has a Forward No Coverage setting. If the call is directly to a hunt list with Use Personal Preferences set, the caller hears reorderfor such hunt lists, a static destination generally suffices.

For a different example, assume phone 2000 has Call Forward All set to hunt pilot 8000, and that hunt pilot 8000 has none of its optional forwarding fields set. When another phone (say, phone 1000) dials 2000, CallManager immediately forwards the call to hunt pilot 8000, and a hunt begins. If no hunt parties answer, then a reorder tone will be played to the caller because no other final disposition was configured.

Now assume hunt pilot 8000 has its Forward Hunt No Answer destination set to 9 1 303 499 7111. Repeating the call this time results in a final disposition. When hunting exhausts, the forward settings on the hunt list apply and CallManager redirects the call OffNet to 9 1 303 499 7111, in this case, the atomic time at the National Institute of Standards and Technology (NIST).

Finally, assume that, in addition to having a Forward Hunt No Answer setting, hunt pilot 8000 has its Forward Hunt No Answer Use Personal Preference check box checked. Even though the destination field is still set to 9 1 303 499 7111, the user preference check box now takes priority.

Direct calls to the hunt pilot still result in the call being forwarded to NIST, but callers who first dial another number that is forwarded to the hunt pilot receive call treatment based on the settings of the forwarded phone.

If the forwarded phone has no Forward No Coverage fields set, then the caller hears reorder. If the caller is classified as an external caller and the Forward No Coverage External field on the forwarding party is set, then when the hunt list associated with the pilot is exhausted, CallManager redirects the call to the Forward No Coverage External destination. If, instead, the caller is classified as an internal caller and the Forward No Coverage Internal field on the forwarding party is set, then when the hunt list is exhausted, CallManager redirects the call to the Forward No Coverage Internal destination.

Route Lists and Route Groups

Life is sweet when you have only one gateway for calls to the PSTN. You configure the gateway with the route pattern you want to use for external calls, and as long as the gateway has an available trunk, it can route calls to the PSTN. But when your network grows beyond the capacity of a single gateway, you are posed with a problem: How do you configure CallManager so external calls can use both gateways, and how can you make CallManager choose the correct gateway when only one gateway has trunks available?

Route lists and route groups are the answer. This section contains the following subsections:

• "Route List and Group Operation" provides an overview of the process that route lists and route groups use to route calls.
• "Assigning Gateways to Route Groups and Route Groups to Route Lists" discusses the details of assigning gateways and trunks to route groups.
• "Route-Based Calling and Called Party Transformations" discusses how calling and called party transformations on a route list can override the calling and called party transformations you have specified on a route pattern.

Route List and Group Operation

The behavior of route lists and route groups is straightforward.

A route group represents several individual trunks and gateways to CallManager as a single high- capacity gateway. A route group is little more than a list. When a route group receives a call, it offers the call to the devices in its list according to its distribution algorithm. Route groups support both Top Down and Circular distribution algorithms; these algorithms work as described in the section "Hunt Lists and Line Groups."

If the device can accept the call, the route group's job is done. If the device rejects the call (because it is being fully utilized or is out of service), however, the route group then offers the call to the next device in its list. Only when all devices have rejected the call does the route group reject the call.

Route lists take the abstraction that route groups provide one step further. Although a route group is an ordered list of gateways, a route list is an ordered list of route groups. Where a route group sequentially offers calls to devices in its list, a route list sequentially offers calls to route groups in its list. A route list rejects an outgoing call only when no route groups in its list can accept a call.

Together, route lists and route groups allow you to control which gateways route outgoing calls. They also allow you to order your gateways so that you can route calls over gateways connected to less-expensive service providers before routing calls over gateways to more expensive service providers.

Finally, route lists provide you with additional routing control. The calling and called party transformations on route lists allow you to override, on a route-by-route basis, the calling and called party transformations that you assigned to the route pattern that selected the route list. You might need to override transformations on a particular route basis to properly format a number for the gateway that receives a call. Figure 2-20 demonstrates these features of a route list.

Figure 2-20. Route List and Route Group Operation

Figure 2-20 depicts a CallManager that controls two gateways in San Jose and a gateway in Dallas. For routing purposes, the two gateways in San Jose are equivalentthat is, it does not matter which gateway handles a particular calland they belong to the same route group. The gateway in Dallas belongs in a separate route group.

Both route groups belong to a route list that handles calls from Dallas to San Jose. The route list attempts to provide toll restriction by trying to route the call to the San Jose gateways before the Dallas gateway. The route pattern 9.@ with route filter AREA-CODE == 408 is associated with the route list so that it handles calls to the 408 area code. Furthermore, dialing transformations on the route list convert the 12-digit number that the user dials into a 7-digit number for routing on the San Jose PSTN.

When a user in Dallas dials 9 1 408 555 1212, the route list performs the following steps:

Assigning Gateways to Route Groups and Route Groups to Route Lists

Route lists are composed of route groups, which, in turn, are composed of gateways. This section describes the process of building the route group and route list structure. It consists of two subsections:

• "Assigning Gateways to Route Groups" defines the criteria by which you determine which gateways should share a route group.
• "Assigning Route Groups to Route Lists" discusses briefly some of the ways that you might choose to place route groups in route lists.
• "QSIG and non-QSIG Route Lists" describes restrictions on the types of gateways that can coexist in a route list.

The order of these sections is representative of the way in which you should build your route list structure. First, you start by configuring gateways, which you then place into route groups. When the route groups are organized, you place them in route lists. Finally, you control routing to these route lists by assigning route patterns.

Assigning Gateways to Route Groups

Each gateway endpoint a CallManager can route to can exist in, at most, one route group. The term gateway endpoint is deliberately a bit vague. For purposes of discussing route groups, a gateway endpoint is not necessarily a gateway, nor is it a particular span or channel on the gateway. Rather, an endpoint differs based on the type of gateway.

For example, CallManager has no control over which interface an H.323 gateway, such as the Cisco 2600, routes outbound calls; the H.323 protocol contains no provision for specific interface selection on an H.323 gateway. Rather, the configuration of the Cisco 2600 router determines which interface routes the call. As a result, even if an H.323 gateway contains several individual spans, these spans cannot be added on a span-by-span basis to different route groups. The finest routing granularity that CallManager has for H.323 gateways is the gateway level.

In contrast, CallManager can select individual spans on MGCP gateways with analog interfaces, and as a result, you can place individual spans in different route groups.

Channels of an ISDN or T1 span differ. T1s and E1s are single digital spans that are divided into 23 or 30 logical channels. Although CallManager can route calls to particular channels, it cannot include individual channels in different route groups. You must assign digital interfaces to route groups on a span-by-span basis.

Table 2-50 presents the level of routing granularity CallManager has for each general type of gateway. See Chapter 4 for more information about gateway types.

How should you assign interfaces to route groups? The most flexible way is to assign one interface per route group; however, even though the External Route Plan Wizard takes this approach, it is by far the most unwieldy. As a guideline, assuming you do not need to reserve certain interfaces for privileged users, you should place all interfaces that route to the same type of carrier in the same routing area in the same route group.

For instance, assume you have three gateways. Gateway 1 provides access to a PBX. Gateway 2 is hooked up to a local carrier in the PSTN. Gateway 3 is hooked directly to a long distance carrier.

Gateway 1 probably provides access to extensions that the PBX manages. Even if it provides outside access (through trunk interfaces that the PBX manages), it cannot share route group membership with either Gateway 2 or Gateway 3. Because neither Gateway 2 nor Gateway 3 provides access to the PBX extensions, they are not equivalent for routing purposes.

Gateway 2 and Gateway 3 also probably should not share route groups, even though they nominally provide access to the same place.

One reason is that calls to a long distance carrier require only ten digits for long distance calls; long distance carriers that see the initial long distance direct-dial digit reject the call.

In addition, Gateway 3 provides you with less-expensive access for long distance calls, while Gateway 2 provides you with inexpensive local calls. This situation means that you prefer local calls to route first out Gateway 2 and then out Gateway 3 as a last resort, while long distance calls route out Gateway 3 and then Gateway 2 as a last resort. As a route group can list its gateways in only one order, the gateways must be in different route groups to provide you with the behavior you want.

As a result, Gateway 2 and Gateway 3 are not equivalent for routing purposes, and each must be in its own route group.

If you add a Gateway 4, connected to the PBX, add it to the same route group as Gateway 1, because the gateways are completely equivalent from a routing standpoint.

Assigning Route Groups to Route Lists

Route lists are ordered lists of route groups. Although a given gateway endpoint can exist in at most one route group, a route group can exist in any number of route lists. Figure 2-21 presents a logical view of route lists, route groups, and gateways.

Figure 2-21. Route Lists, Route Groups, and Gateways

A route list is simply a gateway search pattern. For every unique order in which you want to attempt to route calls to gateways, you need one route list.

The purpose of a route list is wholly determined by the route pattern you assign to it and the route groups it contains. The External Route Plan Wizard relies heavily on route lists to provide a fine granularity of permission levels for external dialing, and to implement a variety of fallback strategies when gateways are busy or not available. The section "Routing by Geographic Location (or What the External Route Plan Wizard Builds)" describes in detail the way that the External Route Plan Wizard uses route lists for this task.

However, you can use route lists for purposes other than routing based on geographical location. You can use route lists to select outbound gateways based on anticipated cost. For instance, if you have one route group for gateways connected directly to a long distance carrier and another route group for gateways connected to a local carrier, you can define two route lists to route outbound calls accordingly. Figure 2-22 demonstrates such a configuration.

Figure 2-22. Route Lists Used for Carrier Selection

On the first route list, you define a route pattern and route filter that routes local calls. Although the way in which one dials local calls varies among geographical regions in North America, the route pattern 9.@ with route filter AREA-CODE DOES-NOT-EXIST AND LOCAL-AREA-CODE DOES-NOT-EXIST AND INTERNATIONAL-ACCESS DOES-NOT-EXIST AND SERVICE DOES-NOT-EXIST selects all seven-digit calls that a user dials.

For this first route list, you assign as the higher-priority route group the one that contains gateways connected to the local carrier. The lower-priority route group is the one that contains gateways connected to the long distance carrier.

When users dial a number that matches a seven-digit route pattern, CallManager offers the call to the local carrier gateways before trying the long distance carrier gateways.

On the second route list, you define a route pattern and route filter that routes long distance calls, such as 9.@ with route filter AREA-CODE EXISTS OR INTERNATIONAL-ACCESS EXISTS. For this route list, you assign as the higher-priority route group the one that contains gateways connected to the long distance carrier. The lower-priority route group is the one that contains gateways connected to the local carrier.

When users dial a dialed digit string that includes an area code or international access code, CallManager offers the call to the long distance carrier gateways before trying the local carrier gateways.

Route-Based Calling and Called Party Transformations

The association between a route list and one of its route groups is called a route. The example in the section "Assigning Route Groups to Route Lists" glosses over a detail about the dialed digits when offering a call to a local carrier versus a long distance carrier. Elaborating on this detail can demonstrate the way that called party transformations work with routes.

When CallManager offers a long distance call to a local carrier in North America, often the area code must be preceded with a 0 for operator access for a 1 for a direct-dialed call. This is usually not a problem, because users expect to dial these extra digits. On the other hand, when CallManager offers a call to a long distance carrier, any leading 0 or 1 causes the long distance carrier to reject the call.

Also, when CallManager offers a local call to a local carrier, the call is likely to route properly, but when offering a call to a long distance carrier, CallManager must explicitly include the area code as part of the dialed number. In geographical regions with seven-digit dialing, the caller does not dial any area code for calls to local numbers.

When route lists contain route groups that have different requirements for the dialed digits, the calling and called party transformations on the route pattern do not suffice. Instead, CallManager must transform the calling and called parties on a route-by-route basis. When you select a route group from the Route List Configuration page, CallManager Administration opens the Route Details Configuration page, where you can customize the dialing transformations that CallManager applies when it offers a call to the selected route group from the current route list.

Each route contains the same calling and called party transformations that exist on the route pattern itself. The calling party transformations are the Prefix Digits, Calling Party Transformation Mask, and the Use External Phone Number Mask check box. The called party transformations are the Digit Discarding Instructions, Called Party Transformation Mask, and Prefix Digits.

If all the calling party transformations in the route group details for a specific route group are assigned the default values, the calling party transformations of the route pattern take effect. However, if one of the calling party transformations on the route is set, the calling party transformations on the route group details take effect, instead of the ones on the route pattern.

Similarly, if all the called party transformations for the route group details for a specific route group are assigned the default values, the route pattern's transformations apply. But if any of the called party transformations are specified on the route group details, these settings take effect instead. To prevent digit discarding instructions from taking effect, the value on the route must be , not NoDigits, which causes the full dialing string to be restored.

Note that when you specify transformations on a translation pattern or route pattern, these transformations manifest both on the display of the calling IP phone and in the CDRs. Transformations in the route group details, however, do not reflect themselves on the caller's phone or in the CDRs.

Therefore, completing the example begun in the section "Assigning Route Groups to Route Lists" requires specifying, on a route-by-route basis, the called party transformations to apply to the dialed digits.

When a user dials a local call, the user provides a seven-digit number. For the route from the route list to the route group containing gateways to the local carrier, the only transformation that CallManager needs to apply is to discard the PreDot section of the dialed number. However, for the route from the route list to the route group containing long distance gateways, CallManager must not only discard the PreDot section of the dialed number, but also prepend the local area code (for example, 972). (If different calling users can make local calls from different area codes, you must use several route lists.)

When a user dials a long distance call, the user provides an 11-digit number. For the route from the route list to the route group containing gateways to the local carrier, CallManager needs only to discard the PreDot section of the dialed number. However, for the route from the route list to the route group containing long distance gateways, CallManager must discard any leading 0 or 1, as well as the PreDot section of the dialed number. The digit discarding instruction PreDot 11D->10D accomplishes this task. Figure 2-23 presents this configuration.

Figure 2-23. Local and Long Distance Route Lists

QSIG and Non-QSIG Route Lists

Since the release of CallManager 3.3, CallManager has been incorporating the QSIG protocol to foster feature interoperability with other PBXs and clusters. QSIG, described more thoroughly in Chapter 4, is a framework that allows PBXs to send feature-related messages to each other, as opposed to the traditional basic call protocols that existed prior to QSIG.

Prior to CallManager 4.0, route lists could be composed of any combination of gateway protocols. However, the QSIG protocol imposes some requirements that have made the rules for intermixing gateways in route lists more complicated.

When a feature in one PBX issues a feature message such as "invoke call transfer" to another, QSIG takes into account that the message might encounter non-QSIG trunks along the signaling path. Because non-QSIG trunks don't have the capability to carry the feature message, if the receiving PBX were to try to force the message to cross the non-QSIG span, the feature request would be lost, which would leave the issuing PBX hanging, waiting for a response.

Therefore, QSIG permits a method of operation that allows a PBX to act as a "gateway" PBX. Essentially, the receiving PBX acts as a proxy for the true recipient of the message, which is isolated behind a non-QSIG trunk.

Sometimes, important QSIG messages take place over an actual call SETUP message. SETUP messages contain the digits that enable PBXs to locate a final destination. PBXs are expected to look at the target of the SETUP and determine whether the SETUP is targeted at something local, such as a phone, or if the SETUP is supposed to transit to another PBX. If the SETUP needs to transit, the action of the receiving PBX depends on whether the transit link is QSIG or non-QSIG. If the transit link is QSIG, the PBX simply forwards the QSIG message, but if the transit link is non-QSIG, the PBX needs to operate in "gateway" mode.

Route lists pose a problem for this QSIG behavior. The function of a route list is to find an available gateway, but route lists do this by actually offering the call to the gateway. This puts CallManager in a Catch-22. If the gateway that is to be selected turns out to not be QSIG-capable, CallManager should have operated in gateway mode, but, because the call has been offered, it's too late to do so. If, instead, CallManager arbitrarily decides to operate in gateway mode, some feature transparency will be lost any time a SETUP ends up selecting a route list.

Because this limitation was fairly severe, the CallManager team worked hard to figure out a way to relax the restriction. Some complex internal code permits CallManager to mix certain types of QSIG and non-QSIG gatewaysnamely, QSIG gateways can be freely intermingled with non- QSIG SCCP and MGCP gateways. However, QSIG gateways cannot be intermingled with H.323 gateways.

With MGCP and SCCP gateways, CallManager understands much more clearly what the state of the calls are on those gateways. As a result, when receiving a QSIG message in a SETUP, CallManager can scout ahead to determine whether a QSIG or a non-QSIG span will actually select the call. Using this information, CallManager can decide whether to act as a gateway PBX for the message. Unfortunately, H.323 gateways are more self-containedCallManager cannot even see what circuit-switched interfaces are hooked up to them, much less whether any resources are left on those gateways. Therefore, when deploying QSIG in your network, limiting your gateway deployments to MGCP or SCCP gateways can help ensure that you get the routing flexibility of route lists and the feature transparency of QSIG.