A Session-Initiation-Protocol-based Middleware for Multi ... - CiteSeerX

0 downloads 0 Views 252KB Size Report
Keywords-Service coordination, Quality of Service (QoS), Session. Initiation Protocol ..... The thread-pool concept and the exclusive-access mecha- nism are ...
A Session-Initiation-Protocol-based Middleware for Multi-Application Management Teodora Guenkova-Luy, Holger Schmidt, Andreas Schorr, Franz J. Hauck

Andreas Kassler

Institute of Distributed Systems, University Ulm, Germany, {teodora.guenkova-luy, holger.schmidt, andreas.schorr, franz.hauck}@uni-ulm.de

Computer Science Department, Karlstad University, Sweden, [email protected]

Abstract—The deployment of multimedia services in nextgeneration networks is a challenge due to the high configuration complexity of the streaming process in different stationary and mobile sub-networks and for various user devices. The Session Initiation Protocol (SIP) has proven to be a suitable mechanism to handle the control of multimedia services in such networks. However, the current standardization and implementation of SIP do not allow the simultaneous coordination of multiple concurrent applications on a single device, as the prescribed realization of the SIP state machines (transactions) does not consider mutual access of applications to a single SIP stack. This paper presents a SIPbased mechanism for synchronized management of services in a shared environment. We have developed a middleware that facilitates the uniform access of multiple applications towards one or multiple SIP stacks to enable prioritization of services and centralized resource coordination of concurrent SIP applications on a single terminal or server. Keywords-Service coordination, Quality of Service (QoS), Session Initiation Protocol (SIP), Offer/Answer Model

I. INTRODUCTION Adaptive, QoS-aware multimedia systems feature several novel algorithms and mechanisms that cover single aspects of the QoS provisioning (such as adaptive play-out [1], networkresources reservation [2], service differentiation [3], multimedia content adaptation within the network [4]). Current multimedia systems that include these techniques consider for adaptation primarily the perceivable multimedia quality as it represents the most important part of the multimedia communication. However, these systems take the adaptation and the management of service-control data for granted. Yet, in distributed and mobile environments the multimedia communication cannot perform properly without having accurate global controls that involve also specific handling of the servicecontrol data and operations. Consequently, multimedia and The work described in this paper is based on results of IST FP6 Integrated Project DAIDALOS, which receives research funding from the European Community's Sixth Framework Programme. Apart from this, the European Commission has no responsibility for the content of this paper. The information in this document is provided as is and no guarantee or warranty is given that the information is fit for any particular purpose. The user thereof uses the information at its sole risk and liability. Additional support was provided by the DFG within the AKOM project.

service quality have to be considered as a combination of perceivable information and associated metadata as indicated within the MPEG-21 Digital Item Adaptation (DIA) specification [5]. However, MPEG-21 DIA is developed independently of other technologies and it provides only examples on how management metadata shall be handled for global service controls, coordination and adaptation purposes [6]. On the other hand, the Session Initiation Protocol (SIP) [7] can be seen as a candidate protocol for management of generic multimedia services, including aspects of configuration, coordination and adaptation logic. SIP was developed initially for controlling of Voice-over-IP (VoIP) applications. Recently, ongoing standardization efforts introduced a much broader scope for multimedia service-management scenarios based on SIP (e.g., the scenarios shown in [8]–[11]). As SIP was originally designed for controlling a single application only, its usage in a multi-application environment remains limited and its implementations are in general unable to manage simultaneously multiple services on a single device (i.e., user terminals, added-value SIP proxies and application servers) due to the specific prescribed realization of the SIP transactions [7]. Concurrent SIP applications have to share, however, their access to the SIP controls and signaling in order to coordinate other lower-level management mechanisms of the system like media adaptation, detection of network interfaces or resource reservations on the terminal and in the network. Regarding the MPEG-21 DIA requirements for media adaptation and considering SIP as the future protocol for global multimedia-service management, we developed a middlewarebased mechanism for facilitating the controlled and uniform access of applications to one or multiple SIP carriers, in order to achieve coordinated utilization of the SIP controls in a multi-application environment. The contribution of this paper is manifold. We discuss typical management scenarios of multimedia services in a shared environment. The design of the SIP-based middleware is presented and the system is evaluated in comparison to a classical SIP implementation to estimate the costs for utilizing SIP in a multi-application environment. We conclude with a discussion of the presented results and of potential future work.

