Lesson 2 Routing Conference Calls with H.323 Gatekeeper

H.323 clients such as NetMeeting 3.0 register with H.323 Gatekeeper by using an alias such as a user name or e-mail address that is easier to remember than an IP address. The purpose of call routing rules is to assist H.323 Gatekeeper in resolving these aliases and to determine whether and where to route conference calls.

After this lesson, you will be able to


Describe the purpose of call routing rules

Explain how H.323 Gatekeeper processes call routing rules

Configure call routing rules to forward conference calls in H.323 Gatekeeper


Estimated lesson time: 45 minutes

Call Routing Rules

To enable real-time conferencing between endpoints, H.323 Gatekeeper needs to know how to route calls that are destined for alias names. H.323 call routing rules specify a destination and parameters to match part or all of a requested alias. When a unique Q931 address is not included in a call request, H.323 Gatekeeper tries to match each H.323 routing rule that has been configured with the requested alias.

Figure 8.6 shows the routing rule types and parameters that you can configure through the H.323 Gatekeeper snap-in. The default call routing rules that H.323 Gatekeeper includes resolve all requested destinations within the local registration database or on the local network. This means that you do not need to configure any additional routing rules if you only want to enable videoconferencing on your local network.

Figure 8.6 Call routing rules and rule parameters

Follow these steps to create a call routing rule:


In the console tree of ISA Management, expand the Call Routing folder.
Do one of the following:
To create a phone number rule, right-click the Phone Number Rules icon, and then click Add Routing Rule and follow the on-screen instructions.
To create an e-mail address rule, right-click the Email Address Rules icon, and then click Add Routing Rule and follow the on-screen instructions.
To create an IP address rule, right-click the IP Address Rules icon, and then click Add Routing Rule and follow the on-screen instructions.

The following section describes how H.323 Gatekeeper searches for the alias of a registered active terminal according to routing rules.

Phone Number Rules

Phone number (E164) rules specify the parameters shown in Table 8.1. The item names in parentheses are those given to parameters in the New Routing Rule wizard when those parameter names differ from the corresponding column names in the details pane of ISA Management.

Table 8.1 Phone Number Rule Parameters

