Open Charging and QoS Interfaces for IP Telephony

Transcription

1 Open Charging and QoS Interfaces for IP Telephony Burkhard Stiller, George Fankhauser, Gabriela Joller, Peter Reichl, Nathalie Weiler Computer Engineering and Networks Laboratory TIK, ETH Zürich, Gloriastrasse 35, CH 8092 Zürich, Switzerland, [ stiller gfa joller reichl weiler ]@tik.ee.ethz.ch Abstract IP (Internet Protocol) Telephony requires the support of guaranteed services and charging to provide a valuable service for potential customers. It has to be considered carefully, that the quality of long-distance telephony calls via the Internet is heavily affected by the load of the links which the call has to traverse. As these different quality requirements of users will 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 will exist in the Internet, there must be the right incentive for any user to choose the traffic class which optimally fits his requirements and will be the most efficient one in terms of prices to be payed. Therefore, the integration of charging and Quality-of-Service (QoS) interfaces for IP telephony are important to stimulate future use of the Internet. This papers gives a first overview of OCIT (Open Charging Interfaces for IP Telephony), an experimental platform for standardsbased IP phones that are enhanced with QoS and charging support. 1 Introduction Since public Internet access is determined by a high growth rate, the usage of this communication network for more than just traditional data applications increases as well. IP telephony is an example for advanced services on the Internet of the near future. IP (Internet Protocol) Telephony is one of the Internet applications which become 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 which is similar to the one of a conventional phone call. In addition, compared to standard telephony, charging for services in the packet-based Internet remains still 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 has 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 (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 costs models. 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. 2 Environment The networking environment chosen for OCIT is influenced by current and recent developments in the Internet. Particularly, IP forms the basis for the application of an IP phone. Since the conventional Public Switched Telephone Network (PSTN) has already offered INET 99: The Internet Summit, San Jose, California, U.S.A., June 22 25, 1999

2 voice service for several decades and is wide-spread, 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 in the Internet, based on the kind of connectivity the user currently uses. Therefore, scenarios to be distinguished are (1) phone-tophone, (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]. 2.1 Internet Service Models 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 usage. 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 [8] has been developed in order to replace the ST-II reservation protocol due to 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 signalling 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 signalling is used to reserve resources along the path according to flow specifications which 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 which 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. Since work in the IETF started at the end of 1997 and the proposed charging and QoS interfaces for IP telephony is based on available signalling protocols in 1998 and still there is no interoperable or feasible DiffServ signalling today features, functions, and interfaces at the host side will remain very similar to the solution discussed below [1]. 3 Design Basics 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). Netmeeting IP Telephony Application Reservation and Charging API (enhanced) IP Protocol QoS and Charging Data Telephony Data 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 has been applied to the Netmeeting IP Telephony application, the use of, and appropriate developed extensions for open charging

3 and QoS interfaces. For these reasons, the implementation of a simple version of as well as the porting of the full ISI 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. 3.1 Protocol Extensions Current implementations do not support the exchange of charging or accounting information. 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. IP Header Header Body Objects Pricing Objects Length 20 Type PRICE Length 21 Type PAYER Length 22 Type REQTYPE Length 23 Type BID Length 24 Type PROVIDER FIGURE 2. Object Extensions to These additional objects include: PRICE: This object is used for exchanging information on the current market price for reservations. Each hops adds its own current market price for the reservation to the price received from the previous hop. The sum is forwarded to the next hop. At the end of the chain, this sum amounts to the total price for the reservation queried. PAYER: The receiver-driven protocol should not allow only for receiver-payments, but should include both sender- and receiver- payments as well as a split of this payment between sender and receiver, e.g., according to a certain sender-to-receiver percentage measure. The system described in this paper uses the PAYER field to define the percentage payed by the sender and which optionally can be modified by the receiver. REQTYPE: This object is used with the semantics of distinguishing price queries for a specific reservation from the reservation message itself. BID: The pricing models used include as one of the options a pricing auction. The value of the BID field defines the actual bid, i.e. a value of 1 is equivalent to 100% of the actual market price. 7 PROVIDER: Certain payment systems implement the necessary security for transactions using provider keys. The PROVIDER field is used for storing such information. 3.2 Pricing Schemes 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 signalling 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 which 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. 4 Implementation 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: Prices based on auctions and Prices based on duration, quality, and data volume. 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 pre-defined 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 currently price charged are obtained. 4.1 Implementation Testbed 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

