IP Telephony Cookbook by Saverio Niccolini, Jorg Ott, et al - HTML preview

PLEASE NOTE: This is an HTML preview only and some elements such as links or page numbers may be incorrect.
Download the book in PDF, ePub, Kindle for a complete version.

7

The previous chapters described how to set up an IP Telephony site and how to use PSTN

gateways to call external targets.With growing support and usage of IP Telephony, it becomes more and more interesting to interconnect IP Telephony sites and use the IP network to transport calls. Since dialling IP addresses is obviously not an option, inter-domain communication introduces the problem of call routing which can be dealt with in various ways.This chapter lists techniques and solutions for inter-domain call routing.

-} 7.1 Technology

This section starts with listing possible mechanisms and protocols to provide inter-domain address resolution.

-} 7.1.1 H.323 LRQ

With the H.323 protocol, even for intra-domain routing, there is a need to localise the terminals.

Under normal operations, the user of an H.323 appliance configures the H.323 alias identifier and, eventually, the E.164 address number as they are assigned by the service administrator.

Later on, when a call is started, there is a need for the terminal to identify the logical channel of the called party (IP address and destination port) where to send the signalling messages.

If a gatekeeper is not present, call routing is possible using the IP address (that has to be known to the calling party) and a standard destination port. On the other hand, if a gatekeeper is present, both intra-domain and inter-domain routing can be performed using either the alias identifier or the E.164 address. If the called party is registered within the same domain as the calling party, alias mapping is performed internally by the gatekeeper itself, which replies to the calling party with the call signalling address (IP address and destination port) of the called party.

If the called party is registered within any other domain, the gatekeeper has to perform another step before replying to the calling party with the Admission ConFirm (ACF) message containing the call signalling address to be contacted. In order to localise the terminal within the domain, gatekeepers use the Location ReQuest (LRQ).The LRQ message is transmitted by the gatekeeper to other well-known neighbour gatekeepers (if any) or to a multicast address.When the LRQ message arrives to the gatekeeper where the terminal to be localised is registered, such a gatekeeper answers with Location ConFirm (LCF) message containing the information on the logical channel of the called party to be used for the signalling messages. At this point, the gatekeeper knows the call signalling address of the called party and, depending on the call model in use, it proceeds with the normal operation (see Chapter 2).

P.184

index-185_1.png

[IP Telephony Cookbook] / Integration of Global Telephony

Figure 7.1 Location request mechanism

In the case that a gatekeeper reached by the LRQ message does not know the answer to such a location request, there are different possible behaviours depending on the channel which is being used by the LRQ message. If the LRQ message was sent on the RAS channel, then the gatekeeper replies with a Location ReJect (LRJ), whereas no action is taken if it was sent on the multicast channel.This simple mechanism is depicted in Figure 7.1, where the channel being used by the LRQ messages is the RAS one.

When handling calls directed to terminals on the traditional PSTN, the zone gatekeeper is in charge of registering the zone gateways. In such a case, the gatekeeper will take care of replying to the LRQ messages with a LCF message containing the call signal address of the gateway that is supposed to be the one routing the call to the PSTN network.

-} 7.1.2 H.225.0 Annex G

Another H.323-specific mechanism is defined by H.225.0 Annex G. Unlike the H.323 LRQ

mechanism that simply provides a way to translate an address to an IP address and port number, Annex G allows the coupling of further information (e.g., pricing information) to an IP address and to use IP address prefixes for dialling (instead of just allowing complete addresses to be dialled). Furthermore, H.225.0 Annex G is a protocol used for communication between administrative domains, meaning a logical collection of gatekeeper zones (e.g., all gatekeepers used in a university would span the administrative domain of the university).The entities that provide H.225.0 Annex G services are called border elements.

The smallest information unit defined by H.225.0 Annex G is the pattern, which might be either a specific address, an address containing a wildcard or a range of telephone numbers. H.225.0

P.185

[IP Telephony Cookbook] / Integration of Global Telephony

Annex G uses the AliasAddress structure to refer to addresses. Such usage is particularly useful when storing specific or wildcard addresses; thus it is able to carry any kind of address information used by H.323 (see Section 2.2.1.3.1).

Along with the patterns, H.225.0 Annex G stores some routing information containing additional data about pricing, necessary access requests, contact information (which IP/Port to contact and what kind of QoS is provided) and other protocol-relevant data.

Patterns and routing information are grouped in a so-called address template, along with the time to live to indicate how long the template is valid.The address template also contains information regarding the signalling protocols that may be used. Currently, signalling protocols include only the H.3xx protocol family.Templates are grouped together by an identifier, known as a descriptor. An administrative domain advertises templates by advertising descriptors to indicate the type of calls it can resolve.

T1

GK1

BE1

BE2

T2