How V. Cerf and A. Bell Would Jointly Design a Telephony System: A CORBA-Based Multilayer IP Telephony Platform, Combining the Strengths of Both Public Switched Telephone Networks and the Internet

Stefan GESSLER <>
Oliver HAASE <>
Andreas SCHRADER <>
NEC Europe Ltd.


Inevitably, two formerly separated kinds of communication networks -- public switched telephone networks (PSTN) on the one hand and packet data communication networks on the other hand -- are meeting under the umbrella of IP telephony. The thrilling challenge of this situation is to draw the maximum benefit of the network-centric and edge-centric philosophies that accompany the two respective technologies. In this paper we present I2N (Intelligent Internet Telephony) as a novel platform for IP telephony. I2N perfectly integrates the network-centric and the edge-centric approaches, exploiting the best of both. This platform provides various layers of a comprehensive IP telephony system, from basic call signaling, via access to user directories and the support of various aspects of mobility, to the rapid integration of value-added services. Together with the integrated AQUARIUS QoS framework, this approach is perfectly suited to realize user-tailored communication applications with high-quality media support.



One particular strength of the network-centric approach of the PSTN is excellent support of security, privacy, and service quality. The edge-centric approach, well known from the Internet, offers enormous flexibility for quick and easy development of new, possibly user-tailored services by any participant, creating new business models.

In this paper we present I2N as a novel platform for IP telephony. I2N perfectly integrates the network-centric and the edge-centric approaches, exploiting the best of both. This platform provides various layers of a comprehensive IP telephony system, from basic call setup signaling, via access to user directories and the support of various aspects of mobility, to the rapid integration of value-added services.

Fundamental for the design layout was the decision to build a homogeneous architecture, which relies on CORBA's remote method invocation (RMI) mechanism. Many features of the CORBA communication paradigm are extremely valuable for the development of distributed applications. The expressiveness of passing message parameters as method parameters and getting the acknowledgment delivered as the method's result value, together with CORBA's implicit error handling, results in application programming interfaces (APIs) that are easy to understand and fast to implement, and hence cost-effective. Even in terms of performance, we can show the competitiveness of our approach compared to others.

Our platform comprises a complete set of all necessary components (see Fig. 1).

Figure 1: General overview over I2N platform components