Network and/or Service Provider

Service Client 1: REGISTER / OPTIONS

2: 200OK(REGISTER / OPTIONS)

Fig. 1. SIP methods used in service registration and discover Offerer

Answerer

1: INVITE (Offer) 2: 100 Trying 3: 183 Session Progress (Answer) 4: PRACK 5: 200OK(PRACK) Resources Reservation 6: UPDATE(Counter Offer) 7: 200OK (Counter Answer) 8: 180 Ringing 9: PRACK 10: 200OK(PRACK) 11: 200OK(INVITE) 12: ACK

Fig. 2. SIP methods used in session establishment and adaptation Action Requestor

Action Acceptor

1: REFER 3: 202 Accepted (REFER) 5: NOTIFY

2: Is REFER possible 4: Is requested action possible

6: 200 OK (NOTIFY)

Process the requested action (e.g. Offerer/Answerer call for session migration) 7: NOTIFY 8: 200 OK

Fig. 3. SIP methods used in third-party call control and session migration

II. MULTI-APPLICATION MULTIMEDIA MANAGEMENT SCENARIOS This section presents several typical service-management scenarios where the operation environment and its resources are shared between applications. A. Service Registration and Discovery The first scenario (Fig. 1) represents the registration/query procedures for services within a SIP-enabled network (see also [12]). The registration is facilitated using the SIP REGISTER transaction [7]. A REGISTER message without a message body is used to announce and record the availability of the device within the specific access network that accepts the registration. A message body carried in REGISTER can detail the capabilities of the terminal device for providing specific applications and services to other devices within the network (i.e., the capabilities registration). The OPTIONS method [7] is used by the terminals to query the network (i.e., its corresponding

location services) about available applications and services. The specific requests for service discovery and their correspondent responses are detailed in the message bodies of OPTIONS and 200 OK of OPTIONS. Requirements for multi-application management in this scenario affect the implementation of the SIP registrars and location services. At recording the device’s and its services’ availability, the registrars have to verify if the registrations are possible due to the state of the resources in the network. Consequently, the processing of the REGISTER request of one device may be postponed in favor of users having higher priority profiles (e.g., a privately used device can have a lower priority profile than a device used for business services or a device supporting automatic services like a Video-on-Demand server). Furthermore, a registration can be preempted and/or receive a negative reply if the resources for higher priority devices and applications do not allow further resource sharing (e.g., if the quality of service for actively communicating devices/services shall not be downgraded, hence, the access of other communication participants is not allowed). The service discovery with OPTIONS for querying the location services applies similar rules like those for the registrars. A location server has to control the processing of multiple OPTIONS requests according to the user profiles and their associated service/device priorities. Consequently, a mechanism for mutual exclusion at processing of REGISTER and OPTIONS methods has to be implemented in the corresponding registrars and location services of the SIP network to guarantee the application of prioritization between devices and services. B. Session Establishment and Sender-Receiver Adaptation The session establishment between terminals and the media processing at the sender and receiver affect the local resourcemanagement of the terminals and/or their resource-reservation coordination within the network. In SIP, these procedures are implemented using the Offer/Answer model [8] and its extensions for network-resource management [9] (see Fig. 2). The Offerer and the Answerer use the SIP INVITE transaction [7] to exchange information about their configurations before a network reservation takes place and they may re-configure themselves according to the results of a coordinated local- and network-reservation procedure (Fig. 2). The only difference between the procedures for session establishment and for renegotiation whenever adaptation is required is the absence of the ringing sequence in the renegotiation process (messages 8–10 in Fig. 2 are only used in session establishment). In the adaptation case, a ringing message is not necessary because the Answerer device does not need to attract its user’s attention. The multi-application management in this scenario influences the coordination of all the local applications at a single terminal and/or the calls of the terminal to external services in order to achieve a consistent view on the resources of the terminal and to avoid possible deadlocks at network-reservation coordination (see also [13]). In this case, the Offerer and An-

