![[INET'99]](/web/20081012020048im_/http://www.isoc.org/isoc/conferences/inet/99/proceedings/inet99sm.gif)
![[ Up ]](/web/20081012020048im_/http://www.isoc.org/isoc/conferences/inet/99/proceedings/up.gif)
![[Prev]](/web/20081012020048im_/http://www.isoc.org/isoc/conferences/inet/99/proceedings/prev.gif)
![[Next]](/web/20081012020048im_/http://www.isoc.org/isoc/conferences/inet/99/proceedings/next.gif)
Burkhard STILLER <stiller@tik.ee.ethz.ch>
George FANKHAUSER <gfa@tik.ee.ethz.ch>
Gabriela JOLLER <joller@tik.ee.ethz.ch>
Peter REICHL <reichl@tik.ee.ethz.ch>
Nathalie WEILER <weiler@tik.ee.ethz.ch>
ETH Zürich
Switzerland
IP (Internet Protocol) Telephony requires the support of guaranteed services and charging to provide a valuable service for potential customers. The quality of long-distance telephony calls via the Internet is heavily affected by the load of the links that the call has to traverse. As different quality requirements of users exist, the Internet has to support different service classes. Therefore, an advanced services network model is required.
In turn, and that is the main motivation for this work, if at least two traffic classes exist on the Internet, the right incentive must exist for any user to choose the traffic class that optimally fits the necessary requirements and will be the most efficient in terms of prices to be paid. Therefore, the integration of charging and Quality-of-Service (QoS) interfaces for IP telephony are important to stimulate the future use of the Internet. This paper gives a first overview of OCIT (Open Charging Interfaces for IP Telephony), an experimental platform for standards-based IP phones that are enhanced with QoS and charging support.
Because public Internet access is determined by a high growth rate, the use of this communications network for more than just traditional data applications increases as well. IP (Internet Protocol) telephony is an example of advanced services on the Internet of the near future. IP telephony is one of the Internet applications that became popular for the following reasons. On one hand, the integration of traditional well-known voice applications -- e.g., the phone as an external device -- with widespread data communication technology based on the Internet offers the potential for developing highly integrated computer-based telephony applications. On the other hand, the costs for using conventional telephone network calls are quite high for long-distance and the international connections. IP telephony promises to save considerable resources by multiplexing voice and data over the same network. However, audio quality in a pure best-effort network has been observed to become quite poor, especially in congested periods. It requires Quality-of-Service (QoS) support for network service to obtain an audio quality that is similar to the one of a conventional phone call. In addition, compared with standard telephony, charging for services in the packet-based Internet remains an open issue [13]. Suitable pricing models have to be developed for an application in the IP telephony domain. These models have to be integrated into current IP implementations to allow for a practical charging and accounting approach for calls and services.
An off-the-shelf IP telephony product has been selected as an application base for the work presented in this paper. This selection is based on a survey of IP telephony products with respect to a potential integration of QoS and pricing interfaces into Application Programming Interfaces (API) [11]. The presented platform is called OCIT, "Open Charging Interfaces for IP Telephony." It has been extended by an open charging and QoS interface. The charging interface and implementation have been developed from scratch, based on pre-investigated pricing model parameters and requirements including static and dynamic pricing approaches. The QoS interface uses a quasi-standard of a resource reservation protocol interface, namely RSVP (Resource Reservation Protocol). Based on a set of QoS parameters of this protocol and a particular user profile for telephony specifications, appropriate cost and QoS mapping functions have been defined and evaluated in a prototype implementation. These mapping functions allow for a range of QoS parameters to be specified. However, only a subset of these parameters is relevant and applicable to different cost models. RSVP has been extended with charging and accounting functionality, such as pricing information or price requests depending on the type of pricing model applied.
This paper is organized as follows. Section 2 introduces the networking model environment applied within this work. Based on these basics the design of the open charging and QoS interfaces are presented in Section 3. The implementation description in Section 4 is followed by conclusions in Section 5.
The networking environment chosen for OCIT is influenced by current and recent developments in the Internet. In particular, IP forms the basis for the application of an IP phone. Since the conventional Public Switched Telephone Network (PSTN) has already offered voice service for several decades and is widespread, IP telephony is required to interact with this established network. Therefore, telephony devices (i.e., conventional phones) will be used in future communication in addition to Personal Computers (PC) or workstations. This already shows the need for an integrated hardware device for dealing with voice calls. In addition, exchange points of calls may be located within the PSTN or on the Internet, based on the kind of connectivity the user currently uses. Therefore, scenarios to be distinguished are (1) phone-to-phone, (2) phone-to-PC or PC-to-phone, or (3) PC-to PC communications. Details on these different cases and the problems to be solved can be found in [11]. In any of these scenarios, the question of charging phone calls requires the exchange of information at various points. However, due to the complete lack of any charging approaches in the current Internet, the problem to be solved is restricted in a first approach at this point to the pure PC-to-PC communication scenario, where no traditional PSTN is involved, but a service-integrated Internet is required. The IP telephony product used for this work is Netmeeting [12].
The current network model for the Internet is a pure best-effort network, since connectivity and ease of deployment have been the major driving forces in the Internet's first days. However, as already mentioned, service integration becomes essential, especially for commercialized Internet use. It is worth discussing this trend under different perspectives, e.g., ease-of-use, free availability, or globalization for everyone. However, the work described in this paper is concerned only with the technical implementation.
Service integration within the Internet is discussed for two cases: the Integrated Services model (IntServ) [3] and the Differentiated Services model (DiffServ) [2]. IntServ is based on the explicit reservation of network and endsystem resources on hosts and routers to allow for the guarantee of services, particularly the guarantee of a predefined or negotiated set of QoS parameter values. The Resource Reservation Protocol RSVP [8] has been developed to replace the ST-II reservation protocol because of its sender-based scheme, where different multicast receivers could not be supported efficiently. It allows for the specification of resources to be reserved as well as information to be exchanged concerning ongoing reservations between participating hosts and routers. An RSVP signaling channel is used for setting up a specific path between sender and receiver. This path is determined by a set of QoS parameter values corresponding to sender's and receiver's requirements. Using a routing protocol resources are reserved along this path from the sender to the receiver. Especially, the RSVP signaling is used to reserve resources along the path according to flow specifications that require these resources.
Another approach to provide different Internet services is provided in terms of a backbone technology called DiffServ. While IntServ handles IP packets based on pre-negotiated data flow requirements, DiffServ services are based on contracted parameters that are predefined in terms of service profile [4]. These profiles allow for the marking of packets to be sent as in-profile, if profile limits are not violated. Otherwise, out-of profile packets may be discarded within the DiffServ backbone, if congested periods occur. In addition, the idea for the backbone network includes the fact that these profiles are valid for a number of aggregated flows, showing similar behaviors and requirements. Because work on the IETF started at the end of 1997 and the proposed charging and QoS interfaces for IP telephony are based on available signaling protocols in 1998 -- and there is still no interoperable or feasible DiffServ signaling today -- features, functions, and interfaces at the host side will remain very similar to the solution discussed below [1].
The OCIT protocol architecture for IP telephony applications is based on the Integrated Services (IntServ) protocol stack to achieve the possible control of user requirements by means of a resource reservation protocol. Based on this protocol layering, as depicted in Figure 1, the developed APIs for the IP telephony include the setting of user-driven parameters for telephony quality and the charging information (cf. Section 4.5 below).
FIGURE 1. Protocol and System Architecture
Based on the availability of protocols and systems in support of IntServ, the Crossbow toolkit [5] provides a suitable design environment. Developed for the experimentation and implementation of Next Generation Internet protocols, IntServ mechanisms such as a packet classifier or packet filtering and scheduling on the host's and router's implementation platform have been investigated for their suitability for multimedia data transport and processing. Within this IP telephony work, the design and implementation environment have been applied to the Netmeeting IP Telephony application, the use of RSVP, and appropriate developed extensions for open charging and QoS interfaces. For these reasons, the implementation of a simple version of RSVP as well as the porting of the full ISI RSVP implementation [8] to Crossbow, provide the excellent position for the design, implementation, and evaluation of IP telephony feature extensions in terms of the developed open charging and QoS interfaces.
Current RSVP implementations do not support the exchange of charging or accounting information. RSVP used for OCIT has been extended by appropriate pricing and payment objects [7]. Figure 2 displays the objects necessary for the system extensions described in this paper.
FIGURE 2. Object Extensions to RSVP
These additional RSVP objects include:
Two different dynamic pricing models have been implemented for OCIT. The "Smart Market" model [10] where each router regularly performs an n-fold second price auction (the resources are sold to the n highest bidders for the unit price bidder n+1 is willing to pay) has been refined in order to distribute the signaling overhead over time and to avoid reservation delays for routes comprising several links. Hence, our "Delta Auction" approach processes requests as soon as they arrive whereas actual reservations are still performed after regular periods of time [7]. Note that the resulting resource distribution turns out to be identical to the simple auction model. A second pricing model is based on offering different service classes and charging an application the basic price of the respective class multiplied by a factor that increases quadratically as soon as the current throughput of the class excesses its allocated bandwidth.
Concerning the billing approach chosen, charging records are being collected within the router for every user. As it is described later in the implementation (cf. Section 4.4), the financial information, as well as data on the IP telephone call, are presented to the user within his user interface.
The implementation of OCIT integrates charging into a network QoS framework and end-to-end resource reservations into an IP telephony application. The results obtained are based on experiments with two different pricing models, where the dynamic pricing method covers congestion-sensitive and usage-based components:
For a qualified practical deployment, a graphical user interface is included in the system to offer all IP telephony users a set of QoS parameters and their predefined values as well as a feedback for current charges for the ongoing or finished call. This feedback mechanism defines an important aspect of user satisfaction evaluations, since a clearly subjective rating of IP telephony quality achieved and current price charged are obtained.
As an implementation platform for OCIT, a mix of off-the-shelf components and experimental systems has been chosen. Basically, the "edge" of the network is populated by personal computers (PC) using commercially available IP telephony software while the "core" of the network is built using experimental router platforms (cf. Figure 3). PCs are running Windows NT version 4.0 and Netmeeting as IP telephony software. This endsystem setup is enhanced with telephony hardware connecting real handsets and a special version of the RSVP signaling software enhanced with charging functionality. It has to be noted that RSVP on these PCs does provide the necessary end-to-end signaling and charging solution, but does not implement traffic control (i.e., it does not reserve real network resources). Assuming overprovisioning in local area networks (LANs) this functionality has been neglected intentionally. Figure 3 shows a typical Internet telephony setup with the sender or caller (S), Internet Service Providers (ISP), and a receiver or callee (R). Standard H.323 messages [9] are routed through a gatekeeper (G). A billing server is used for offline collection of invoice data. Finally, ingress- (I) and egress-routers (E) at ISPs are responsible for RSVP signaling and collection of accounting data.
FIGURE 3. A Typical Internet IP Telephony Setup
The core of the network is built on routers based on the NetBSD Unix operating system using the implementation of router plug-ins [5] that implement fair queueing for appropriate traffic control and RSVP enhanced with charging to allow ISPs to enhance admission control with payments.
The introduction of dynamic QoS pricing schemes into a flat-fee based communication network like the Internet requires the possibility for an evaluation of actual market prices in order to judge as a user the following two aspects:
Therefore, an additional, but optional phase has been introduced for OCIT, particularly keeping the current RSVP signaling phase-wise untouched. This so-called query phase introduces a second set of path and reservation messages for a complete call before the standard path and reservation messages are being exchanged. As a result of this extension, there are two phases for handling reservations (cf. Figure 4, shaded area).The query phase is considered optional and the reservation phase mandatory.
In conventional RSVP, the PATH message is used to determine the path for a flow. The sender sends a PATH message towards the receiver and the packet is routed through the network. Each hop on the path not only forwards the PATH message, but also uses and modifies the PHOP_ADDRESS entry, determining the previous hop. The PHOP_ADDRESS of the received packet is stored as part of soft state in the router and maintained for a certain period. For the packet sent to the next hop, this entry is replaced by the hop's own address. This results in a soft state chain for specific flows along the path from sender to receiver.
FIGURE 4. The Two RSVP Phases
The semantics of the PATH message for the query phase is similar to a standard RSVP reservation phase. The only difference is the new REQTYPE object that is used at the receiver to reply with the correct RESV message extension concerning the calculation of the current price (cf. below).
Due to the receiver-based reservation characteristics of RSVP, the actual reservation is made by the receiver by sending a RESV message back to the sender. This RESV message travels along exactly the same path in reverse order as the PATH message making use of each soft state PHOP_ADDRESS set on each router. On the arrival of a RESV message, the forwarding router reacts by reserving the requested resources for the particular flow if available. The standard compliant result is a reserved path from sender to receiver.
For an optional price query the RESV message is extended by the REQTYPE object. Further on, additional objects are used for exchanging pricing information. Thus, each router on the path updates the entries according to their local pricing characteristics (i.e., actual price for the requested reservation on the particular hop). This allows for the calculation of price information for sender requests only. This price may change during the actual reservation in the case of dynamic pricing models applied, since the market situation may have changed. During the regular reservation phase, this pricing calculation is performed again, determining the final price for the upcoming reservation period as defined in the RSVP standard.
The implementation platform of OCIT centers around a signaling system that integrates existing standards protocols as well as new signaling protocols that are needed for charging purposes. Figure 4 shows the integration of H.323, RSVP, and customer protocol extensions in a message sequence chart. As shown in Figure 5 the unmodified Netmeeting application is redirecting its H.323 signaling messages [9] to a gatekeeper that is usually located in the access providers network. The gatekeeper implements a fully functional H.323 proxy that allows for the analysis of all H.323 protocol elements. It is used to detect the audio flow's properties, in particular its bandwidth requirements and its flow-id consisting of the IP addresses, port numbers, and transport protocol identification. This flow-related information is signaled back to the end-systems where it is used to initiate appropriate resource reservations using the local RSVP API. Although there is a version of Netmeeting supporting native RSVP, we chose to intercept H.323 messages in order to be application independent and to use our own RSVP version enhanced with charging objects on the end-systems. Note that the IP phone and the charging-related processes on the end-system are completely decoupled. As depicted in Figure 5, an H.323 gatekeeper [9] with a proxy protocol stack is used to detect the flow-id of calls. On top of RSVP, charging messages signal the resource usage of each user to the ISPs.
The caller and callee processes, running in parallel with the IP phone applications, use the standard RSVP API to signal resource reservations. Also integrated into the caller and callee process are charging functions that are visible to the user. In the current prototype system no real and secure payment scheme has been implemented, therefore accounting information such as money spent is displayed only but not debited from a user's account. Charging relevant information is embedded into an extension of the RSVP API and further transported using opaque object extension in the RESV and PATH messages (cf. Section 3).
FIGURE 5. Signaling Architecture of an Off-the-shelf IP Phone Supported by RSVP-based Reservations
As an extension of the Application Programming Interface (API) an approach using simple Java applets has been selected. It reflects the decoupling of H.323 signaling (session setup) and RSVP (resource reservation and charging) and offers the advantage of being able to interoperate with almost any commercial IP telephony product. The disadvantage of this approach might be a slightly user-unfriendly system due to its lack of complete integration, but it is considered sufficient serving as a prototype. This prototype is complemented by appropriate user interfaces as described in Section 4.5 below.
QoS support is implemented in a very simple fashion: Using Netmeeting's codec dialog [12], a voice coder is selected with its respective bandwidth requirements. Via the H.323 proxy, these requirements are automatically translated into RSVP flowspecs by the caller and callee processes (cf. Figure 5).
Charging support is a little more complicated and fully implemented in the Java applets for the caller and callee processes. According to the charging protocol used, dynamic market prices queried are displayed at the user interface (cf. Figure 7). Once a user decides to initiate a call, billing records are continuously displayed at the UI.
The user of an IP telephony application will remain a human user. Therefore, the human user will identify his or her requirements in terms of QoS parameters of the IP telephony application in use. Due to the fact that these requirements should not be expressed (only) by technical means, because the user may not be aware of bandwidth, delay, or error rates in any network in use, an easy-to-use and simple user interface for expressing his or her needs is essential. Fortunately, in a certain sense, IP telephony provides a single service, called the telephony service based on an Internet and it is concerned with audio data transmission. Therefore, two interactions between human user and application are required:
Obviously, the selection of the destination may be chosen from the user or selected from a local database. As the destination format for a participant's address, the Domain Name System (DNS) name of the machine can be chosen. However, before the establishment of an IP telephony call, the choice of the audio quality has to be determined from the human user. This audio quality currently is independent of technical parameters at the user interface level. Therefore, it offers different levels of quality as indicated in Figure 6.
From 5 kbit/s to 64 kbit/s, very low to telephone quality levels can be selected. Providing an efficient and direct mapping between these user-level QoS -- the user-driven selection of a codec -- and underlying network QoS, a static mapping is implemented based on the resulting Codec data rates which Netmeeting is able to support. This results in the use of different bandwidths that are being handled from the reservation protocol afterwards.
Based on these two selections and choices, the establishment of an IP telephony call is initiated, particularly requesting the selected quality from the network. However, as expressed above, the communication costs involved in this call should be determined -- at least the user should be made aware of the current price to be paid for this call and he or she explicitly has to accept or reject the call's price. For these reasons, a second window pops up and summarizes the destination selected and the quality chosen (this time including the technical bandwidth parameter for information only) in addition to the current price. This price is determined at that point in time when the initiation is submitted by pressing "OK."
FIGURE 6. Selecting Audio Quality Through Netmeeting's Codec Dialog
Of course, based on the pricing model in use, the price always will remain the same in static pricing models or it will adapt to the market price, if dynamic or congestion-sensitive pricing schemes are applied. This price is valid for the next complete reservation period of this call, as used from RSVP. By acknowledging this price, the resource reservation is performed and the final call is established in full. A price feedback is provided within the main window to allow for a user-driven decision on the acceptance of the current price for all periodically upcoming reservation periods.
Finally, after the completion of the IP telephony application, the user is informed on all details of the IP telephony call. These details are included into the original window of the IP telephony call setup (cf. Figure 7). Billing information includes the following details:
Depending on the price models applied and the policy chosen, this information may be omitted partially. However, minimal information is required to set up a correct bill, which encounters the destination's IP address, the duration of the call, and its total price.
FIGURE 7. Resulting Billing Information
In the case of automatic bidding mechanisms in dynamic markets, a last step can improve the future perceived performance for users. Based on per-user profiles and simple feedback information (cf. Figure 8), strategies may be shifted between conservative or aggressive behavior. Figure 8 shows an experimental implementation of such a feature asking for a simple feedback from the user concerning delay, audio quality, and overall satisfaction.
FIGURE 8. Optional User Feedback Dialog
The results of this work show that the integration of commercial applications, such as the Netmeeting IP telephony, standard protocols, such as RSVP and H.323, and experimental protocol extensions, such as the charging extensions applied to RSVP, are possible. This is especially valid and promising for signaling protocols, since the charging and pricing tasks to be performed require the use of existing protocol architectures.
Important to mention is the fact that the design of a user interface can cover this signaling complexity to a certain degree, except for the need of specifying the callee and the quality requested for. However, exactly these two issues are the only ones a user is interested in. As shown before, the quality selection is based on the explicit user-driven Netmeeting's codec selection. Still, this requires an unnecessary degree of technical complexity visible at the user interface and should be avoided in future implementations.
In addition, concerning the economic dimensions of this work, complex pricing functions can be abstracted away from the user completely. If a highly dynamic pricing scheme or a pure flat fee pricing scheme are intended, all signaling protocol extensions handle these matters transparently. With respect to the billing required, this work assumed the existence of a traditional billing system. Although from a research point of view clever payment systems are needed, particularly in the case of electronic payments with, e.g., digital cash.
All of the features described above have been implemented in a prototypical manner. The resulting implementation and the described system were composed out of several experiments and studies conducted in the TIK laboratory. Therefore, a product-like implementation will integrate all different windows of the user interfaces in a single one, it will hide away Netmeeting's codec selection, and will simplify the signaling processes in terms of a to be defined signaling architecture integrating network layer signaling (RSVP) and application layer signaling (H.323) as proposed in appendix II of the H.323 recommendation [9].
Future work on the OCIT architecture will provide an interface to payment systems. Thus, the IP telephony service can be paid for in a secure and convenient manner. We currently develop a micro-payment system for online correlated payments supporting multiple sellers as needed in an IP telephony application with continuous charging. JavaCards, (i.e., Java-based smartcards) are used as containers of the digital money and the necessary secret information. Furthermore, in addition to the implemented pricing models, different approaches are investigated in order to provide a complete validation of the prototype presented above. Although the charging approach already works transparently over different network clouds, e.g., LANs without resource reservation and accounting, it has to be investigated how the behavior of RSVP-based charging will be, if it is used in conjunction with Differentiated Services-based (DiffServ) transit networks. Appropriate pricing at the edges of DiffServ network clouds as well as RSVP message forwarding are major topics in this field.
Thanks are addressed to a number of TIK students, namely M. Foser, S. Kniess, L. Mysyrowicz, R. Ritler, P. Tscharner, S. Tufekovic, and C. Vögtli, who implemented and evaluated IP telephony scenarios.
[1] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss: An Architecture for Differentiated Services, RFC 2475, December 1998.
[2] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin: Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification, RFC 2205, Internet Engineering Task Force, September 1997.
[3] R. Braden, D. D. Clark, S. Shenker: Integrated Services in the Internet Architecture: An Overview, Request for Comments, RFC 1633, Internet Engineering Task Force, June 1994.
[4] D. D. Clark and W. Fang: Explicit Allocation of Best-Effort Packet Delivery Service, IEEE/ACM Transactions on Networking, Vol. 6, No. 4, August 1998.
[5] D. Decasper, Z. Dittia, G. Parulkar, B. Plattner: Router Plugins -- A Modular and Extensible Software Framework for Modern High Performance Integrated Services Routers, ACM Computer Communication Review (SIGCOMM'98), Vol. 28, No. 4, 1998.
[6] D. Decasper, M. Waldvogel, Z. Dittia, H. Adiseshu, G. Parulkar, B. Plattner: Crossbow -- A Toolkit for Integrated Services over Cell-Switched IPv6, Proceedings of the IEEE ATM'97 Workshop, Lisbon, Portugal, June 1997.
[7] G. Fankhauser, B. Stiller, C. Vögtli, B. Plattner: Reservation-Based Charging in an Integrated Services Network, 4th INFORMS Telecommunications Conference, Boca Raton, Florida, March 1998.
[8] ISI implementation of RSVP, URL: ftp://ftp.isi.edu/rsvp/release/rsvpd.rel4.1a4.tar.Z.
[9] ITU-T Recommendation H.323: Series H: Audiovisual and Multimedia Systems, Infrastructure of Audiovisual Services -- Systems and Terminal Equipment for Audiovisual Services, Packet-Based Multimedia Communications Systems, February 1998.
[10] J. K. MacKie-Mason, H. Varian: Pricing the Internet, Technical Report, University of Michigan, February 1994.
[11] L. Mysyrowicz: Interfaces for IP Telephony in Support of QoS and Charging, Student Thesis, Computer Engineering and Networks Laboratory TIK, ETH Zürich, Switzerland, February 1998.
[12] Netmeeting, URL: http://www.microsoft.com/netmeeting.
[13] B. Stiller, G. Fankhauser, B. Plattner, N., Weiler: Charging and Accounting for Integrated Internet Services -- State of the Art, Problems, and Trends; INET'98, The Internet Summit, Geneva, Switzerland, July 21-24, 1998.