There are a number of approaches existing or under development that cover different aspects of IP telephony. For instance, there are the Internet Engineering Task Force (IETF) Session Initiation Protocol (SIP) [10, 11], the ITU-T protocol suite H.323 [12] and the related architecture of ETSI Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON) [13], as well as some proprietary architectures (e.g., AT&T's TOPS [7]). The main focus of most of these approaches is interoperability with PSTN (through gateway technology). Consequently, the forthcoming service integration concepts show a strong similarity with the Intelligent Networks (IN). Without doubt, IN is very useful, proven, and appropriate for circuit-switched, network-centric technologies. However, the Internet has completely different characteristics: it is connectionless, open, programmable, and edge centric, and it offers transportable software through the Java programming language. Hence, it is worthwhile to reconsider what service platforms are appropriate for the Internet.

Active directories

For the support of user and service mobility, directories are the basic technology. One of the most widely accepted standards for directories is the TCP/IP-based LDAP [6]. LDAP is used by a large variety of platforms and applications (e.g., the TAPI 3.0 telephony platform [5], the telephony platform TOPS [7], the Novell Directory Services [NDS] [8], Netscape's Navigator [see also [9] for an overview]).

Our active directories bridge the gap between LDAP and CORBA technology by defining LDAP-like directory services in OMG IDL. Besides language and transport layer independence, the directory services also exploit CORBA's strong type system to deliver the results of a query in the correct type format and to express as much of the semantics of a query through syntactic structures as possible. We have implemented both, pure CORBA directories and wrappers to existing LDAP servers, which we have interconnected to a network of CORBA directory servers, each of which provides fully transparent access to the entire distributed information base. The interworking of pure CORBA servers with LDAP wrappers paves the path for a smooth migration from LDAP to CORBA directory services.

The performance measurements of our implementations show the competitiveness of CORBA directory servers compared to LDAP servers. Moreover, the general-purpose IIOP protocol proves to perform even better than the dedicated LDAP protocol [1, 2].

In I2N, we use the Domain Name System (DNS) hierarchy of the Internet to distribute the global naming space into administrative domains. Each subscribed user belongs to a particular home domain, for which one directory server is responsible. The subscriber has a personal entry with this home directory server. This entry consists of

Whenever an I2N user registers with the system, the registry of the hosting domain delegates the registration to its nearby directory server (see section Call signaling). Through the distribution mechanisms of the directory service, even a foreign mobile user will be registered with the appropriate directory server (i.e., with the directory server of the user's home domain).

As can be seen, the directory is the core enabling technology for user mobility as well as service mobility. Service mobility is crucial to provide anytime anywhere access to personalized services.

Call signaling

As already discussed in the Introduction, call signaling runs under the control of the I2N platform, to ensure security and to enable accounting and billing. To be specific, a user's signaling state machine (SSM), which is capable of handling incoming and outgoing call requests, runs remotely on a particular signaling server. Two peer SSMs as well as a user's telephony application and SSM communicate via CORBA RMI.

Figure 2: Call setup using SSMs and the appropriate CORBA interfaces

Fig. 2 shows an example where a mobile caller is setting up a call to a callee, who is currently logged at the callee's home location. At the time when the caller registers with the platform (1), the registry of the hosting network initiates the creation of an SSM for the caller's telephony application (2). In addition to the user registration (see section Active directories), the object reference of the newly created SSM is stored with the user's home directory server (3). We assume that the registration of the callee has already been performed.

All call requests to, and call indications from, other parties go through the SSM, which acts as a signaling proxy for the respective telephony application. An SSM provides some remote methods to the telephony application as well as some remote methods to other peer SSMs. The interface SSM comprises the first set of methods, that is, methods to be invoked by the telephony application. These are methods to initiate a call request (call()), to cancel a pending request (cancel()), to accept an incoming request (accept()), to refuse it (refuse()), or to hang up a connection (hangup()). The interface PeerSSM consists of the methods to be invoked by peer SSMs, which are acting on behalf of other users. In principle, the methods are intended to forward the requests, which came in via the SSM interface.

In order to be I2N compliant, each telephony application on top of the platform must implement the interface TelephonyApplication. This requirement ensures that the SSM that is acting on behalf of a particular application is allowed to invoke the appropriate call-back methods to indicate incoming requests, other users' responses to previously signaled call requests, and so on.

In the above example, the caller invokes a call request through the SSM interface (4). The SSM looks for the right object reference by a directory query (5) and forwards the request to the remote SSM via the PeerSSM interface (6). The callee's SSM uses the TelephonyApplication interface to indicate the call to the user (7), who can accept the call (8). This answer is again forwarded to the caller's SSM (9), which finally uses a call-back method of the caller's client to finish the setup procedure (10).

QoS support

The essential function of an IP telephony system is the transmission of real-time media streams. Voice is essential to compete with the PSTN, but delivering general audio as well as video information is without doubt a desirable addition. Due to the connectionless, packet-oriented nature of IP-based networks, no service quality can be guaranteed for the transmission parameters, like bandwidth, delay, or jitter. Especially in wireless access networks (e.g., GSM/GPRS, UMTS) there is even a significantly high probability for packet loss. Some kind of QoS mechanism is therefore mandatory for an acceptable provision of voice and video services on the Internet.

AQUARIUS (Adaptive Quality of Service Architecture for Intelligent Universal Services) is a comprehensive but also generic framework consisting of a distributed, hierarchically organized collection of all necessary QoS components to provide end-to-end QoS. AQUARIUS components are located at end systems as well as at intermediate nodes. AQUARIUS provides mechanisms for adaptive scaling, filtering, and transcoding for a broad range of audio/video codecs ranging from low-bandwidth speech codecs (e.g., CELP) to high-quality video streaming (e.g., H.261/H.263). The user's static, global QoS policies (like default parameters and price/quality relationships) are stored in the CORBA directory servers as part of the personal profile information (in accordance with the IETF QoS Policy Framework [14]). The user's dynamic local QoS wishes are captured via GUIs and mapped to appropriate network parameters within distributed QoS Brokers. The QoS Brokers are also responsible for establishing and managing the system components in such a way that the specified high-level QoS policy is approximated. Using knowledge about the underlying network layer, available codecs, and so on, the QoS Broker chooses the appropriate QoS strategy and configures all other AQUARIUS QoS components. With the usage of Java Media Technology (Java Media Framework [JMF] [15]) for QoS management components and CORBA for intercomponent communication (e.g., out-of-band signaling of monitoring results), the AQUARIUS framework is able to download, install, and maintain QoS components on demand to react in a flexible manner to changing network or group communication session characteristics. AQUARIUS is perfectly able to use underlying network QoS technologies, like the IETF IntServ [3] and DiffServ [4] architectures. The AQUARIUS QoS Brokers are therefore capable of supporting all kinds of multimedia requirements by choosing an appropriate compromise between resource reservations (via RSVP; mainly in corporate managed local area networks [LANs]), appropriate Classes of Service (CoS) (via DiffServ Codepoints; mainly in the backbone), and AQUARIUS adaptive scaling mechanisms. Although originally designed to be smoothly integrated into the I2N framework via CORBA interfaces, AQUARIUS can also be used to support any kind of multimedia communication application.

Value-added services

The rapid and easy introduction of new user-tailored intelligent services will be the key issue for the market acceptance of IP telephony. We tackle this goal by splitting a service into a stationary part and two movable parts. The stationary part runs at the service provider's site and executes the essential computations of the service. Examples are databases or Web servers with product information for e-commerce services. There are many reasons that require the stationary part not to be bound to one particular programming language (e.g., performance, embedded run-time environments, skills of programmers, and integration of legacy code, to mention only a few). One movable service part is used for the configuration of a service (e.g., to specify the trigger conditions for services running on the callee site [e.g., call distribution] or to choose the personal "look and feel" of the service). In order to support service mobility, the personal settings of the configuration parameters are stored with the stationary service part. The characteristic aspect of this service part is that it is performed before the actual service invocation. One illustrative example for a configuration service part is a GUI for the user's preselection of the personal addresses of some frequently called persons for an abbreviated dialing service. This list is transmitted to, and stored within, a server in the provider's domain. The second movable service part is a GUI that allows for the actual invocation of a service. To continue the abbreviated dialing example, the invocation of the service causes

Both movable service parts (service configuration and execution) must be implemented in Java. To ease communication between the stationary part -- which can be implemented in any programming language -- and the movable parts, we use the CORBA RMI paradigm (i.e., the stationary part must be implemented as a CORBA object). Either part of a service can be missing; for example, the well-known call forwarding service does not need an invocation part because this service is invoked passively when a request indication arrives.

In our environment, a service is described through its input and its output. We have defined some standard types, such as Person or PersonalAddress. If a certain service (component) s2 requires, for instance, input of type t2, and service (component) s1 produces output of type t1 which is a subtype of t2, then s1 and s2 can be concatenated to a new complex service (s1, s2). For instance, the abbreviated dialing service delivers the personal address of the selected person, which can be used to configure the call forwarding service.

Telephony application

Since the I2N architecture together with the AQUARIUS QoS framework provides all necessary signaling and media facilities to realize basic call signaling and voice/video streaming for telephony, applications using I2N can be built in a very simple way as a stateless collection of GUIs, either for the active request of a call or as call-back methods for incoming indications. As a prototype we have developed HiTel (Heidelberg Intelligent Telephony) as a Java application using Swing components that can also be downloaded from the Web. This allows for the automatic deployment of new releases.

Figure 3: HiTel client

In the default version, HiTel supports only basic call signaling. Since the client is stateless, it does not even know which actions are impossible at a certain "state" and therefore is not able to provide user guidance mechanisms (e.g., disabling parts of the interface). From this point of view, HiTel is only a kind of mediator between the user and the user's SSM. Other applications that want to disable options that are not allowed in the current call state, are left to hold (part of) the call state themselves. On the other hand, by subscribing additional value-added and AQUARIUS QoS services, HiTel can be seen as a virtually user-tailored telephony client, perfectly suited for the demands of the user without changing one single line of code in the application/applet itself.

As indicated in the section Value-added services, additional intelligent services can be provided by arbitrary service providers. HiTel provides mechanisms to subscribe, configure, maintain, and invoke these services from within the telephony client. Usually, service providers will install a hypertext markup language (HTML) page with information about the type of service and the price for subscription as well as mechanisms to invoke the subscription (e.g., a JavaScript-based subscribe button). To subscribe a service, the downloadable parts of the service will be transported to and evaluated within HiTel. To configure a service, HiTel provides mechanisms to invoke the configuration interface of the service. To maintain services, the list of currently subscribed services can be viewed and modified. To invoke a service from within HiTel, HiTel provides an appropriate interface in the service management interface, as well as service invocation buttons on the main window of the client to allow very fast access to frequently used services (see Fig. 2). The configuration of these buttons will be stored with the user's personal entry at the user's home directory server (see section Active directories).

HiTel also provides mechanisms to concatenate chains of services. When a service is needed to deliver a certain parameter of type t1 as a result value, or when a certain parameter of type t2 is available and can be used as an input parameter for the invocation of a service, the appropriate collection of possible service chains is determined by the system automatically. For example, if a certain name within a phonebook is chosen, a list of all services that can use the parameter of type Person as an input value (e.g., call forwarding configuration, info page invocation, abbreviated dialing configuration) is available. This can be regarded as a context-sensitive functionality enabling even inexperienced users to exploit the complete set of services in a very convenient way.

For the integration of QoS configuration and media render interfaces, HiTel is able to use the AQUARIUS system via the respective APIs. The AQUARIUS Media API can be used, for example, to capture audio or stream RTP/RTCP flows, but also to acquire a panel to render received video data. The AQUARIUS QoS API can be used to determine the user's current quality wishes (e.g., audio codec choice or video resolution settings). In this respect, the provision of QoS can be envisaged as one particular value-added service that can be provided by different competing QoS providers. With the mechanisms described above, users can arbitrarily configure the HiTel system according to their personal preferences.

Gateways to other technologies

I2N is designed as an integrated IP telephony system comprising various aspects of telephony systems. Individual aspects are also covered in some way by other existing IP telephony systems. The aimed flexibility requires us to provide interworking facilities to those systems as well. Moreover, we do not intend to provide all desirable functionality within I2N itself but to rely on existing services. Interworking or direct access is achieved by connecting the different systems via gateways. For I2N, therefore, several gateways are planned or already under development.

Conceptually there are four different kinds of gateways in I2N:

  1. The IP telephony call signaling gateway, which provides interworking between call signaling methods of I2N and other IP telephony systems such as H.323 or SIP. In this case the gateway transparently acts as an endpoint in both systems.
  2. The IP telephony service control gateway. Some of the services in I2N have counterparts in other IP telephony systems. The gateway makes use of their signaling interfaces and hence simulates a service client of the respective system, whereas in I2N it represents a new service or an enhancement for an I2N service.
  3. SCN (Switched Circuit Networks) service access gateway. This gateway directly interconnects I2N services with SCN service entities.
  4. Value-added services gateway. Value-added services -- either call related or call independent -- are becoming the main drivers for IP-based telephony systems. Therefore, one of the main objectives of the I2N design is to offer interoperability as well as far-reaching openness toward those services. Such services are currently still in their infancy. Typical services are various types of directory and location services.

Figure 4: Multilevel gateway support in I2N design

The reader may have noticed that no interworking entity to any SCN phone service is planned. Although the ability to make calls between SCN and IP systems is indispensable, we believe that it is advisable to make a slight detour using existing SCN gateways (e.g., H.323 or MGCP based) rather than spending the effort to reinvent similar entities.

In some cases, data services provided by other IP telephony systems can be linked either via IP telephony service control gateways or via appropriate value-added service gateways. A well-known example is the name resolution service, available in all IP telephony systems. The first option has the advantage that the regular interface of the service is used (i.e., the consumer acts in the same way as service clients within the foreign system). If IP telephony interworking with that system is desired anyway, then certain gateway modules already exist. The drawback is that only the service functionality provided at that interface is available. Management functions are usually not accessible. Furthermore, the consumer normally has to make a pseudo-registration in the foreign network first. This can be avoided by establishing an individual value-added service gateway. It supplies all functions of the service itself. The service access is performed directly, and the service itself can be maintained also from within I2N. In some cases this option is not available if the value-added service does not provide any direct access point.


In this paper we have presented a novel integrated architecture for IP telephony services. The proposed architectural components cover the complete set of all necessary functionality, ranging from basic call signaling to the support of mobility via active directories and mechanisms for the subscription of user-tailored value-added services. The architecture also includes the AQUARIUS QoS framework for the support of adaptive media transmission.

Through the usage of the CORBA communication paradigm, the I2N architecture combines network layer and programming language independence. With the provision of the Java-based HiTel telephony client we demonstrated the ability to use downloadable value-added services to enhance the overall functionality on demand. Gateways allow the interoperability with other IP-based telephony architectures, such as H.323 or SIP, and circuit-switched traditional telephony networks.

The future deployment of IP-based telephony systems will mainly depend on the availability of services that are not possible or not seen so far in the traditional telephone networks. With mechanisms to download new value-added service on demand, new business models can be identified for service providers. The same argument holds for the provision of Quality of Service, which can be interpreted as one special instance of such a value-added service. An open question remains in the automatic detection of service incompatibilities (e.g., conflicts in the necessary modification of signaling state machines).

Future research activities can be identified in the area of accounting and billing. Through the introduction of new business roles for value-added service and QoS providers, appropriate mechanisms are essential to handle the negotiation of prices and to control the registration of actual service usage. Another very important aspect is security. To protect users from unsocial behavior by other users' applications and to protect service providers from illegal use of resources, appropriate mechanisms are needed. The possibilities and restrictions of small end devices (e.g., embedded systems or stand-alone IP phones without operating systems) also present a challenge for researchers.


  1. O. Haase, A. Schrader, K. Gheis, and R. Janz. CORBA Directories for Virtual Home Environments. In Proc. SoftCOM'99 Intl Conference on Software in Telecommunications and Computer Networks, Split - Rijeka, Croatia, Trieste - Venice, Italy, Oct 1999.
  2. O. Haase, A. Schrader, K. Gheis, and R. Janz. Mobility Support with CORBA Directories. In Proc. CNDS'00 Intl Conference on Communication Networks and Distributed Systems Modeling and Simulation, San Diego, USA, Jan 2000.
  3. R. Braden, D. Clark, and S. Shenker. Integrated Services in the Internet Architecture: An Overview. IETF RFC 1633, June 1994.
  4. A. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss. An Architecture for Differentiated Services, IETF RFC 2475.
  5. Microsoft. IP Telephony with TAPI 3.0. White paper, 1999.
  6. Lightweight Directory Access Protocol (v3). IETF RFC 2251, Dec 1997.
  7. N. Anerousis et al., TOPS: An Architecture for Telephony over Packet Networks, IEEE Journal on Selected Areas in Communication, vol. 17, no. 1, January 1999.
  8. Novell. NDS 8: Discovering the Cross-Platform, Full-Service Directory. White paper, 1999.
  9. H. Maass. Location-Aware Mobile Applications Based on Directory Services. Mobile Networks and Applications, vol. 3, no. 2, pp. 157-173, August 1999.
  10. J. Rosenberg, J. Lennox, and H. Schulzrinne. Programming Internet Telephony Services. IEEE Network Magazine, vol. 13, no. 3, pp. 42-49, May/June 1999.
  11. M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg. SIP: Session Initiation Protocol. IETF RFC 2543, March 1999.
  12. H.323: Packet-based multimedia communications systems. ITU-T Recommendation, February 1998.
  13. Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON), Network Architecture and Reference Configurations, Phase II: Scenario 1 + Scenario 2. ETSI Technical Specification TS 101 313, February 1999.
  14. S. Gai, J. Strassner, D. Durham, S. Herzog, H. Mahon, and F. Reichmeyer. QoS Policy Framework Architecture. IETF Internet Draft, February 1999.
  15. Sun. The Java Media Framework Version 2.0 API.