H.323 Gatekeeper determines which rules match the alias in the call request. A phone number alias can use the numbers 0 through 9 and the number sign (#), asterisk (*), and comma (,).

Example of a Phone Number Rule

Suppose that a caller requests translation for the phone number 95551234#3344.

H.323 Gatekeeper attempts to match the digits up to the first special character or the end of the string, if there is no special character. In the phone number 95551234#3344, the alias used for rule matching is 95551234.

Tables 8.2 and 8.3 contain example phone number rule patterns and matching parameter types (prefix or exact).

As specified in Table 8.1, when you configure the matching parameter as a prefix type, this designates that the pattern specified in the routing rule will be declared a match if it matches the first numbers of a phone number alias. A matching parameter configured as exact designates that the pattern will be declared a match only if the pattern specified matches the complete phone number alias. Note that a null or blank pattern will always match when the matching parameter is prefix.

A prefix type is configured in a phone number rule when you leave the Route All Phone Numbers Using This Prefix check box selected. When you clear the check box, the pattern is configured as an exact type.

The examples listed in Table 8.2 will successfully match the 95551234#3344 phone number. In the first example, the pattern 9 is configured as a prefix type, which matches the phone number's prefix. In the second example, the pattern 9555 is also specified as a prefix type, and these four digits match the first four digits of the phone number alias. In the third example, the pattern 95551234 is specified as an exact type. This is the only exact type pattern that will correctly match the given phone number alias. Finally, in the last example, an empty pattern is configured as a prefix type. Such a rule will match every phone alias. The default phone number rule is configured with an empty pattern of the prefix type.

Table 8.2 Phone Number Rule Pattern Examples – Matching

The examples in Table 8.3 would not match the 95551234#3344 number. In the first rule, the pattern 8 is specified as a prefix type. This does not match the phone number, which begins with the number 9. The second rule specifies the pattern 9555 as an exact type. This rule will not match because the exact phone alias is 95551234, not 9555.

Table 8.3 Phone Number Rule Pattern Examples – Not Matching

IP Address Rules

IP address rules apply only to requests for translation of IP address strings that take the form of a.b.c.d., for example, 192.168.154.13.

IP address rules specify the parameters shown in Table 8.4.

Table 8.4 IP Address Rule Parameters

When a specified pattern matches and the IP address rule affects a given call, the call is routed to the destination specified in the IP address rule. The destination types for IP address rules you can select are the following:

None (no destination). The call is disconnected.

Gateway/proxy. The call is forwarded to the selected H.323 Gateway, Proxy server or Internet firewall.

Gatekeeper. The call is forwarded to a gatekeeper residing in a

different zone.

Multicast gatekeeper. The call is forwarded to a group of multicast gatekeepers.

Local network. The called party resides in the same network as the caller. The call is returned to the callee to resolve.


IP Address Rule Resolution Example

Suppose that a caller requests translation for an IP address string in the form of a.b.c.d. After attempting to match the digits of the string with the patterns configured in various IP address rules, H.323 Gatekeeper finds three matching rules for a.b.c.d.

Once H.323 Gatekeeper has established which routing rules match, the routing rules are sorted for additional processing according to the following requirements.

Rules with the highest number of bits in the subnet mask have precedence over rules with fewer bits in the subnet mask. For example, an IP address string of 192.168.154.13, with a subnet mask of 255.255.255.192, would have a higher number of bits then an IP address string of 192.168.154.13 with a subnet mask of 255.255.255.0.

If two rules contain the same pattern, a rule with matching type exact has precedence over a rule with matching type prefix.

If two rules contain the same pattern and the same matching type, a rule with a lower metric number assigned to it has precedence over a rule with a higher metric number.


E-mail Address Rules

E-mail address rules specify the parameters shown in Table 8.5. The item names in parentheses are those given to parameters in the New Routing Rule wizard when those parameter names differ from the corresponding column names in the details pane of ISA Management.

Table 8.5 E-mail Address Rule Parameters

H.323 Gatekeeper attempts to match the domain portion of the e-mail alias with the rules. Table 8.6 describes how the domain portion is obtained from an alias.

Table 8.6 Domain Portions of User Aliases

The alias accounting1 is an example of what is known as a dotless alias, which is not a standard alias format.

If a call request contains the e-mail address someone@microsoft.com, the domain portion is microsoft.com.

Table 8.7 presents examples of parameter specifications in four e-mail address rules. The following pattern and matching parameter specifications would match the alias someone@microsoft.com correctly. In the first example, the pattern "com" is specified as a suffix type. This matches the alias someone@microsoft.com because the alias does end in the letters "com." In the second example, the pattern "microsoft.com" is specified as a suffix type. This pattern matches the alias someone@microsoft.com because this alias includes the string "microsoft.com" as its suffix. The third example shows that the pattern "microsoft.com" will match the alias "someone@microsoft.com" when this pattern is specified as an exact type. This is because what is being matched in email address rules is not the entire user alias but only the domain portion of the user alias. This is in fact the only pattern of type exact that will match the alias "someone@microsoft.com." Finally, the fourth example shows that a blank pattern of suffix type will match the given alias; in fact, it will match every email alias. The default e-mail address rule uses a blank pattern of suffix type.

Table 8.7 Sample Pattern Matches for an E-mail Address Rule

The rules whose parameters are specified in Table 8.8 would not match the alias someone@microsoft.com correctly. In the first example, the pattern "com" is configured as an exact type. This does not match the exact string of the domain portion of the email alias. In the second example, a blank pattern is configured as an exact type. This pattern will only match an email alias with no domain specified.

Table 8.8 Sample Non-Matching Patterns for an E-mail Address Rule

If a call request alias contains someone and the domain portion is an empty string, the only rules that match this domain portion are those shown in Table 8.9.

Table 8.9 Dotless Alias Matches for an E-mail Address Rule

After H.323 Gatekeeper has established which routing rules match, the routing rules are sorted for additional processing according to the following conditions:

Rules with patterns containing more domain elements have precedence over rules with patterns containing fewer domain elements. For example, accounting1.accounting.microsoft.com has precedence over microsoft.com.

If two rules contain the same pattern, a rule with the matching type exact has precedence over a rule with the matching type suffix.

If two rules contain the same pattern and the same matching type, a rule with a lower metric number has precedence over a rule with a higher metric number.


Rule Processing and Destinations

After H.323 Gatekeeper creates the sorted list of rules that match an alias specified in a call, it processes each rule in order. How the rules are processed depends on the type of destination specified by the rule.

The function of a call routing rule is to specify a destination. Each rule can specify one of the nine destination types described below. If you want to make a particular gateway/proxy, Internet Locator Service (ILS) server, gatekeeper, or multicast group available for selection in a routing rule, you must first run the Add Destination wizard. You can run the Add Destination wizard by right-clicking the Destinations node in the H.323 Gatekeeper snap-in and clicking Add Destination.

None

This destination stops rule processing. Even if there are other matching rules having lower metric values (higher numeric value) following the None rule, H.323 Gatekeeper rejects the request and returns the message "Cannot be resolved."

Registration Database

This destination finds the alias in the local registration database. If the alias is of type E164, H.323 Gatekeeper looks for the phone number string up to, but not including, any special characters. For example, if the original string is 95551212#3344, Gatekeeper uses only 95551212. The registration database can then match the string to an IP address.

If the alias is of Email-ID or H323-ID type, the lookup is done using the complete alias, not only the domain portion. Because the two types are interchangeable, a user registered with an Email-ID of someone@microsoft.com is successfully resolved when querying for the H323-ID of someone@microsoft.com, and vice versa. If an entry is found, its address is returned in the confirmation to the client and the processing stops. Otherwise the processing continues with the next rule.

This destination cannot be used for IP aliases.

Gateway/Proxy

This destination specifies a particular H.323 proxy, or gateway, and lists an IP, DNS, or NetBIOS address. H.323 gateways are required if you want to route your call through the PSTN. (ISA Server does not include an H.323 gateway.)

In networks with multiple proxies or gateways, if name resolution is required, H.323 Gatekeeper randomly chooses one of the returned IP addresses. The process of random IP address selection balances the network load by allowing H.323 Gatekeeper to choose from multiple proxies or gateways. The resulting address is returned to the client. The client is responsible for proceeding with the call to connect to the supplied address. If an entry is found, the address is returned in the confirmation to the client and the processing stops. Otherwise, the processing continues with the next rule.

Internet Locator Service (ILS)

This destination specifies a Microsoft Site Server computer running Internet Locator Service (ILS) for name resolution. It works only for the e-mail address namespace queries. It is an uncommon format that is used to support backward compatibility.

First, the H.323 Gatekeeper conducts name resolution for the IP address of the server running Site Server ILS. If necessary, it then queries the server.

The H.323 Gatekeeper performs at least one query with the complete alias. If the query fails and the alias has the standard e-mail address format, such as someone@microsoft.com, the H.323 Gatekeeper extracts the user name and queries again the ILS for entries beginning with someone. This provides the client that tries to find someone@microsoft.com with the opportunity to find an ILS entry such as someone@accounting5.accounting.microsoft.com. If neither query returns an entry, H.323 Gatekeeper moves to the next rule.

Gatekeeper

This destination specifies the IP, DNS, or NetBIOS address of another H.323 Gatekeeper. The local H.323 Gatekeeper conducts name resolution to determine the IP address of the destination H.323 Gatekeeper. After that, the local gatekeeper queries the remote gatekeeper with a special location request. When H.323 Gatekeeper receives a location request, it attempts to resolve the alias by using its local registration database, regardless of what the rules specify. If the distant H.323 Gatekeeper returns a Q931 address, it is returned to the client. Otherwise, rule processing continues.

Multicast Gatekeeper

The destination type specifies that the destination is a multicast group. The H.323 Gatekeeper sends a location request message using the multicast protocol. H.323 Gatekeeper listens and processes incoming location requests only on the 224.0.1.41 multicast group, even though other multicast groups may exist. If any entry is found, the address is returned in the confirmation to the client and the processing stops. Otherwise, processing continues with the next rule.

DNS

This destination type can only be used for e-mail address queries. The H.323 Gatekeeper resolves the domain of the alias using DNS, regardless of the user portion of the alias. In someone@microsoft.com, the domain of the alias is microsoft.com. If any entry is found, the address is returned in the confirmation to the client and the processing stops. Otherwise, rule processing continues.

Active Directory Directory Services

Active Directory can be specified as a rule destination for e-mail address rules. When Active Directory is configured as the destination, the Active Directory store is queried for the ipPhone attribute of the matching user object, and the call is routed to this IP phone number.

Local Network

This destination type is valid only for IP aliases. H.323 Gatekeeper returns the address represented by the alias. Because a resolution or translation is not required and the destination is directly reachable, the IP address that is represented by the requested alias can be used as the query address.

Applying Rules to Calls

The following section provides examples of how call routing rules are applied to inbound and outbound calls.

Inbound Calls

When H.323 Gatekeeper receives an inbound query, it identifies the type of alias request—whether it is an E164, H.323-ID, or Email-ID. H.323 Gatekeeper then compares this alias to the list of configured rules, compiles the matching rules, and sorts them by placing those rules with the lowest metric value highest on the list. Next, the gatekeeper goes through the list of rules, in order, until either the requested address of the alias is resolved, or the search fails. Finally, H.323 Gatekeeper sends a confirmation or rejection to the originating client, depending upon whether the address is found.

For example, an e-mail namespace request would be processed in this manner. Suppose you are working at Microsoft and want to use NetMeeting 3.0 to call a person who also works at Microsoft and uses the e-mail alias someone@microsoft.com.

An admission request is sent to H.323 Gatekeeper for someone@microsoft.com. H.323 Gatekeeper searches the rules list, which could consist of the rules listed in Table 8.10.

Table 8.10 Main List of Rules (Example)

The H.323 Gatekeeper rule engine sorts the matching rules for the domain part microsoft.com and creates the filtered rules list shown in Table 8.11.

Table 8.11 Example Rule Matches

H.323 Gatekeeper uses the first rule to try to find someone@microsoft.com in the local registration database. If the registration exists, H.323 Gatekeeper returns a confirmation along with the address to the origination client. If no address is returned, H.323 Gatekeeper continues looking, going to the second rule, Gatekeeper "otherzone," for resolving the request. H.323 Gatekeeper works its way down the rules list until an address is returned or until it gets to the None rule. When the None rule is encountered, the query fails and a "Cannot be resolved" message is sent. Once the None rule has been reached, no other rules are processed, regardless of their weighted metric value.

Outbound Calls

When a registered client places an outbound call, an admission request is sent to the H.323 Gatekeeper. In the request, the H.323 client specifies the destination alias. If H.323 Gatekeeper finds the address for the destination alias, it returns an admission confirm, and the requested destination address is sent to the originating client. If the destination address is not found, it continues to process the rules list to resolve the request.

An outbound request to another domain will be forwarded to the remote ISA Server and resolved. This process is explained in following example.

A NetMeeting 3.0 client at the Acme company calls someone@microsoft.com. If the domain name is external or unknown, the following rule listed in Table 8.12 may be the first to match.

Table 8.12 Sorted List of Rules (Example)

In this case, H.323 Gatekeeper informs the ISA Server computer that the address is external to the network. The ISA Server computer then initiates the DNS lookup sequence. If the query returns a fully qualified DNS computer name, H.323 Gatekeeper then performs an additional DNS query to find the destination IP address.

Lesson Summary

Call routing rules allow H.323 Gatekeeper to resolve alias names and to determine whether and where to route videoconference calls. When a unique IP address is not included in a call request, H.323 Gatekeeper tries to match each H.323 routing rule you have configured with the requested alias.

Call routing rules include phone number rules, e-mail address rules, and IP address rules. Phone number rules designate patterns of numbers to match phone number aliases. E-mail address rules configure domain name suffixes to match H.323-ID aliases. IP address rules configure IP address patterns to forward to specified locations. Once H.323 Gatekeeper has established which routing rules match, the routing rules are sorted for additional processing.

When H.323 Gatekeeper receives an inbound query, it identifies the type of alias request—whether it is an E164, H.323-ID, or Email-ID. H.323 Gatekeeper then compares this alias to the list of configured rules. It then compiles the matching rules and sorts them by placing those rules with the lowest metric value highest on the list. Next, the gatekeeper goes through the list of rules, in order, until either the requested address of the alias is resolved, or the search fails. Finally, H.323 Gatekeeper sends a confirmation or rejection to the originating client, depending upon whether the address is found.

When a registered client places an outbound call, an admission request is sent to the H.323 Gatekeeper. In the request, the H.323 client specifies the destination alias. If H.323 Gatekeeper finds the address for the destination alias, it returns an admission confirm, and the requested destination address to the originating client. If the destination address is not found, it continues to process the rule list to resolve the request.