swerer terminals have to coordinate both the prioritization of local services and the distributed network-resource management. While the coordination of the local resources and applications at the terminal can be achieved through the means of the operating system, the management of concurrent SIP calls over the network can be done only through a configurable middleware solution that has information on the kind of SIP stacks available for the services and on the types of the services (e.g., their QoS features, resource-management requirements, etc.). Furthermore, the network-resources management for the applications can be assisted through added-value, priorities-enabled SIP proxies that listen in the Offerer and the Answerer calls and apply correspondingly QoS guidelines within the underlying network-provider architecture (see [13]). C. Third-Party Call Control and Session Migration Third-party call control and session migration between terminals are example scenarios for advanced adaptation and resource management of multimedia sessions. In these scenarios, dedicated terminals take over actions on behalf of other terminals (e.g., in a session-migration scenario a terminal that cannot cope with the QoS requirements of its peer may discover a terminal with better-suitable capabilities for its sessions and may decide to transfer its sessions to this other terminal). Similar to the Offer/Answer model (see Section II.B), the thirdparty call-control entities and their correspondent mediated entities have to apply mutual exclusion when managing concurrent services. We considered the SIP REFER method [10] for implementation of third-party call control and session migration, where the Action Requestor initializes a process that shall be controlled by the Action Acceptor (Fig. 3). In the case of session migration, the initialized process is an INVITE transaction that runs between the Action Acceptor and a terminal currently involved in a session with the Action Requestor. D. Concurrent SIP Applications without Resources Sharing Certain SIP calls for service management can be processed in parallel in case that they do not share resources (e.g., SIP transactions of QoS-aware applications and best-effort services). In such a case, the coordination middleware shall handle multiple SIP User Agents (UAs) in parallel as a single SIP UA supports per definition only a single application ([9], see the SIP transactions). However, a single SIP UA managing all the SIP-based applications is a bottleneck within the system and similar solutions should be applied only if SIP coordinates shared system resources (i.e., terminal and network resources), since the concurrent sharing of resources implies sequential processing of service requests to achieve a consistent view on the global resources and to avoid deadlocks at resources reservation (see Section III).

S tan d a rd S IP M a n a g e m e n t

C o o r d in a t e d S I P M a n a g e m e n t

A p p lic a tio n

licaaatio t ionnn lic tio AAApppppplic M id d le w a r e ti onnnMMMoooddduuulelelesss tio CCCoooooorrd dr dinininaaatio

M u lt i m e d i a M a n a g em e n t

R e so u rc e s M a n a g e m en t

M u lt i m e d i a M a n a g em e n t

R e so u rc e s M anagem ent

IP SSta t acckk SSIP

S e r v ic e M a n a g e m e n t ( S IP U A )

S e r v ic e M a n a g e m e n t ( S IP U A s )

Fig. 4. SIP management – single- and multi-application Unlocked get / resum e(OK)

signal

[timer expired] / resume(KO)

Locked get / starttimer, enqueue [queue empty] LockedWithQueued [fake]

[timer expired] / dequeue, resume(KO) get / startTim er, enqueue

signal [valid]

[high priority] / congestionInd [low priority]

[queue not empty] / dequeue, resume(OK)

Fig. 5. MUTEX for priority-based management and congestion control

III. MULTI-APPLICATION MANAGEMENT MIDDLEWARE A classical SIP service controls on its own the communication through SIP, the media management and all the other resources relevant for the application (see Fig. 4, left-hand side). Correspondingly, if a device has to support multiple SIP applications for different purposes (e.g., media streaming, instant messaging, third-party call control, etc.), these applications may collide with unpredictable results for the device when sharing playout (e.g., graphic card), transport (e.g., network access) and control resources (e.g., SIP ports). For avoiding congestions between SIP-based services, we propose the coordinated management applying a middleware (Fig. 4, right-hand side) that can be used on both terminal and provider devices, including added-value SIP proxies for coordinating network reservations and for managing the QoS guarantees on the network. The design of the multi-SIP-capable middleware is based on concepts for QoS brokers and for generalized resource management in access networks as presented in [14]. However, this paper concentrates only on the specific problems at applying SIP in multi-service environment, so that multiple applications can concurrently access one or several SIP UAs preserving consistent view on the rest of the system resources. The coordination modules within the middleware (Fig. 4) represent multiple operations concerning the control actions associated with the managed multimedia applications. The implementation of the middleware supports different servicemanagement scenarios (as described in Section II). Thus, it enables different management roles, like Offerer or Answerer,

