Internet-Supported PSTN Services

Last year a colleague of ours was called by a reporter from a well-known technical publication and asked to describe the effort of the PSTN/Internet Internetworking (pint) working group in the Internet Engineering Task Force (IETF). Our cautious colleague wisely decided that the best he could do under the circumstances was to read out to the reporter a few selected sentences from the working group charter published by the IETF on its Web page. Specifically, he stressed—prompted by the pint Web page—that the purpose of pint was to “address connection arrangements through which Internet applications can request and enrich PSTN . . . telephony services.” The reporter wrote down what she heard. Later, in accordance with her agreement with our colleague, she sent to him the draft of the article. The article was accurate except for one word: enrich had turned into unleash—this is what the reporter heard over the telephone line (an atypically imperfect telephone line, we presume). When the amazed author called the reporter with the correction, she seemed to be disappointed. (And so are we. We wish the pint charter really did talk about unleashing the telephone services, because this is precisely what the Internet-supported PSTN services are all about!)

In his recent article on Intelligent Network, Scott Bradner correctly observes that the intelligence of IN is strictly in the network, not on its edges. This lack of edge intelligence is precisely what the interworking of the Internet and IN is to change—once and forever!

The basic goal of the IN technology is to allow the user of an Internet host to create, access, and control the PSTN services. A simple example of what the technology can do is the click-to-dial-back service, where you click on an icon displayed on a Web page and the PSTN call is established as the result.

As simple as it sounds (and a crude implementation of this service is just as simple), the unleashing quality of this service alone should not be underestimated. The competition among the long-distance service providers is such that they would do almost anything to get a call flowing through their networks. With Web-based access, their customers are around the world! There are still countries that protect their networks by forbidding the call-back service; people may get angry about such backward and anticompetitive practices, but click-to-dial-back, which technically is not a call-back service, is a way to get even.

Once you start thinking about the possibilities of tweaking this basic concept, you will find that the possibilities for creating new services are virtually unlimited. We will demonstrate a straightforward extension of click-to-dial-back to drastically improve on a PSTN-only service.

The service in question, interestingly enough, came to life as an application of the Web business model (but not the Web technology) to the PSTN. Telephony service providers in Europe started to market free telephone calls to those who would agree to listen to several minutes of audio advertising. The advertisers have so far found the approach ineffective—pure audio is hardly the best means of delivering advertising today. This already bad effect is further worsened by the “push” nature of audio advertising.

Now, with the technology just described, the prospective caller can access the service provider’s page on the Web, where he or she can also subscribe to the service and register a profile stating the preference for the types of products he or she wishes to learn about. Every time a call is to be made, the caller can then be walked through a video presentation of the advertisement on his or her Internet appliance—possibly accompanied by the audio portion over the PSTN line. The caller can control the pace of the advertisement; when it is finished, the caller will be prompted for the number he or she wishes to call and then connected to that number.

There are several early developments in this area (Hubaux et al., 1998). In the relevant architecture, the SCPs and SNs are connected to the Internet (which is fairly easy to achieve because they are almost invariably implemented on the Unix system platform).

Figure 1: The architecture for Internet-supported PSTN service delivery.

It is important to repeat that with this arrangement only SCPs and SNs—but by no means the switches—are connected to the Internet and thus can communicate with other IP hosts.

The service control function can be distributed to Internet hosts as much as the PSTN service provider allows and the owner of a particular IP host (who may be the same PSTN service provider) wishes to handle. In the WebIN, the IP host is actually a Web server, and part of the service control function (called WebSCP) is moved into the Internet (Low, 1997; Low et al., 1996). This arrangement can be used to provide the main features of the PSTN VPN service—the private numbering plan and closed user group in particular (Hubaux et al., 1998). The translation map of the enterprise-significant numbers to the PSTN-significant ones, as well as the specification of the closed groups (including the calling privileges of each group member), are kept in the databases accessible through the Internet. Part of the SCP service logic is executed by the WebSCP. While there is very little interoperability among the legacy IN implementations, integrating them with the Internet immediately establishes a common language for interworking. Even more significant is that the service creation and service management are also moved (via the Internet) to the edge of the network.

As exciting as the opening of PSTN call control to the Internet hosts may be, there is a serious and not completely solved problem associated with it. This problem is security, and it is ubiquitous in the Internet. While trusted relations between the PSTN and IP entities can be established between the enterprise networks, opening IN control fully to anyone on the Internet remains problematic. There may be no need for IN control to be fully opened, except in the cases of some well-understood services.

Potential security issues also prevent (at least for the time being) direct connection of the switching offices to the Internet. If that were done, the SCP itself could be placed on the Internet, and subsequently anything that IN does presently could be done in the Internet. Although there is a single ITU-T standard, it specifies different options. These options reflect implementations that differ not only between different continents (that is, Europe and North America) but also among the network operators in the United States. (Bell Operating Companies use the option corresponding to the Bellcore AIN; some IXCs use proprietary or European versions of IN.) Thus, direct interconnection of the PSTN switches and Internet SCPs, even if secure, would not provide global interoperability. Only interworking of the PSTN service control with the Internet hosts holds the promise (on which it has already started to deliver) of universal, global access to service control of the PSTN.

To conclude this section, we would like to repeat that so far we have taken an intentionally one-sided approach to the role of IN in the integration of PSTN and the Internet. Our only goal was to demonstrate how IN can be used to give more control in creating and executing services to the edge of the network. At this point, it is important to observe an interesting duality: While the PSTN benefits from Internet-based service creation and control, the IP networks greatly benefit from the existing PSTN-based service control for at least three different reasons: (1) efficiency of the access to IP networks; (2) provision of certain combined PSTN-Internet services; and (3) support of the existing PSTN services in the IP telephony environment.

No comments:

Post a Comment