Gateway Location

What we have touched on so far are the core gateway functions—signaling and media conversion. Yet, to support an IP telephony call end to end, other things need to be taken care of. One such thing is gateway location.

Suppose a call originated in (or was passed on to) an IP network, and the call needs to be terminated in the PSTN. There are many gateways that could do the job, but only a few may be suitable for a particular call. For instance, the gateway definitely should be chosen so as to terminate the call at the point in the PSTN as close to the called party as possible. In this case, terminating at the gateway that is connected to the called party’s end office is clearly the optimal solution if other factors are not involved.

But other factors are typically involved, such as the load and capability of gateways in question, the IP network provider’s and the end user’s preferences, agreements with the PSTN service providers, and—to top it all—the costs to be incurred.

Thus, gateway location is an important activity that is bound to become more complex as more telephony gateways are built and deployed. A considerable amount of research on the subject has been done (Schulzrinne and Rosenberg, 1999) and more or less detailed proposals on that matter have been submitted to both ITU and the IETF [specifically, the IP Telephony (iptel) working group].

As it happens, the Internet has had a similar problem with interdomain routing, which has been solved. It should come as no surprise, then, that many ideas of a specialized routing protocol [called Border Gateway Protocol (BGP)] have been used to develop the gateway location technology.

In the tradition of IP routing, the process is dynamic and the knowledge is built using distributed computation performed by the gateways. Before the decision can be made regarding which gateway to choose, the database of eligible cooperating gateways has to exist. This database is built in the act of gateway discovery. Figure 1 shows a representative architecture that spans several administrative domains. Each domain, which contains several gateways and some number of endpoints (for example, PCs), has at least a logical entity, called a location server. The main job of the location server is to learn about the gateways in its own administrative domain as well as in other domains and to construct the database of the gateways. In the intradomain case, this is usually achieved in a registration process. Each gateway signs on with the location server when started up and updates its availability status whenever necessary. The information is propagated by means of an intradomain protocol, such as the Service Location Protocol.^[7]

Figure 1: Architecture for gateway discovery.

In comparison to the intradomain case, discovery of gateways in other domains is not as straightforward a process. Complicating the process is the need for a business agreement between the administrative domains for any exchange of gateway information or any use of the gateways by users in a different domain. A location server can only propagate to another location server the gateway information that is permitted by the agreement between the administrative domains to which they each belong. Similarly, synchronization of the database in one domain with that of another and selection of the route of a call are subject to the intradomain agreement and policy. As a result, there cannot be a single global database of gateways where a user can look up and select a gateway as desired. Instead, different databases may be available in different domains based on the respective business agreements and associated policies. The database contains the IP address of a gateway and a range of telephone numbers that the gateway can terminate. In addition, it contains the attributes of the gateway, such as signaling protocols (for example, SIP and H.323), usage cost, and the provider’s identification number, which we have mentioned before. A location server uses the attributes to decide which gateways are to be used for terminating a call to a particular number or to be further advertised to other location servers.

Interdomain gateway discovery is carried out through an interdomain protocol, such as the Telephony Routing Information Protocol (TRIP), which is under development in the IETF. As mentioned before, an inter-domain gateway discovery protocol resembles a routing protocol. It also shows significant differences, however. The most important are that the inter-domain gateway discovery protocol runs at the application level and runs between location servers, which may not be adjacent and, unlike routers, do not forward IP packets.

As far as access to the gateway database is concerned, it is an activity that is independent of gateway discovery. There are several possible approaches for such database access using different protocols. One protocol is Lightweight Directory Access Protocol (LDAP), which, as its name suggests, is for access to any directory organized in a special tree structure. When LDAP is used, the gateway database is organized based on the LDAP data model. Another protocol is Service Location Protocol, which has been designed for locating a networked service based on service attributes rather than the name (or location) of the network host providing the service. Logically, it can be used to find gateways given a set of user preferences. Yet another protocol is HTTP, the communications enabler of the World Wide Web. In this case, the gateway database has a Web front end, which allows a user to query it through Web-based forms. We should note that an inter-domain gateway discovery protocol is actually another possible candidate. Nothing prevents it from being used for retrieving information in the gateway database.