External Action Requestor or Acceptor, etc. The coordination modules display a generalized programming interface towards the applications for realization of abstract control roles. The interface towards the carrier (in this case SIP) is protocol specific. Consequently, the middleware enables the integration of other than SIP carriers for implementing similar control roles, like demonstrated in [13] for an application of the Remote Method Invocation (RMI) and of SIP. Each control role corresponds to a specific state machine. Furthermore, the middleware contains transformation modules for the description language of the message bodies of SIP into application-specific internal representation (e.g., XML descriptions into Java objects and vice versa, see Section IV). The core of the multiapplication management in the middleware is the mutual exclusion (MUTEX) state machine (Fig. 5). The MUTEX implements a coordination strategy with dynamic priorities and time-slots for granting of SIP processing. Note that the application priorities (see [15][16]), the timeslots for accessing the SIP-based processing and the size of the MUTEX’s waiting queue for the administered tasks are based on configurable rules included in an arbitration unit of the system management middleware (e.g., a QoS broker, see also [14]). For testing the multi-application coordination, we simulated such a global system configuration and management unit, applying simplified rules for accepting/rejecting of certain tasks based on evaluation of some SIP headers and/or on test features of our tasks. Note that the evaluation of the SIP headers in the middleware is necessary for applying global QoS guarantees within the user terminals, the application servers and on the network (i.e., using value-added SIP proxies). The MUTEX provides the arbitration unit only with results about the state of the SIP processing, with information about occurred congestions and with a mechanism for resumption of tasks at failure situations. However, the decisions on how to manage the tasks at congestions are taken from the arbitration unit in the middleware, as the SIP-environment alone has no notion about the rest of the resources in the system. The scenario-specific state machines (see Section II) coordinated through the MUTEX apply the primitives get and signal to access the SIP processing (see Fig. 5). With get the state machine requests to obtain processing time for a specified period. The signal releases the MUTEX lock and, respectively, the next task locked in the MUTEX queue is released for processing. The specification of a period for seizing the MUTEX enables the MUTEX to forcibly stop misbehaving applications. Correspondingly, the tasks in the MUTEX are started/stopped explicitly, using the resume primitive, where the parameters OK or KO indicate the ability of a task to continue processing or the necessity for forcible clear-up (see below). According to the type and priority of the applications accessing the MUTEX, the MUTEX can be implicitly or explicitly booked. We consider all SIP non-INVITE transactions [7] that are not used for session establishment and/or adaptation as non-critical (e.g., service search). Correspondingly, they acquire the MUTEX implicitly. If such transactions are not successful at