4 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 end-system setup is enhanced with telephony hardware connecting real handsets and a special version of the signalling software enhanced with charging functionality. It has to be noted that on these PCs does provide the necessary end-to-end signalling and charging solution, but does not implement traffic control, i.e. it does not reserve real network resources. Assuming overprovisioning in LANnetworks 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 messages [9] are routed through a gatekeeper (G). A billing server is used for off-line collection of invoice data. Finally, ingress- (I) and egress-routers (E) at ISPs are responsible for signalling and collection of accounting data. 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: Whether to make a reservation at all or Which QoS class to choose. Therefore, an additional, but optional phase has been introduced for OCIT, particularly keeping the current signalling 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, grey shaded area).the query phase is considered optional and the reservation phase mandatory PATH Message In conventional, 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. G B Caller Gatekeeper Router at ISP Billing Callee [] [] S I1 ISP 1 E1 In ISP n En R [] [] [flow id] [flow id] Messages with Charging 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] which implement fair queueing for appropriate traffic control and enhanced with charging to allow ISPs to enhance admission control with payments. 4.2 Signalling Phases Stream Billing Information [ Quote Request] [ Quote] [ PATH] [ RESV] [ Quote Request] [Billing Message] [ Quote] [ PATH] [ RESV] FIGURE 4. The Two Phases. The semantics of the PATH message for the query phase is quite similar as for a standard reservation phase. The only difference is the new REQTYPE object which is used at the receiver to reply with the correct RESV message extension concerning the calculation of the current price (cf. below) RESV Message Due to the receiver-based reservation characteristics of, 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

5 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 a price information for sender requests only. This price may change during the actual reservation in 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 standard. 4.3 A Signalling System for OCIT The implementation platform of OCIT centers around a signalling system that integrates existing standards protocols as well as new signalling protocols that are needed for charging purposes. Figure 4 shows the integration of,, and custome protocol extensions in a message sequence chart. As shown in Figure 5 the unmodified Netmeeting application is redirecting its signalling messages [9] to a gatekeeper which is usually located in the access providers network. The gatekeeper implements a fully functional proxy which allows for the analysis of all 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 signalled back to the end-systems where it is used to initiate appropriate resource reservations using the local API. Although there is a version of Netmeeting supporting native we chose to intercept messages in order to be application independent and to use our own version enhanced with charging objects on the endsystems. Note that the IP phone and the charging related processes on the end-system are completely decoupled. As depicted in Figure 5, an gatekeeper [9] with a proxy protocol stack is used to detect the flow-id of calls. On top of, charging messages signal the resource usage of each user to the ISPs. The caller and callee processes, running in parallel to the IP phone applications, use the standard API to signal resource reservations. Also integrated into the caller and callee process are charging functions which 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 API and further transported using opaque object extension in the RESV and PATH messages (cf. Section 3). 4.4 API Extensions As an extension of the Application Programming Interface (API) an approach using simple Java applets has been selected. It reflects the decoupling of signalling (session setup) and (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 Gateway at ISP Proxy Caller IP Stack Callee User Interface Caller IP Phone Process API Router at ISP User Interface Callee IP Phone Process API daemon daemon Accounting Database daemon IP Stack + Charging IP Stack + Charging IP Stack FIGURE 5. Signalling Architecture of an Off-the-shelf IP Phone Supported by -based Reservations.

6 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 proxy, these requirements are automatically translated into 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, since 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: Selection of destination address and Choice of audio quality. 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 bandwidth which 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 payed for this call and he or she explicitly has to accept or reject the call s price. For this 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 has been determined at that point in time, when the initiation has been submitted by pressing OK. 4.5 User Interfaces FIGURE 6. Selecting 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 congestionsensitive pricing schemes are applied. This price is valid for the next complete reservation period of this call, as used from. 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: Sender s DNS name, Destination s DNS name and IP address, Number of reservation periods utilized, Separate prices per reservation period, Duration of the full call in seconds, and Total price for the full call. Depending on the price models applied and the policy chosen, these information may be omitted partially. However, minimal informations are required to set up a correct bill, which encounter the destination s IP address, the duration of the call, and its total price.

7 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 5 Results and Conclusions The results of this work show that the integration of commercial applications, such as the Netmeeting IP telephony, standard protocols, such as and, and experimental protocol extensions, such as the charging extensions applied to, are possible. This is especially valid and promising for signalling 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 signalling 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 userdriven 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 signalling 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 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 signalling processes in terms of a to be defined signalling architecture integrating network layer signalling () and application layer signalling () as proposed in appendix II of the 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 on-line 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 -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 message forwarding are major topics in this field.

8 Acknowledgments 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. This work has been performed partly in the framework of the project Charging and Accounting Technology for the Internet - CATI (CAPIV /1 and MEDeB /1) which has been funded by the Swiss National Science Foundation, SNF, Berne, Switzerland. The authors like to acknowledge the discussions on relevant aspects with their CATI colleagues. References [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 () Version 1 Functional Specification; RFC 1633, Internet Engineering Task Force, Internet Engineering Task Force, September [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 [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 [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, Lisboa, Portugal, June [7] G. Fankhauser, B. Stiller, C. Vögtli, B. Plattner: Reservation-based Charging in an Integrated Services Network. 4th INFORMS Telecommunications Conference, Bocca Raton, Florida, U.S.A., March [8] ISI implementation of, URL: ftp://ftp.isi.edu/ rsvp/release/rsvpd.rel4.1a4.tar.z. [9] ITU-T Recommendation : Series H: visual and Multimedia Systems, Infrastructure of visual Services Systems and Terminal Equipment for visual Services, Packet-based Multimedia Communications Systems; February [10] J. K. MacKie-Mason, H. Varian: Pricing the Internet. Technical Report, University of Michigan, U.S.A., February [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 [12] Netmeeting, URL: [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.