obtaining of processing time, they may simply be repeated according to the requirements of the respective application. The transactions associated with resource-reservation coordination at session establishment/adaptation book the MUTEX explicitly. The booking enables such transactions to try repeatedly to get the MUTEX, before they end with a failure notification and the respective handling is returned to the application logic. Getting the MUTEX is associated with the restricted size of the MUTEX queue, with the restricted number of threads within the thread-pool of the coordination middleware and the restricted number of active tasks waiting for processing in the MUTEX queue. If there is no pending control session on the MUTEX, the MUTEX is in the state Unlocked (Fig. 5). If an application succeeds to lock the MUTEX (state Locked), its session is directly processed when there is no other equal or higher priority task actively working, otherwise the session is blocked and its task is queued (state LockedWithQueued). The MUTEX artificially increases the priority of the actively working sessions (compared with the queued sessions), in order to avoid resetting the state of the session each time a higher priority task tries to acquire the MUTEX. The actively working tasks are not stopped to avoid resource resetting, since the application of SIP and the associated resource coordination of the terminals and in the network are too expensive to allow intermediate interruptions. Correspondingly, the priorities of the sessions are valid only for the MUTEX queue to achieve the prioritybased handling. If a session cannot finish within the specified period declared at getting the MUTEX, the MUTEX indicates the application about the occurred failure. The MUTEX throws congestionInd that is mapped by the middleware to an application-specific failure indication. However, if the expired task is still in position to continue processing, it is not preempted by another task automatically. The task affected from a timerexpiry can perform a clear-up process (i.e., send signal) and return to a previous stable state or it can decide to continue (such decisions are controlled through an additional arbitration unit – see above). The MUTEX facilitates such application behavior through starting of an additional timer. If no application response is available within the period of this timer, the MUTEX clears up the task forcibly. The tasks are ordered in the MUTEX queue according to their priorities. If sessions have equal priorities, the MUTEX processes them according to a first-come-first-served strategy (corresponding to the sequence of their arrival at the MUTEX). When an active task ends, the MUTEX re-arranges the queue and ejects all the tasks with an expired timer. The MUTEX indicates the affected applications about the occurred problem with their tasks correspondingly. When the MUTEX retrieves a new task from the queue for active processing, it validates the task (i.e., the specified processing/waiting time for the task is proven). If this time is still valid the task is processed (guard condition valid – Fig. 5), otherwise a new queue re-arrangement takes place (guard condition fake). The MUTEX can be configured with different timer periods and different task-queue size (respec-

IV. COMPARATIVE MEASUREMENTS – SIP VS MIDDLEWARE The configuration information of the multimedia applications using SIP is delivered usually in the SIP message bodies. We experimented with different XML-based [17] session descriptions applying concepts of the MPEG-21 DIA specification [5], the Session Description Protocol next generation (SDPng) [18] and the End-to-End Negotiation Protocol (E2ENP) [13] (see also [4]). The processing of the SIP message bodies is integrated in our middleware in order to provide a uniform session-information management for the applications. The applied XML-message bodies for the tests have approximately 7kB file size. This size corresponds roughly to the maximal size of SIP message bodies, when no special QoS mechanism for the control signaling at the terminals is applied and the carrier protocol of SIP is UDP (see also [7]). Our experiment is based on the Offer/Answer model with simulated resource-reservation coordination (see Section II.B and [9]), since this scenario serves as a basis for multiple other session management scenarios with QoS guarantees. Our middleware and the corresponding simple SIP solution for the tests are implemented in Java (J2SE v4.2) [19] and they apply standard SIP stacks jSIP [20] and NIST SIP [21]. The test-bed for the experiment consists of two end-devices in the roles of the Offerer and the Answerer (i.e., PC1 – Intel PIII with CPU 700 MHz, RAM 256 MB and WinXP/SP 2 and PC2 – Intel PIII with CPU 1 GHz, RAM 256 MB and WinXP/SP 2) and a router that emulates network behavior (CPU AMD Athlon with 1.2 GHz, RAM 128 MB and SuSe Linux 2.4.19). TABLE I EMULATED NETWORKS

Type

Bandwidth (kbit/s)

Delay (ms)

GSM GSM-GPRS GPRS UMTS WLAN LAN

16 64 170 384 1500 100000

60 60 45 45 10 10

Network gsm

gsm-gprs

gprs

umts

wlan

lan

10000

1000

time [ms]

tively thread-pool size) according to the specific needs of the device running the middleware. For instance, the configurability of the timers allows the middleware to adjust automatically to different delay requirements of the network. The thread-pool concept and the exclusive-access mechanism are extendable for the purpose of regulated access to a shared pool of SIP UAs. The administration of multiple SIP User Agents associated with the system is achieved through the coordinated access to multiple locks which number corresponds to the number of the SIP UAs supported in parallel. Thus, QoS-aware and best-effort tasks can be processed in parallel within the system.

100

MUTEX-based-negotiation MUTEX-based-renegotiation

10

Simple-SIP-negotiation Simple-SIP-renegotiation

1

0,1 0.1

Fig. 6. Simple SIP access vs. worst-case of multi-application SIP

The emulation of network behavior considers that a DiffServ-like [3] network-internal QoS mechanism for the SIP signaling is available. Hence, only bandwidth and delay parameters are applied at the emulation. These parameters correspond to specifications of network performance and to recommendations for network measurements (see [23][24]). For the emulated networks (see Table I), it is assumed that the routers forward the control data of the applications with high priority and without loss. However, the presented results correspond to a simulation of application-to-application roundtrips, as the test software consists of some simplified modules (e.g., the middleware arbitration unit that currently substitutes a real QoS broker – see Section III) in order to achieve possibly stable results for the SIP signaling, uninfluenced from other system-management actions. The measurements (Fig. 6) are made for the case of a classical SIP application [7] (i.e., one SIP UA per application and no resource-reservation coordination) and for an example of worst case of multi-application management where many applications have to share just a single SIP UA and coordinate resource reservations. Note that the number of potential applications that may share simultaneously the SIP environment depends on the size of the predefined thread-pool in the middleware. In our measurement case, we start a dozen of threads in parallel that can manage both normal SIP transactions, but can serve also some failure-management actions done in the MUTEX (see Section III). Consequently, the middleware management and arbitration of these threads influences the speed of the application-to-application signaling. The measurements show the complete application-to-application roundtrips in the classical [7] and in the coordinated cases for a single SIP INVITE transaction with resource-reservation coordination (i.e., a procedure similar to the one defined in [9]). The presented values are average results of the measurements based on the applied jSIP [20] and NIST SIP [21] stack versions within our middleware. Measurement results indicated with negotiation correspond to session establishment with SIP and the renegotiation is the session adaptation. In both cases, of coordinated and noncoordinated SIP access, the renegotiation is quicker as the negotiation, due to the lesser number of exchanged SIP messages (see Fig. 2). The measurement shows that the price for shifting

the SIP coordination and the applications’ resource management to a middleware situated between the SIP UA and the user-services is a processing delay that can be 10 to 100 times higher than that of a classical SIP application associated with a single service. The delay occurs because the MUTEX has to coordinate multiple threads in the system corresponding to the number of the activated threads in the MUTEX thread-pool to simultaneously control SIP transactions and to provide failuremanagement at congestions of services. Additionally, the middleware synchronizes the SIP state machines with its own state machines to coordinate the SIP transaction timers and the taskactivation and -expiration timers of the MUTEX (e.g., for adjusting to different network delays or for automatically launching SIP-transaction cancellation in case of a misbehaving application). Furthermore, the middleware provides resourcereservation coordination for its applications and thus requires additional synchronization towards the user-services. It should be noted, however, that the complexity of managing the control signaling through SIP (e.g., the realization of the Offer/Answer model) and the processing costs for the QoSrelevant resource coordination are moved into the middleware and the applications on top of it do not need to take care of mutual coordination of related sessions and their resource management any longer. On the contrary, the classical SIP application is alone responsible for the specific realizations of SIP scenarios. Compared to the classical SIP application, the presented approach reduces the service-own processing as the middleware takes over the coordination of all the SIP sessions in the system no matter if they stem from the same or from different applications.

tions thus improving the performance of the middleware. ACKNOWLEDGMENT The authors of this paper would like to thank Davide Mandato for his contributions to the development of the MUTEX for priority-based SIP management. REFERENCES [1] [2] [3] [4] [5]

[6] [7] [8] [9] [10] [11] [12] [13]

V. CONCLUSIONS This paper presents a middleware-based mechanism for coordinating the access of multiple applications to global service controls with SIP. This mechanism enables users and network/service providers to apply priorities to different services and sessions and to coordinate the sharing of the operation environment between multimedia applications controlled via SIP. Furthermore, the presented middleware takes over resource-coordination tasks thus facilitating the simplification of the service implementation and of the service-own resource management. The achieved results from the simulated multiapplication management with SIP give hints on how to configure a real media-management QoS broker for accomplishing monitoring and coordination of multiple session-management events occurring in the system. Considering the acquired results, we intend to integrate our SIP-based middleware as a service-management module within a QoS broker for multimedia management. We intend to test the performance of our middleware migrating our implementation from J2SE v4.2 to J2SE v5.0 (see also [19]). Thus, we can reuse the advantages of J2SE v5.0 concurrent-programming standard solution (unavailable in J2SE v4.2) and try to improve the synchronization between our middleware and the reused SIP UA implementa-

[14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24]

M. Kalman, B. Girod, E. Steinbach, “Adaptive Playout for Real-time Media Streaming”, in Proc. of ISCAS 2002, May 2002 R. Braden et al., “Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification”, IETF RFC 2205, Sept. 1997 S. Blake et al., “An Architecture for Differentiated Services”, IETF RFC 2475, Dec. 1998 T. Guenkova-Luy et al., “Advanced Multimedia Management – Control Model and Content Adaptation”, in Proc. of EuroIMSA 2006, Feb. 2006 International Organization for Standardization and International Electrotechnical Commission, “Information Technology - Multimedia Framework (MPEG-21) – Part 7: Digital Item Adaptation”, ISO/IEC 210007:2004, 2004 C. Timmerer, H. Hellwagner, “Interoperable Adaptive Multimedia Communication”, IEEE Multimedia Magazine, Vol. 12, No.1, pp.74-79, Jan. 2005 J. Rosenberg et al., “SIP: Session Initiation Protocol”, IETF RFC 3261, June 2002 J. Rosenberg, H. Schulzrinne, “An Offer/Answer Model with SDP”, IETF RFC 3264, June 2002 G. Camarillo et al., “Integration of Resource Management and Session Initiation Protocol (SIP)”, IETF RFC 3312, Oct. 2002 R. Sparks, “The Session Initiation Protocol (SIP) Refer Method”, IETF RFC 3515, Apr. 2003 J. Rosenberg et al., “Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)”, IETF RFC 3725, Apr. 2004 H. Schmidt, T. Guenkova-Luy, F. Hauck, “Service Location using the Session Initiation Protocol”, in Proc. of ICNS'06, July 2006 T. Guenkova-Luy, A. Kassler, D. Mandato, “End-to-End Quality of Service Coordination for Mobile Multimedia Applications”, IEEE Journal on Selected Areas in Communications, Vol. 22, No. 5, pp. 889 - 903, June 2004 A. Kassler et al., “MASA - A scalable QoS Framework”, in Proc. of IMSA2003, Aug. 2003 H. Schulzrinne, “Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP)”, IETF RFC 3487, Feb. 2003 H. Schulzrinne, J. Polk, “Communications Resource Priority for the Session Initiation Protocol (SIP)”, IETF RFC 4412, Feb. 2006 World Wide Web Consortium, “Extensible Markup Language (XML) 1.0 (Third Edition)”, W3C Recommendation, Feb. 2004 D. Kutscher et al., “Session description and capability negotiation”, IETF Work-in-progress, draft-ietf-mmusic-sdpng-08, Feb. 2005 Sun Microsystems Inc., “Reference API Specifications”, http://java.sun.com/reference/api/ Sourceforge, “jSIP Home Page”, version 0.8, 2002, http://jsip.sourceforge.net/ National Institute of Standards and Technology, “NIST-SIP 1.2 -- SIP Libraries and Tools for the People!”, version 1.2, 2003, http://wwwx.antd.nist.gov/proj/iptel/src/nist-sip/jain-sip/docs/ National Institute of Standards and Technology, “NIST NET Home Page”, version 2.0.12, 2002-2005, http://snad.ncsl.nist.gov/itg/nistnet/ H. Honkasalo et al., “WCDMA and WLAN for 3G and Beyond”, IEEE Wireless Communications Magazine, Vol. 9, pp. 14 - 18, Apr. 2002 J. De Vriendt et al., “Mobile Networking Evolution: A Revolution on the Move”, IEEE Communications Magazine, Vol. 40, pp. 104 - 111, Apr. 2002