D2
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
917
On Slideshare
917
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Project Number: AC343 Project Title: MOVE Deliverable Type: (P/R/L/I)* P CEC Deliverable Number: AC343/ Siemens / WP2 / DS / P / 02 / a1 Contractual Date of Delivery to the CEC: November 1998 Actual Date of Delivery to the CEC: November 1998 Title of Deliverable: Design of V/D-API and Architecture of the VE-MASE W2D2 / D2 Workpackage contributing to the Deliverable: WP2 Nature of the Deliverable: (P/R/S/T/O)** R Author(s): Dominique Carrega, Emmanuel Fournier, Hervé Muyal (Tecsi), Michael Krautgärtner, Hendrik Decker (Siemens), Michael Wallbaum, Jens Meggers (RWTH Aachen), Casey Ong (KRDL). Abstract: This document defines the VE-MASE Architecture and the Voice/Data API (V/D-API). The first part is the functional, high level specification of the voice-enabled middleware architecture (VE-MASE). A set of VE-MASE Managers offering the voice/data services is defined. These managers are responsible for the functionality of the VE-MASE. The second part of the document includes a detailed specification of the V/D-API through which mobile voice enabled services can access the managers’ functionality of the middleware. It takes the requirements from WP1 into account. This part is an important input for WP1 in order to enable WP1 to develop the application. Keyword list: MOVE, VE-MASE, V/D-API, Services. *Type: P-public, R-restricted, L-limited, I-internal **Nature: P-Prototype, R-Report, S-Specification, R-Tool, O-Other
  • 2. HISTORY OF THIS DOCUMENT Date Version Status July 07, 1998 D2_01.DOC creation of the document. August 18 D2_02.DOC second draft September 4 D2_03.DOC third draft September 23 D2_04.DOC fourth draft October 2 D2_05.DOC fifth draft October 5 D2_06.DOC sixth draft October 7 D2_07.DOC seventh draft November 16 D2_08.DOC eighth draft November 30 D2_09.DOC ninth draft ACKNOWLEDGEMENTS The VE-MASE and Voice/Data API specification document is the outcome of an effort which started in May 98. Many people from the MOVE consortium have invested time in contributing to the VE- MASE and the V/D-API maturation in co-operative spirit. Let them and their companies (here below listed) all be acknowledged for the part they played in the set up of this specification. ◊ KENT RIDGE DIGITAL LABS ◊ ORANGE PCSL ◊ RHEINISCH WESTFALISCHE TECHNISCHE HOCHSCHULE ◊ SIEMENS AG ◊ TECSI Page 2 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 3. Table of Content 1 EXECUTIVE SUMMARY .................................................................................................................6 2 INTRODUCTION ...............................................................................................................................8 2.1 OBJECTIVES OF THE MOVE PROJECT.....................................................................................................8 PART I: THE ARCHITECTURE.........................................................................................................9 3 THE VE-MASE OVERALL ARCHITECTURE .............................................................................9 3.1 PHYSICAL VIEW...................................................................................................................................9 3.1.1 The Mobile Client (MC).........................................................................................................11 3.1.2 The Mobility Gateway (MG)..................................................................................................11 3.1.3 The Information Server (IS)....................................................................................................11 3.1.4 The Voice/Data Application Server (V/D-AS)........................................................................11 3.1.5 The Voice/Data Application Client (V/D-AC)........................................................................11 3.2 FUNCTIONAL VIEW.............................................................................................................................12 4 AUDIO GATEWAY ..........................................................................................................................14 4.1 FUNCTIONAL SPECIFICATION.................................................................................................................15 4.1.1 The Gateway Architecture......................................................................................................16 4.1.1.1 Media and Channel Selection............................................................................................16 4.1.1.2 Transcoding and Codecs....................................................................................................17 4.1.1.3 Mixing................................................................................................................................17 4.1.1.4 Application Level Framing................................................................................................17 4.1.1.5 Network Adaptation...........................................................................................................17 4.1.2 The Gateway Client................................................................................................................18 4.1.3 Signalling Issues.....................................................................................................................18 4.1.3.1 End-to-End Signalling Using H.323..................................................................................18 4.1.3.2 Lightweight Signalling For The Wireless Network...........................................................20 4.1.3.3 Discussion of the Signalling..............................................................................................21 4.2 EXTERNAL INTERFACES.......................................................................................................................21 4.3 INTERNAL INTERFACES........................................................................................................................21 5 SCHEDULER......................................................................................................................................23 5.1 FUNCTIONAL SPECIFICATION.................................................................................................................24 5.1.1 The VE-MASE Scheduler........................................................................................................25 5.1.1.1 Service classes...................................................................................................................25 5.1.1.2 QoS parameters..................................................................................................................25 5.2 EXTERNAL INTERFACES.......................................................................................................................25 5.3 INTERNAL INTERFACES........................................................................................................................26 6 CALL MANAGER............................................................................................................................27 6.1 FUNCTIONAL SPECIFICATION (SERVICES)................................................................................................27 6.1.1 Requirements..........................................................................................................................27 6.1.2 Presumption............................................................................................................................28 6.1.3 Call Manager in VE-MASE Distributed Architecture ...........................................................28 6.1.4 Implementation of Call Manager and Call Manager Proxy..................................................29 6.1.5 Operation................................................................................................................................31 6.1.6 Session Termination...............................................................................................................32 6.2 EXTERNAL INTERFACES........................................................................................................................33 AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 3 AC343 / Sie / WP2 / R / P / 02 / a1
  • 4. 6.3 INTERNAL INTERFACES.........................................................................................................................33 7 COLLABORATION MANAGER ...................................................................................................34 7.1 FUNCTIONAL SPECIFICATION (SERVICES)................................................................................................34 7.1.1 HTTP dispatching...................................................................................................................34 7.1.2 Notification.............................................................................................................................35 7.1.3 Two implementation options...................................................................................................35 7.2 A PLUG-IN APPROACH TO DECENTRALISED COLLABORATION MANAGEMENT...................................................36 7.2.1 Message sequence chart for decentralised collaboration management ................................38 7.3 A CENTRALISED APPROACH...................................................................................................................40 7.3.1 Message sequence chart for centralised collaboration management....................................40 7.3.2 Architecture of a centralised Collaboration Manager...........................................................42 7.4 INTERNAL INTERFACES ....................................................................................................................47 7.5 EXTERNAL INTERFACES....................................................................................................................47 8 SYSTEM ADAPTABILITY MANAGER (SAM) ...........................................................................48 8.1 FUNCTIONAL SPECIFICATION.................................................................................................................48 8.2 QOS CLASSIFICATION.........................................................................................................................49 8.3 EVENTS ............................................................................................................................................51 8.3.1 Network events........................................................................................................................52 8.3.2 Transport events.....................................................................................................................53 8.3.3 Session events.........................................................................................................................53 8.3.4 Application events..................................................................................................................53 8.4 SAM ARCHITECTURE.........................................................................................................................54 8.5 EXTERNAL INTERFACES.......................................................................................................................55 8.6 INTERNAL INTERFACES........................................................................................................................55 9 ONTHEMOVE MANAGERS...........................................................................................................56 PART II: THE API...............................................................................................................................57 10 OVERVIEW OF THE V/D-API......................................................................................................57 10.1 GENERAL CONCEPTS.........................................................................................................................57 10.2 FUNCTIONAL DECOMPOSITION OF THE V/D-API..................................................................................57 10.3 DISTRIBUTION OF THE V/D API........................................................................................................57 10.4 NOTATIONS AND CONVENTIONS..........................................................................................................57 10.5 SUMMARY OF THE METHODS...............................................................................................................59 11 AUDIO GATEWAY API ................................................................................................................62 11.1 OVERVIEW OF THE API....................................................................................................................62 11.2 SPECIFICATION OF THE API...............................................................................................................62 11.2.1 Textual Definition.................................................................................................................62 11.2.2 State Tables..........................................................................................................................63 11.2.3 IDL Definition......................................................................................................................64 12 SCHEDULER API............................................................................................................................65 12.1 OVERVIEW OF THE API....................................................................................................................65 12.2 SPECIFICATION OF THE API...............................................................................................................65 12.2.1 Textual Definition.................................................................................................................65 12.2.2 State Tables..........................................................................................................................65 12.2.3 IDL Definition......................................................................................................................66 13 CALL MANAGER API...................................................................................................................67 Page 4 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 5. 13.1 OVERVIEW OF THE API (EXTERNAL INTERFACES).................................................................................67 13.2 SPECIFICATION OF THE API (EXTERNAL INTERFACES)...........................................................................68 13.3 OVERVIEW OF THE API (INTERNAL INTERFACES).................................................................................80 13.4 SPECIFICATION OF THE API ..............................................................................................................82 13.4.1 Use of VE-MASE classes by the Call Manager....................................................................83 14 COLLABORATION MANAGER API..........................................................................................84 14.1 OVERVIEW OF THE API....................................................................................................................84 14.2 SPECIFICATION OF THE API...............................................................................................................84 14.2.1 API for the Call Manager Proxy..........................................................................................84 14.2.2 API for the Collaboration Manager.....................................................................................84 14.2.3 API for driving the collaboration Manager.........................................................................85 15 SYSTEM ADAPTABILITY MANAGER (SAM) API..................................................................87 15.1 OVERVIEW OF THE API....................................................................................................................87 15.2 SPECIFICATION OF THE API...............................................................................................................87 16 HOW TO USE THE V/D API FOR VOICE/DATA INTEGRATION SERVICES...................89 16.1 PRINCIPLES OF USING VOICE/DATA INTEGRATION FOR EXTENDED SERVICES..................................................89 16.2 A GENERIC PROCESS SCENARIO FOR USING EXTENDED VOICE/DATA SERVICES..............................................89 16.3 A POSSIBLE TECHNIQUE TO USE THE VOICE/DATA API .........................................................................92 17 REFERENCES..................................................................................................................................94 18 ABBREVIATIONS...........................................................................................................................96 AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 5 AC343 / Sie / WP2 / R / P / 02 / a1
  • 6. 1 EXECUTIVE SUMMARY The Deliverable D2 ‘Design of V/D-API and Architecture of the VE-MASE’, prepared by Workpackage 2 (Voice Enabled Multimedia Application Support Environment, VE-MASE), describes the architecture of the VE-MASE (Part I) and the Voice/Data Application Programming Interface (V/D-API) (Part II) for integrated voice and data services. The external V/D-API is specified explicitly whereas the internal APIs between different functional entities of the VE-MASE are described informally. The design including an explicit specification of internal interfaces and the description of their implementation will be given in the Deliverable D5 ‘Design and Implementation of the VE- MASE Prototype’. The supported voice/data services use the V/D-API and its underlying functionality as offered by the VE-MASE. The V/D-API allows application programs to start voice and data connections and service providers to offer voice enabled mobile services. The Deliverable D2 serves as a basis for the development of the mobile multimedia demonstration service (Workpackage 1, Demonstration Service) which demonstrates the feasibility and market potential of integrated voice and data services. Furthermore, the Deliverable D2 makes use of the Mobile-API developed by the ACTS project 034 OnTheMove [OTM]. The V/D-API allows applications to signal their quality of service requirements to employed computing and communication subsystems. Application programs are enabled to use voice and data connections without the necessity to explicitly select the underlying transport mechanism. Mobile devices need a mobility gateway that provides an intelligent gateway to the wired infrastructure. By means of a user-supplied profile, the mobility gateway acts as a proxy agent for mobile devices, which cannot always be fully connected, to a network. The mobility gateway knows about the current quality of available wireless links and intelligently schedules communication with the mobile device based on user-supplied profiles. The MOVE project has investigated network requirements in terms of quality of service limitations of voice over packet-switched networks like the Internet and over different mobile networks, for example Wireless LANs and GSM. Within the scope of the MOVE project, the actual prototype will only be implemented for voice services running on top of data services. The VE-MASE architecture supports integrated voice and data applications. The VE-MASE adapts to the specific transport capabilities of the underlying networks and supplies a set of mobility, voice, and data related management functions: • The Mobility Gateway (MG) approach supports Voice over IP (VoIP) over mobile networks. Examples for its functionality are the harmonisation of new voice sessions and ongoing data sessions as well as bandwidth adaptation on the narrowband wireless link. • The Audio Gateway on the Mobility Gateway provides for real-time audio conferencing between peers in a wireless access network and peers located in a fixed network environment. • The Audio Gateway Client is an application for VoIP running on the Mobile Client, e.g., a notebook or a PDA. • The Scheduler ensures that real-time streams (e.g., audio) are not delayed by non real-time data (e.g., collaborative web browsing). Incoming packets are classified according to their service class. Quality of Service (QoS) parameters are measured for each stream and signalled to the System Adaptability Manager (SAM). Page 6 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 7. • The Call Manager is part of the distributed VE-MASE architecture and is responsible for the set-up and the termination of a voice/data conference between a mobile client and another client with voice/data capability. It controls the audio session (i.e., VoIP) and the collaborative web browsing session. The call set-up is based on an existing IP connection; either a call is placed from the client terminal or call set-up information is delivered to the proxy gateway where the connection is set up to a Voice over IP based terminal, e.g., a call-centre. Depending on real- time changes of QoS parameters, the voice/data conference is possibly terminated or only the audio session is terminated. The corresponding V/D-API enhances Sun’s Java-based telephony API JTAPI [JTAPI]. • The Collaboration Manager on the Mobility Gateway enables the members of a conference to exchange HTML pages and to perform collaborative web browsing. Thus, a kind of push mechanism for the forced download of an HTML page in a browser is proposed (HTTP dispatch). A notification informs the Collaboration Manager that the corresponding member (e.g., Mobile Client) has received the HTML page. A notification is sent to all members of the conference after successful completion of the download. • The MOVE extension of the System Adaptability Manager (SAM) collects events and measurements from the Audio Gateway, the Scheduler, and in principle also from the Collaboration Manager and the HTTP proxy. The quality of service (QoS) parameters are analysed in real-time for real-time audio and non real-time data and the result (e.g., QoS class cannot be guaranteed) is delivered to the Call Manager. The function of the SAM extension is to perform QoS trading for the complete transmission medium (e.g., voice and data), i.e. by co- ordinating per-stream QoS trading. • The Profile Management (OnTheMove) will give the service provider access to user-specific context information (e.g., to a history of HTML downloads preceding a particular information access). • Multi-sensitivity adaptations (OnTheMove): A Location Manager will support applications handling location-dependent information and a System Adaptability Manager (SAM) will provide information about device capabilities, user preferences and/or network capabilities. AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 7 AC343 / Sie / WP2 / R / P / 02 / a1
  • 8. 2 INTRODUCTION This Deliverable provides a high level specification of the architecture of the VE-MASE and the V/ D-API. This document will be used by WP1 to design and implement the Demonstration Service. The MOVE project will investigate, develop and demonstrate the integration of voice and data services into a middleware for mobile multimedia applications. MOVE will integrate mobile technologies and voice services into the European approach for „information superhighways“. Proper support and adaptations must be given to people who are on the move and need information using mobile network access to their voice/data services. 2.1 Objectives of the MOVE Project The overall objective of the MOVE project is: To define and prototype a voice-enabled mobile middleware architecture that integrates voice and data services for small user terminals and to derive a common interface for voice-enabled mobility support as an enhancement of today’s networks and part of the UMTS service. The main project objectives are consequently derived from this overall objective: • To design an architecture that supports strong integration of voice and data over UMTS for interactive mobile multimedia services and applications. • To evaluate emerging mobile multimedia protocols integrating voice and data communication and architectural approaches well suited for interactive wireless multimedia communication. • To offer an open voice enabled application programming interface (Voice/Data V/D-API) to content and service providers for rapid and flexible deployment and operation of voice/data services, supporting on-line user contextual assistance. • To specify and prototype a demonstration service that demonstrates the benefits of the V/D-API. • To define a demonstration on advanced personal digital assistants or laptops to demonstrate the V/D-API and middleware architecture, and to show the value of the approach for service providers. • To promote the adoption of the V/D-API by the computer industry, application and service developers, and standardisation bodies. • To increase commercial and public interest for mobile multimedia information services through publications and demonstrations. By achieving these objectives, MOVE will accelerate the use of voice enabled multimedia information services and assist the development of new applications and network embedded mobility support. Page 8 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 9. PART I: THE ARCHITECTURE 3 THE VE-MASE OVERALL ARCHITECTURE 3.1 Physical View The following diagram panoramically shows the physical architecture of the MOVE demonstrator. Some hardware components could, of course, be merged on the same machine, but, as they are functionally independent, they will be designed so that they can be distributed on separate computers. Figure 3.1: VE-MASE Hardware architecture Mobility Gateway (MG) Information Server (IS) Mobile Client (MC) Voice/Data Application Client (V/D-AC) Voice/Data Application Server (V/D-AS) Voice/Data Application Client (V/D-AC) AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 9 AC343 / Sie / WP2 / R / P / 02 / a1
  • 10. The following figure shows the software architecture of the MOVE architecture. Mobility Gateway (MG) Information Server (V/D AS) Mobile Client (MC) with HTTP Server V/D API V/D API Voice Over IP V/D Scheduler MASE Client Audio Gateway Web Site System Call Manager Adaptability Manager MASE Gateway Collaboration Manager Call Mgr Proxy Voice/Data Application Client (V/D AC) Voice/Data Application Server (V/D AS) V/D API Voice/Data Application Client (V/D AC) Call Manager Voice Over IP Figure 3.2: VE-MASE Software architecture Page 10 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 11. 3.1.1 The Mobile Client (MC) The mobile client (MC) is used by a mobile user to access the voice/data services. It should be a thin client, compliant with all the mobility constraints. This computer is equipped with a wireless LAN PCMCIA card, or alternatively with a GSM card and a compatible modem. It is also equipped with a sound card, a microphone, and a speaker. It accesses the Mobility Gateway (MG) either through a wireless LAN or the GSM connection. It is configured so that the MG is a proxy for all accesses to the IS or the V/D-AS. A standard recent HTTP client is installed, allowing to browse the demonstration web site on the IS. This HTTP client should be Java 1.1 compliant, support JavaScript and Dynamic HTML. The VE-MASE components Call Manager and Audio Gateway VoIP client are installed on the Mobile Client. In addition, the Location Manager (OnTheMove MASE component) informs about the current location by its Mobile-API. 3.1.2 The Mobility Gateway (MG) The Mobility Gateway is the entry point to the fixed network for the Mobile Clients. It is equipped with a modem driven by the Remote Access Service, allowing a Mobile Client to connect to the system through a GSM connection or by access via a wireless LAN base station. The VE-MASE components Audio Gateway, Scheduler, Call Manager Proxy, Collaboration Manager, and components of the MASE from the ACTS project AC 034 OnTheMove (HTTP Proxy, profile manager, event services, user management, directory services) are installed. The VE-MASE components support the mobile user offering Voice over IP, scheduling of voice (real-time) and data (e.g., HTTP), conference call set- up for common voice/data sessions, and collaborative web browsing. 3.1.3 The Information Server (IS) The Information Server hosts the Web site including an HTTP server. It is linked with the MG through a wired network. 3.1.4 The Voice/Data Application Server (V/D-AS) The Voice/Data Application Server (V/D-AS) serves all the Voice/Data Application Clients (V/D- AC) and is the only entry point into the call centre. It is linked with the MG through the wired network. The VE-MASE components, the Call Manager and the System Adaptability Manager, are installed. The Collaboration Manager on the Mobility Gateway can be accessed using a specified API (i.e., a protocol for driving the Collaboration Manager). 3.1.5 The Voice/Data Application Client (V/D-AC) The Voice/Data Application Clients (V/D-AC) are clients that will be able to interact with the MC using voice and data. A VoIP client and a standard recent HTTP client are installed, allowing to browse the demonstration web site on the IS. This HTTP client should be Java 1.1 compliant, support JavaScript and Dynamic HTML. AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 11 AC343 / Sie / WP2 / R / P / 02 / a1
  • 12. 3.2 Functional View Application Mobile Location-aware Call Centre World Wide Internet Services Services Web Telephony Mobile Application Programming Interface Voice/Data API VE-MASE Components MASE Components (OnTheMove) Collaboration Session Manager Adaptability Profile Location Multimedia • HTTP Dispatcher Manager Conversion Multimedia Manager Manager • Notification • V/D QoS Trading (HTTP Conversion • Collaborative Proxy) (HTTP proxy) Browsing Audio Alerting Call Gateway User Manager Directory Event • Mixing/Forwarding Manage- • Conference Services Manager • Transcoding ment Control for Voice & Data UAL Scheduler wireless networks IMT 2000 Wireless GSM UMTS LAN Figure 3.3: The VE-MASE Software Architecture and MASE components Multimedia Page 12 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 Conversion AC343 / Sie / WP2 / R / P / 02 / a1 (HTTP proxy)
  • 13. The VE-MASE components Audio Gateway, Scheduler, Call Manager, Collaboration Manager and System Adaptability Manager are discussed in detail in the subsequent chapters. The OnTheMove components are listed as MASE (Mobile Application Support Environment) components. These components are the relevant parts of the MASE managers (cf. chapter 9). AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 13 AC343 / Sie / WP2 / R / P / 02 / a1
  • 14. 4 AUDIO GATEWAY The Audio Gateway is a central component of the VE-MASE since it provides for real-time audio conferencing between peers in a wireless access network and peers located in the fixed network environment. Connected by one or more wireless access networks like GSM, DECT or Wireless LAN, mobile clients receive a possibly adapted Voice over IP (VoIP) stream from the associated Audio Gateway, which is located at the border between the wireless access network and the fixed network environment. Likewise the Audio Gateway forwards audio data from the mobile to the stationary client. This service, which primarily differentiates the VE-MASE from its predecessor MASE, provides the basis for a number of new interactive mobile services and applications, such as the call centre access that will be prototyped and investigated by the MOVE project. The Audio Gateway and its client address the following VE-MASE requirements as stated in the D1 document [CFM98]: • Requirement MOVE/R/1: The VE-MASE shall support voice conversations between two users over low bandwidth networks. • Requirement MOVE/R/2: The VE-MASE shall be ready for UMTS environment services. • Requirement MOVE/R/3: The VE-MASE shall support voice conferencing functionality. • Requirement MOVE/R/4: The VE-MASE shall provide the ability to end the conversation from both ends. • Requirement MOVE/R/6: The VE-MASE shall inform the application layer when a voice conversation ends. • Requirement MOVE/R/7: The VE-MASE shall provide the MC with the ability to request a voice conversation with some appropriate agent. • Requirement MOVE/R/9: The client part of the VE-MASE software should be as thin as possible to be in accordance with mobility constraints. To meet these requirements, the Audio Gateway acts as a mediator between the participants in the fixed and wireless networks. Instead of just routing the media streams from one side of the gateway to the other by network layer protocols, the gateway intercepts the data streams on the application level. There it can manipulate the streams by means of intelligent operations such as transcoding, mixing, congestion control, etc. In principle, this scheme makes the Audio Gateway the endpoint of communication for the transport level entities of both parties engaged in a conference. Figure 4.1 shows a simple conference scenario with a stationary and a mobile terminal. Page 14 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 15. S ta tio n a r y T e r m in a l In te rn e t M o b ile T e r m in a l M o b ilit y G a t e w a y Figure 4.1: Simple Audio Gateway Scenario The Audio Gateway is closely modelled on the Video Gateway that was implemented as part of the OnTheMove project [MSP97] [Kre+98]. Like the Video Gateway it is located at the border to the access network and performs operations such as forwarding and transcoding of media streams on the application level. But the Audio Gateway differs from the Video Gateway in three important aspects: • In order to support interactive voice services such as those provided by the PSTN the Audio Gateway enables bi-directional, full-duplex transport of audio data. • The Audio Gateway needs to consider the very strict delay and jitter requirements of interactive audio conferencing. • The Audio Gateway is tightly integrated in the VE-MASE architecture, thus allowing integrated, adaptive transport and scheduling of voice and data packets. Nevertheless, the conceptual similarities of the Audio and Video Gateways could ease a potential integration of these components in the future. The following section describes the Audio Gateway’s architecture. 4.1 Functional Specification The components of the VE-MASE mainly responsible for audio conferencing are the Audio Gateway and the Audio Gateway Client. The former is part of the Mobility Gateway residing at the border between the fixed network and the wireless access network. The latter is an application running on the mobile terminal, e.g. a notebook or a PDA. The client may as well be connected by means of the fixed network. Regarding the call centre scenario, the call centre operators may use the same client as the mobile user. AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 15 AC343 / Sie / WP2 / R / P / 02 / a1
  • 16. To achieve wide acceptance within the user community and in order to allow for simple implementation by reuse of existing code, the Audio Gateway supports standard protocols. No assumptions are made concerning the client software used by the peer in the fixed network, except that it follows the principles of VoIP, i.e. it must use the RTP [Sch96a] protocol to transport frames of encoded speech data over an IP-network. Furthermore it must employ a voice codec which is available to the Audio Gateway. Most currently available conferencing tools meet these constraints. 4.1.1 The Gateway Architecture As the Audio Gateway acts as the endpoint of communication on the transport level for all parties taking part in the conference, its main task is to receive an audio stream from a sender and forward it to a receiver. The transport address of the actual receiver of a stream is conveyed to the gateway at session initiation time. The Audio Gateway follows a layered architecture as shown in Figure 4.2. According to the prevailing quality of Channel Selector service (QoS) parameters, a channel selector determines which of the incoming media streams can be delivered to the output. If necessary, the next layer transcodes the data Transcoder streams of the selected channels into a different format. The mixer merges the different channels to form a single audio stream, which is passed to the application framing entity. It QoS subdivides the bit stream into application frames that allow Mixer limiting the amount of loss occurring during transmission. Furthermore, the network adaptation layer is responsible for adapting the bit stream to the form most suitable for Application Framing transmission over the given network. The focus in the discussion of the gateway architecture is Network Adaptation on the downlink (in the direction to the mobile client), where channel selection and mixing are beneficial. For the uplink it is assumed that a mobile client will only generate one media stream, which will simply be forwarded to the Figure 4.2: client in the fixed network after potential transcoding. Layered Gateway Architecture 4.1.1.1Media and Channel Selection The Media and Channel Selector is used in conjunction with the Video Gateway and plays a vital role in scenarios involving changing network conditions, e.g. caused by roaming, and in scenarios where the mobile user cannot influence the sender’s output. The Media and Channel Selector obtains the current network configuration from the QoS Module, which comprises a characterisation of the input streams and the QoS characteristics of the currently employed wireless access network. The former includes the number of video and audio channels and a description of each incoming bit stream, Page 16 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 17. stating, e.g., bit rate and frames per second. According to the network conditions the selector will choose channel and media from the input stream and, if possible, configure available transcoders. 4.1.1.2Transcoding and Codecs The employed audio codecs dictate most of the QoS requirements. For example, a simple H.323 compliant conferencing system produces a stream of G.711 coded frames with a bit rate of 64 kbit/s. The Audio Gateway can transcode this audio stream, e.g. to G.723.1 [Cox97]. The latter is a newer format which allows to reduce the needed bandwidth to a bit rate below 5.6 kbit/s. A major drawback of this scheme is the additional delay introduced by transcoding which, in fact, requires decoding and encoding each frame. Though transcoding should be avoided in highly interactive conferences, it is a legitimate technique to enable mobile users to receive media streams, which do not require their interaction. Examples of this include lectures and conferences broadcast on the Internet or even the reception of radio programmes streamed to the Audio Gateway via RealAudio. 4.1.1.3Mixing So far it was assumed that a conference consists of two participants − one in the fixed network and one in the wireless access network. But it also conceivable to have more than two parties involved. If the media streams are not distributed by a multicast transport mechanism but by unicast, then the receivers will have one input stream from each sender. To meet the constraints of the narrowband wireless link, an application level relay called a mixer [Sch96a] is included in the Audio Gateway. The mixer resynchronises incoming audio frames to reconstruct the constant spacing between them and combines these reconstructed audio streams into a single stream. This scheme saves valuable bandwidth since the mixer’s single output stream contains the audio information of all input streams, e.g. mixing together three G.723.1 streams into one G.723.1 stream reduces the amount of required bandwidth from 15.9 kbits/sec to 5.3 kbits/sec. A drawback of mixers is that receivers cannot control the playback of individual senders, i.e. they cannot mute or adjust the volume of a specific sender’s data, which is contained in the mixed stream. 4.1.1.4Application Level Framing Application level framing [CT90] is closely related to the coding scheme. If knowledge about the syntax of the coder output is available, the bit stream may be segmented into frames at the application layer. The newly created segments form the smallest loss unit that can be encountered at the application layer. This is the basis for graceful degradation in case of transmission errors or losses. Because of the semantic knowledge of the bit stream, the error characteristics of the wireless network can be taken into account. 4.1.1.5Network Adaptation At this level, full knowledge of the semantic structure of the bit-/frame-stream should be available and may be exploited to enhance the loss or error properties: Possible methods include protection of vital information, commonly known as unequal error protection, by retransmission or forward error correction (FEC) codes. One form of forward error correction, that plays a role in VoIP, is the redundant encoding of audio data [Per+97]. Whilst FEC schemes are often overly complex and AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 17 AC343 / Sie / WP2 / R / P / 02 / a1
  • 18. constantly require additional bandwidth, ARQ (automatic repeat request) schemes add additional delay. The choice of application controlled ARQ schemes nonetheless has its benefits. The application can decide if and when a retransmission is necessary. If only non-vital information is corrupted, the application can decide to use other methods to conceal the error. By separating the error and loss protection from the network/transport layer and moving it to the application layer, content-based corruption handling becomes possible. This is in strong contrast to current transport protocols where all packets are handled the same way. The application only defines the guidelines and policies, while the application layer handles the rest to relieve the application and to provide a predictable behaviour. 4.1.2 The Gateway Client The generic Audio Gateway architecture provides for a variety of possible realisations and configurations. Most importantly, the split between the wireless and the wireline network on the levels of transport and signalling makes it possible to employ different client software on both sites. This is especially useful, since both sites have different requirements: • On the mobile client site efficient use of bandwidth is of utmost importance. Furthermore, an Audio Gateway client should have minimal storage and CPU resource requirements to meet the restrictions of today’s mobile terminals such as notebooks and PDA’s. • On the stationary client site it is meaningful to employ legacy applications. The usage of legacy applications enables communication with hosts, which are not integrated into the VE-MASE architecture, thus raising the users’ and providers’ acceptance of the VE-MASE middleware and its applications. Since RTP/RTCP is a widely acknowledged standard for the efficient real time transport of audio and video data, differences are mainly reflected on the level of signalling. This issue will be discussed in the following section. 4.1.3 Signalling Issues The ITU standard H.323 is the common standard for Internet telephony and is widespread among client applications like Netscape’s conference tool and Microsoft’s Netmeeting. The following discussion of the benefits of H.323 is limited to the signalling for Voice over IP (H.245, Q.931) and does not include the full conferencing protocol T.120 for data exchange. Thus, the minimal goal of the MOVE project is to enable fixed network users to start Voice over IP sessions using their standard software. A further step is the integration of H.323 signalling also for mobile users. Several possibilities are discussed subsequently. 4.1.3.1End-to-End Signalling Using H.323 H.323 signalling for call control of the audio part from the mobile client via the mobility gateway to the V/D application client is one possible way to perform call control. Standard Internet Telephony software can be used on the mobile client. Interception of audio at the mobility gateway for voice/data scheduling is needed for the functionality of the Audio Gateway Automatic call distribution a the V/D Page 18 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 19. Application Server in the context of H.323 usage and the new ITU standard H.450 is beyond the scope of the MOVE project. SIP for conference setup MC MG H.323 for call control H.323 for call control SIP for conference setup V/D AS Figure 4.3: Full H.323 Based Signalling for Wireless and Fixed Network Another solution is to employ an enhanced H.323 gatekeeper (cf. ITU H.323 version2 [ITU2]) at the Mobility Gateway. In this case, the Audio Gateway would be part of the gatekeeper. The gatekeeper, which is an optional component in an H.323 system, provides call control services to the H.323 endpoints. This entails address translation, admission control, bandwidth control, and zone management. Other optional functions are call authorisation, bandwidth management, call management, and call control signalling. For the interesting call control signalling mode, the gatekeeper may choose to complete the call signalling with the endpoints and may process the call signalling (Q.931) itself. The gatekeeper uses the ability to route H.323 calls, which can also be used to re-route a call to another endpoint. Extending the call signalling capabilities beyond the standard is important if transcoding of the audio data on the Audio Gateway is necessary, e.g. due to different voice codecs on the two endpoints. Thus, a H.245 capability exchange has to be conducted. Using the Gatekeeper routed call signalling the H.245 Control Channel can be routed between the endpoints through the Gatekeeper. AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 19 AC343 / Sie / WP2 / R / P / 02 / a1
  • 20. Gatekeeper Cloud 1 ARQ 2 ACF/ARJ 3 Setup 4 Setup 10 1 2 3 8 9 4 5 6 7 5 ARQ 6 ACF/ARJ 7 Connect 8 Connect 9 H.245 Channel Endpoint 1 Endpoint 2 10 H.245 Channel H.245 Control Channel Messages T1521310-96 Call Signalling Channel Messages RAS Channel Messages Figure 4.4: Gatekeeper Routed H.245 Control 4.1.3.2Lightweight Signalling For The Wireless Network In this scenario the mobility gateway acts as the termination point of the H.323 signalling for the fixed network H.323 compliant VoIP client. The VoIP client in the wireless network employs a lightweight signalling protocol (e.g., audio conference with minimal control [Sch96b]) for call control. This scheme provides for small mobile devices with restricted storage and CPU capacities, since the Audio Gateway Client does not have to entail a full H.323 stack. Furthermore, it makes more efficient use of the access network’s limited bandwidth than H.323, since the signalling overhead is kept to a minimum [Sch98]. For integrated conference control, i.e. target localisation, capability exchange, etc., the lightweight SIP protocol [HSSR98] can be deployed. It can signal the request for a combined data and voice over IP session from the V/D Application Client or the mobile client to the mobility gateway including the IP address of the mobile user to be called. Page 20 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 21. SIP for conference setup MC MG audio conference with minimal control H.323 for call control SIP for conference setup V/D AS Figure 4.5: H.323 Signalling For Fixed Network Site Only 4.1.3.3Discussion of the Signalling The lightweight signalling solution does allow transcoding at the Mobility Gateway as the Mobility Gateway is the endpoint of the H.323 signalling. The capabilities of this endpoint are set during call set-up with a fixed network H.323 client. For very lightweight mobile clients and narrowband networks, the audio conference with minimal control minimises the time for call set-up. Nevertheless, in the H.323 version 2 a fast call set-up mode was introduced. In the case of end-to-end H.323 signalling for VoIP, a gatekeeper has to be enhanced for the interworking with the Audio Gateway functionality. In a minimal scenario where the Audio Gateway was only forwarding audio data and no transcoding takes place, the Audio Gateway would be not necessary and only the Scheduler would be used for transparent scheduling. 4.2 External Interfaces None. 4.3 Internal Interfaces The VE-MASE located on the Mobility Gateway provides several functions that are needed by the Audio Gateway implementation. These functions and the corresponding APIs ease the development and installation of the Audio Gateway. The following architectural components are accessed by the gateway’s core component which itself is a part of the Communication Manager. AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 21 AC343 / Sie / WP2 / R / P / 02 / a1
  • 22. • UAL – UMTS Adaptation Layer (OnTheMove) The UAL offers a uniform API to transport services provided by different access networks and bearer services. The API allows querying of complex QoS parameters and status information indicating the actual prevailing conditions of the installed access networks. The UAL is needed to allow a simplified transport access and to get QoS parameters needed for the calculation of e.g. filtering functions and transcoders. • SAM – System Adaptability Manager The SAM provides means for multimedia conversion functions, like audio transcoders. Transcoders may be deployed, maintained and updated within the SAM. This would enable other VE-MASE and application components to access transcoder services through the SAM API. The MOVE extension of the SAM performs QoS trading for the complete transmission medium (e.g., voice and data), i.e. by co-ordinating per-stream QoS trading. • Communication Manager The Communication Manager provides a framework, which allows deploying application level protocols, like HTTP, FTP or SMTP. The core Audio Gateway implementation resides in the Communication Manager. • Call Manager The Call Manager Proxy allocates Audio Gateway resources for a VoIP channel, connecting a sender and a receiver. Page 22 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 23. 5 SCHEDULER Mobile users demand different kinds of data to be serviced, which are generated by interactive and non-interactive forms of audio, video and data applications. These applications require different qualities of service from the communication network. For example, interactive audio and video applications such as Microsoft Netmeeting, VIC, VAT etc. are more sensitive to delay and jitter than playback video applications, whereas file transfer requires reliable delivery. Because the transmission of most multimedia information has constraints in terms of throughput and delay real time transmission is needed. On the network level, the Internet is connectionless and offers only best effort service. Two different service architectures are currently being discussed to enhance the Internet by QoS support. The Integrated Service model [Wro97] allows senders and receivers to exchange signalling messages which establish classification and forwarding state in each node along the path between them. The Differentiated Service Architecture [Ber98] is based on a simple model where traffic entering a network is classified and shaped at the boundaries of a network. Since the Internet currently does not support QoS on an end-to-end basis, the MOVE project’s middleware architecture requires a component that offers different service classes for the last hop on the narrowband wireless link. This VE-MASE component, called Scheduler, ensures that real time data is not delayed by the transmission of non real time data. Specifically, in the context of the demonstrator scenario [Ca98], it ensures that simultaneous exchange of audio and web data is possible without degrading the quality of the ongoing audio conference. The Scheduler addresses the following requirements as stated in the D1 document: • Requirement MOVE/R/10: The VE-MASE shall provide a MC with the ability to transfer multimedia data to another MC in the context of a voice conversation between two users, without disturbing the voice conversation. • Requirement MOVE/R/11: The VE-MASE shall predict the time needed to transfer data. • Requirement MOVE/R/12: The VE-MASE shall be able to inform the application layer that the data has not yet arrived or will not arrive. In order to meet these requirements, the Scheduler must classify incoming packets according to their service class, measure the current utilisation of the wireless link, check if the traffic conforms to the specified profile and possibly shape the traffic. AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 23 AC343 / Sie / WP2 / R / P / 02 / a1
  • 24. 5.1 Functional Specification The Audio Gateway and other VE-MASE components such as the HTTP Proxy make use of the Scheduler, which determines the transmission sequence of packets, that are transmitted over the same (wireless) network link. The major task of the scheduler is to provide delay bounds for packets transmitted by delay sensitive applications. In the context of the VE-MASE, the delay sensitive applications are of course the Audio Gateway clients, which have constrained delay and jitter requirements in order to enable interactive audio communication. In the past, several packet schedulers have been proposed. All schedulers apply a priority scheme that classifies incoming packet to a priority queue that has a specific delay and jitter bound property. Examples are the RCSP (Rate Controlled Static Priority) scheduler of the TENET protocol suite [FER90], the CSZ scheduler [CSZ92], CBQ (Class Based Queuing) [FJ95], WFQ (Weighted Fair Queuing) and the HOL scheduler (Head of Line). In general, the simple model depicted in figure 5.1, called a traffic conditioner can fulfill the requirements of the VE-MASE. Figure 5.1: Marker Logical View of A Traffic Packets Conditioner Classifier Meter Shaper Packets can be classified within two categories: Voice and Data, i.e. real-time and non real-time. A packet classifier determines the actual type of an incoming packet. Afterwards, the incoming packet streams are measured against their traffic profile. In case they do not exceed their expected behaviour, they are scheduled according to their priority. This may be done by a simple CBQ or HOL packet scheduler. In some situations, incoming packet streams may exceed their expected behaviour. For example, the sender of an audio stream may change its coding which results in bandwidth needs which are higher than the available output link capacity. When this happens, the stream may be forwarded to a dedicated Shaper that reduces the amount of bandwidth. The shaper may differ from implementation to implementation. Whilst a sophisticated shaper may discards extra packets of a hierarchically encoded stream, a simple shaper simply discards all packets. Page 24 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 25. 5.1.1 The VE-MASE Scheduler FTP The VE-MASE Scheduler follows the model depicted in HTTP Audio figure 5.2 – the interaction between the Scheduler and other Proxy Gate- way VE-MASE components is shown in figure 5.2. The Scheduler classifies the packets according to their incoming ports and transport layer information. For the sake of simplicity, the FIFO FIFO FIFO meter is skipped. In order to achieve a delay bound for audio traffic, a HOL scheduler performs non pre-emptive and work- conserving scheduling of packet queues. 5.1.1.1Service classes HOL The VE-MASE provides two service classes: Mobility Gateway • Real-Time: This service class includes all delay and jitter Mobile Terminal bounded sources. Examples are Voice over IP and video streams. Typically, this traffic is transferred by the UDP transport protocol. • Non-Real-Time: This class includes all data transfer FTP IP Client Browser Phone streams. Examples are file transfer, Telnet and HTTP traffic. Typically these packet streams are delivered by the TCP transport protocol. Figure 5.2: Interaction between the Scheduler and Other VE-MASE Components 5.1.1.2QoS parameters Specific QoS parameters for different packet sources are not necessary, since the VE-MASE distinguishes only between two service classes. The corresponding QoS parameters are calculated implicitly out of the service class. This methods eases implementation and needs no additional QoS set-up or reservation protocol, which would cause incompatibility with existing applications and services. 5.2 External Interfaces None. AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 25 AC343 / Sie / WP2 / R / P / 02 / a1
  • 26. 5.3 Internal Interfaces The Scheduler provides several services to other parts of the VE-MASE that allow the set-up, control and maintenance of real-time and non-real-time transport connections. The following architectural components interface with the Scheduler, which itself is a part of the UMTS Adaptation Layer: • UAL – UMTS Adaptation Layer (OnTheMove) The UAL provides a framework for the access to different access networks and bearer services. Since the Scheduler co-ordinates the resource demands of different services to the network, it is part of the UAL. • SAM – System Adaptability Manager The SAM provides means for multimedia conversion functions, such as audio transcoding. The Scheduler facilitates QoS trading by the SAM by providing it with statistical information about the status of the different service classes. This includes inter-arrival times, queue lengths, jitter and packet drop rates. • Communication Manager As the Communication Manager allows for the deployment of different application level protocols, it must convey to the Scheduler what service is needed by a specific application and how a corresponding stream is to be treated. No additional calls are necessary, since the UAL API is a superset of the WinSock 2 API, which provides means to express quality of service parameters for sockets. Information about the status of streams (e.g. bandwidth utilisation, jitter, etc.) can be obtained by subscribing to events, which indicate a certain condition. Page 26 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 27. 6 CALL MANAGER 6.1 Functional Specification (Services) The Call Manager is the component of the VE-MASE distributed architecture, which is responsible for the set-up, and termination of one-to-one voice/data conferences between a Mobile Client and a fixed network client. In the context of the demonstrator scenario, the fixed network client is the Voice/ Data Application Client (V/D AC) of a call centre. 6.1.1 Requirements The Call Manager is designed to meet the following requirements of D1 [CFM98]: • Requirement MOVE/R/13: The VE-MASE shall support voice/data conferencing functionality. - This is the basic function of the Call Manager, which manages call set-up, the invocation of VoIP clients, and the Collaboration Manager to provide voice/data conferencing functionality. • Requirement MOVE/R/14: The VE-MASE shall provide the ability to end a voice/data conference from both ends. - Refer to the section about operation/session initiation of this chapter. • Requirement MOVE/R/15: The V/D API shall provide the application layer with the ability to end a voice/data conference. - Refer to the section about the external API of this chapter and to chapter 13. • Requirement MOVE/R/16: The VE-MASE shall inform the application layer when a voice/data conference ends. - Refer to the section about the external API of this chapter and to chapter 13. • Requirement MOVE/R/17: The VE-MASE shall provide a MC with the ability to request a voice/ data conference with some appropriate client, or with a specified client. - Refer to the section about operation/session initiation of this chapter. • Requirement MOVE/R/18: The Call Manager shall automatically define the behaviour of the Collaboration Manager. - Refer to the section about the internal interface of this chapter and of chapter 13. • Requirement MOVE/R/19: The VE-MASE shall stop the Collaboration Manager when a voice session is terminated. - Refer to the section about the internal interface of this chapter and of chapter 13. AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 27 AC343 / Sie / WP2 / R / P / 02 / a1
  • 28. • Requirement MOVE/R/20: The initiation of the voice session should be fast after the Mobile User asks for it. - This Session Initiation Protocol is relatively lightweight. The signalling for call set-up is expected to take less than one second under normal network conditions. • Requirement MOVE/R/21: The V/D API shall allow to remotely launch the Call Manager with parameters concerning both ends. – This will not be a problem if the VoIP modules of the MC and the V/D AC could be remotely launched. • Requirement MOVE/R/22: The V/D API shall allow the application layer to be informed about the Call Manager state (waiting process, start of a voice conversation…) - Refer to the section about the external API of this chapter and to chapter 13. 6.1.2 Presumption The Call Manager will be based upon the Session Initiation Protocol (SIP) [HSSR98] standardised by the IETF working group MMUSIC. SIP is used as the call/session set-up protocol throughout the VE-MASE, i.e., from Mobile Client to the Voice Data Application Server (V/D AS). The signalling between the V/D AS and the V/D AC is beyond the scope of VE-MASE, but an example implementation will be provided by the demonstration service. SIP SIP XXX Mobile Mobility V/D Application V/D Application Client Gateway Server Client Fig 6.1: SIP Signalling in the VE-MASE 6.1.3 Call Manager in VE-MASE Distributed Architecture The functions of the Call Manager in the VE-MASE are achieved by the inter-operation of Call Managers and Call Manager Proxy residing on their respective client or server machines as shown in Figure 6.2. The Call Manager and the Call Manager Proxy realise two different types of SIP servers, namely the User Agent and the Proxy Server. The function of these two types of servers are described below: • User Agent: A program that implements a User Agent Client or a User Agent Server or both. ♦ User Agent client (UAC): A user agent client is a client application that is able to initiate SIP requests. Page 28 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 29. ♦ User agent server (UAS): A user agent server is a server application that contacts the user when a SIP request is received and that returns a response on behalf of the user. The response may indicate acceptance, rejection or redirection of the request. • Proxy Server: An intermediary program that acts as both a server and a client for the purpose of making requests on behalf of other clients. Requests are serviced internally or by passing them on, possibly after translation, to other servers. A proxy must interpret, and, if necessary, rewrite a request message before forwarding it. 6.1.4 Implementation of Call Manager and Call Manager Proxy The Call Manager on the MC is implemented as signed Java applet, while the Call Manager on the V/D AS and the Call Manager Proxy on the MG are implemented as Java applications. The Call Manager Java applet on the MC will be downloaded when the Information Server (IS) sends the web- page due to the change of location or upon user requests. In this case, the web-page has to have at least two frames. One frame is static while the other changes dynamically as the user browses the web-site. The dynamic frame may also change, when it is synchronised by with users in the session through the VE-MASE Collaboration Manager. The applet will be located in the static frame with a user-interface allowing the user to monitor the progress of the call. AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 29 AC343 / Sie / WP2 / R / P / 02 / a1
  • 30. Mobility Gateway (MG) Information Server (V/D AS) Mobile Client (MC) with HTTP Server V/D API V/D API Voice Over IP V/D Scheduler MASE Client Audio Gateway Web Site System Call Manager Adaptability Manager MASE Gateway Collaboration Manager Call Mgr Proxy Voice/Data Application Client (V/D AC) Voice/Data Application Server (V/D AS) V/D API Voice/Data Application Client (V/D AC) Call Manager Voice Over IP Figure 6.2: Call Manager and Call Manager Page 30 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 31. 6.1.5 Operation Session Initiation (typical sequence of events): Refer to figure 6.3: Message Sequence Chart of Session Initiation. 1. When MC's location has changed, the Information Server sends the location-dependent web pages to the MC. 2. When the mobile user triggers the "start session" button at the web-page, a request to start a session is sent to the Call Manager at the MC, which implements the SIP User Agent. In the request, the V/ D AS URL of the call centre and preferred session setting are specified. 3. The Call Manager at the MC sends a SIP INVITE request to the Call Manager at the V/D AS through the MG. 4. If the Mobile User has the right authentication to the Call Centre, the V/D AS immediately sends a "100, Trying" SIP Response back to the MC, otherwise it sends a "401, Unauthorized" SIP Response. 5. If a V/D AC is available, a "180, Ringing" SIP Response is sent to the MC. Otherwise, the request is queued and the V/D AS sends a "182, Queued" SIP Response to the MC. 6. When the V/D AC picks up the call, the V/D AS sends "200 OK" to MG. 7. Upon receiving "200, OK" Response, the Call Manager Proxy located at the MG will send similar SIP Response to the MC. At the same time, it will send an event with the relevant session data (e.g., network address of MC and V/D AC, etc.) to the Collaboration Server at the same MG. The Collaboration Manager that entails the Collaboration Server is responsible for sending the first web-page of the established session and also for subsequent synchronisation of the web-page dispatching. For details, refer to the chapter describing Collaboration Manager. 8. Once the MC received a "200, OK" Response, it sends an "ACK" SIP Request to the V/D AS. The MC now considers the session as established. The Call Manager at the MC will invoke the VoIP module which will then establish a connection to the respective V/D AC with the agreed session description that is carried in the SIP Response. 9. Once the V/D AS received the "ACK" SIP Request, the session is established. In the case of the demonstration service, the Connection Manager will activate a session between the designated V/D AC and the MC. The interaction between the Connection Manager and the Call Manager at the V/D AS is conducted through the external API of the VE-MASE. In the case where the V/D AC is not available and the request is queued, the Call Manager provides the option for external modules in the V/D AS, e.g., for a Interactive Voice Data Response (IVDR) module, to establish a separate session with the MC. The IVDR component could transmit contextual HTML pages and audio to the MC while the user is waiting for a free call centre agent. AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 31 AC343 / Sie / WP2 / R / P / 02 / a1
  • 32. 6.1.6 Session Termination 1. At any time, the MC or the V/D AS can terminate the initiation by sending a "BYE" SIP Request to the opposite party. When receiving such a request, the receiving party will send back a "200 , OK - BYE" SIP Response immediately. 2. Once a "200, OK - BYE" SIP response is sent or received, the session is considered as terminated. MC MG V/D AS (1) Location Dependent Web Pages IS (2, 3) INVITE sip://sales@move.com (3) INVITE sip://sales@move.com (4) 100 Trying Connection (5) 180 Ringing Manager (5) 180 Ringing (6) 200 OK (7) 200 OK Collaboration Manager (8) ACK (8, 9) ACK Connection VOIP Manager Figure 6.3: Message Sequence Chart (MSC) of Session Initiation Page 32 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 33. 6.2 External interfaces The Call Manager needs to provide a minimum external interface for an application to begin and end a voice/data conference. It also needs to inform the application about the state of the session. As the Call Manager modules are implemented in Java, the API will naturally be implemented as Java classes. More details on the external interfaces of the Call Manager can be found in chapter 13 (Call Manager API). 6.3 Internal interfaces The Call Manager modules interact with the following VE-MASE modules: • VoIP client at the MC and the V/D AC The Call Manager module at the MC invokes respective the VoIP module to start or stop an audio connection in the conference. Other than the START and STOP events, it could include PAUSE and RESUME events. Together with the events, the session description is attached. The content of the description will depend on the requirements of the VoIP modules at both ends of the conference to effectively establish an audio connection. • Collaboration Manager at the MG The Call Manager Proxy module at the MG will start the Collaboration Manager once it received the "200, OK" Response from the V/D AC, and stop the Collaboration Manager once it received a "BYE" Request from either end of the conference. Together with the events, the session description is attached. The contents of the description will depend on the requirements of the Collaboration Manager. The format of content description is likely to based on IETF Session Description Protocol (SDP) [HJ98]. • System Adaptability Manager at the MG The SAM is located at the MG together with the Call Manager Proxy. When a session has begun, the Call Manager Proxy will inform the SAM of a new session. It will provide the SAM with the agreed session description of both ends of the session. Session description includes the QoS attributes. The SAM will monitor all the media (i.e. both voice and data) of the session according to the QoS setting, and dynamically reports events of deviation and exception when the real time quality of service values of the session falls below the negotiated level of parameter values. The SAM could also propose a new QoS setting for the session in the event that the overall quality cannot be expected to be sustained on a previously determined level. With such an event, the Call Manager Proxy could send a SIP INVITE message to the Call Manager agents at both the MC and the V/D AS. If both MC and V/D AS agents agree on the new QoS setting, they will return with a SIP "200, OK" response. When receiving a "200, OK" response from both ends, the Call Manager Proxy will send a SIP "ACK" request to both the MC and the V/D AS. The moment the MC or the V/D AS receive the acknowledgement message, they will physically change the QoS setting of the session within their context. More details on internal interfaces of the Call Manager can be found in chapter 13 (Call Manager API). AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 33 AC343 / Sie / WP2 / R / P / 02 / a1
  • 34. 7 COLLABORATION MANAGER We presuppose a scenario that conforms to the proposal of the VE-MASE Distributed Architecture as described in chapter 6. However, a slightly more generic view on the architecture is taken, such that the VE-MASE Demonstrator Scenario [Ca98] is just one of several possible special instances of the general architecture. Essentially, there is the Mobile Client (MC) who communicates with some Voice/Data Application Server (V/D AS) via the Mobile Gateway (MG). (A typical example of a V/D AS would be a call centre agency disposing of a central service unit and one or several application agents (V/D AC)). The objective of the communication between MC and V/D AC is to exchange aural and visual information between both partners on the basis of shared HTTP data. "HTTP data" means data requested by a Collaboration Proxy, i.e., typically an HTML page specified by an URL. Such HTTP data is supposed to originate from some Information Server (IS), an entity which, in general, is separate from the V/D AS, and is also able to communicate with the MC via the MG. In the current proposal of the VE-MASE Distributed Architecture, the Collaboration Manager is positioned as a module on the MG. 7.1 Functional Specification (Services) The main functional purpose of the Collaboration Manager is to provide both MC and V/D AC with the option to have simultaneous access to HTTP data associated to a topic that has been negotiated between the MC and the V/D AC. This is achieved by two important functions: • HTTP dispatching: The IS sends each HTTP data item requested by the MC to the V/D AC, and vice-versa. • Notification: Each client informs the server that it has received a page, so that the server can inform all clients in the conference such that their display is synchronised. 7.1.1 HTTP dispatching Whenever the V/D AS intends to send some HTTP data to the MC, the V/D AC requests this data from the IS by an appropriate command, issued via the Collaboration Proxy and Multimedia Converter of the MG. The Collaboration Manager intercepts this command. Once the data is retrieved by the IS, they are sent to the MG and then converted according to the Mobile Client's QoS demands and constraints. Then, the Collaboration Manager sends them back to the V/D AS and mirrors them to the MC. Conversely, when the MC requests some HTTP data from the IS, those data are converted on the MG, then sent back and also mirrored to the V/D AC by the Collaboration Manager. Page 34 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 35. Several degrees of granularity and fine-tuning can be imagined, concerning the amount of synchronised attributes of shared HTTP data items on the sites of both MC and V/D AC. On the lower end of that range, we can envisage a collaborative browsing functionality similar to that offered by Netscape’s Conference tool. That is, the same web page is visible on the sites of both communication partners. In the middle of the granularity scale, simultaneous display of several frames can be envisaged, including, e.g., a synchronised highlighting of the frame currently focused on by the leading partner. On the upper end of the scale, all kinds of detail, such as cursor movements and clicks, would be synchronised. To be able to search the appropriate data before sending them to the MC, the V/D AC should be in the position to browse the Information Server without having the requested data mirrored to the client. Thus, the V/D AC could decide whether a web-page is in fact useful for the MC before actually sending it. An analogous option should be available also to the MC. 7.1.2 Notification During the conference, when a client receives HTTP data sent after a mirroring command from one of the clients of the conference, it should inform the Collaboration Server that the download is completed. Thus, when the server has received all the notifications, it can dispatch a global notification message, informing all the clients that the data has been completely mirrored. All the clients can then talk freely about the respective document. 7.1.3 Two implementation options In 7.2 and 7.3, we sketch two alternatives architectures for collaboration management (i.e., notification and HTTP dispatching), namely the so-called centralised and the decentralised approach. Conceptually speaking, they can be distinguished as follows: 1- The Collaboration Manager is fully integrated as a centralised agency into the VE-MASE. Then, the V/D AS provides functions to configure the settings of this module (IP addresses and ports, start and stop mirroring, who is leading partner of collaborative browsing session, etc…). Functions such as „push this data to that client“ will then have to be provided by the Collaboration Manager. 2- Notification and HTTP dispatching are decentralised, i.e., realised via Plug-Ins on the clients of a collaborative browsing session. A technical key problem for the centralised approach consists of the manner in which the VE- MASE on the MG can push HTTP data to the MC and the V/D AS. In the course of investigations up to this point, no commercially available software products offering such push facilities could be identified for possible use in the MOVE project. AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 35 AC343 / Sie / WP2 / R / P / 02 / a1
  • 36. A disadvantage of the alternative approach mentioned above is that decentralised notification and HTTP dispatching would in general have to maintain a large number of connections between multiple partners of a collaborative session (which grows polynomially with the number of participants). As opposed to that, a centralised session is easier to control because, for each partner, there is just one connection to the Collaboration Manager. However, in the most frequent case of just two communication partners, the general case collapses to a trivial one. Existing commercial solutions, such as Netscape Conference Collaborative Browsing or the Internet Explorer NetMeeting facilities, can readily serve as role models and points of departure for implementing a PlugIn-based approach. 7.2 A plug-in approach to decentralised collaboration management The basic idea of this approach is that collaborative web surfing between two partners is realised by Plug-Ins (as known from commercial Internet browsers) via the Collaboration Proxy, as depicted below. As before, collaborative browsing sessions are supposed to be started with the conference set- up protocol SIP (cf. chapter 6). IS GUI GUI leading leading start stop start stop API API Plug Plug -in -in Collab. Proxy MC MG V/D AS Figure 7.1: Architecture of decentralised collaboration management Communication of HTTP data takes place directly from PlugIn to PlugIn, without interference of the Collaboration Manager. In fact, the role of the Collaboration Manager is much less significant than in the centralised approach (7.3.2). In particular, no modification of HTML pages should be necessary in the decentralised approach. However, the PlugIn-based solution requires the MC, V/D AS and IS to collaborate over the same proxy. Also notice that this solution depends on the PlugIn implementations Page 36 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 37. of the particular browser tool which supports collaboration. A description of the flow of requests and messages after an initialising conference set-up dialogue is given in subsection 7.3.4. The curved lines at the bottom of the diagram above allude to the starting event of the collaboration session, i.e., the MC calls the V/D AS (e.g., by pressing a call button), and the Call Manager caters for the start (and in the end also for the stop) signal of the session. Such calls and signals of course need to pass the MG, but without interference of a sophisticated collaboration manager. Similarly, a signal which determines who is leading the session can be catered for. Together with the dashed line between the IS and MG, the curved lines also stand for the transmission of web content downloaded from the IS. Downloading can be requested through a VoIP session between the MC and the V/D AS over the Audio Gateway of the MG, which can in principle be independent of the web-content-based collaboration session. AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 37 AC343 / Sie / WP2 / R / P / 02 / a1
  • 38. 7.2.1 Message sequence chart for decentralised collaboration management MC MG IS V/D AS 1 2 4 3 5 6 7 8 9 : : : : : : : : : : : : 10 Figure 7.2: MSC for decentralised collaboration management Page 38 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 39. Comment: 1 The MC starts a collaborative web browsing session (e.g., after a call button is pressed). The call that starts the session is sent via the MG to the V/D AS. Notice that only the plain gateway functionality of the MG is involved in processing this call, no collaboration manager is needed. 2 The V/D AS acknowledges the start signal. 3 The V/D AS sends a URL requesting HTTP data to the MC via the MG. 4 The message in 3 is intercepted by the MG before it is passed to the MC, such that … 5 … the same HTTP data request sent in 3 and 4 is sent to the IS, such that … 6 … requested HTTP data is downloaded to the V/D AS and also … 7 … to the MC via the MG, which intercepts the message for multimedia conversion. 8 The converted HTTP data is forwarded to the MC. 9 The MC signals to the V/D AS that the HTTP data has been successfully downloaded. 10 After some further interchanges between MC and V/D AS, the MC decides to terminate the session and sends an "terminate session" to the V/D AS. AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 39 AC343 / Sie / WP2 / R / P / 02 / a1
  • 40. 7.3 A centralised approach 7.3.1 Message sequence chart for centralised collaboration management MC MG & Collaboration IS V/D AS 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Figure 7.3: MSC for centralised collaboration management Page 40 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 41. Comment: For specifying a complete protocol in terms of a message sequence chart, messages for signalling as well as messages for the transmission of aural and visual data would have to be captured in more detail. For the sake of illustrating the role of the Collaboration Manager, however, we have concentrated on the flow of HTTP data in the diagram above. A description of steps 1 - 14 is given below. Steps 3 through 8 illustrate how the Collaboration Manager reacts to a request by the V/D AS. Steps 10 through 14 show how the Collaboration Manager reacts to a request by the MC. It depends on the particular application whether such options should be granted to an MC at all. 1 The MC requests a session with the V/D AS, e.g. by pressing or clicking a device button. (That request is channelled through the MG, such that the Collaboration Manager can possibly provide the MC with some intermediate info while contacting the V/D AS. For simplicity, such intermittent activities are not displayed in the diagram.) 2 The MC request is forwarded to the V/D AS. 3 The V/D AS decides that the MC should consult a certain document containing HTTP data, e.g., a web page. A corresponding URL is sent as a request to the Collaboration Manager. 4 The Collaboration Manager forwards the URL request issued by the V/D AS to an appropriate IS. 5 The HTTP data specified by the URL is downloaded from the IS and sent to the Collaboration Manager. 6 HTTP data is sent as-is to the V/D AS. 7 After multimedia conversion, HTTP data is sent to the MC. 8 The same converted HTTP data is sent to the V/D AS. 9 The MC decides to share a certain HTTP data item with V/D AS. A corresponding request (e.g., "Get URL") is sent to the Collaboration Manager. 10 The Collaboration Manager forwards the request issued by the MC to an appropriate IS. 11 The requested HTTP data is downloaded from the IS and sent to the Collaboration Manager. 12 HTTP data is forwarded to the V/D AS. 13 After multimedia conversion, HTTP data is sent to the MC. 14 The same converted data is mirrored to the V/D AS. AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 41 AC343 / Sie / WP2 / R / P / 02 / a1
  • 42. 7.3.2 Architecture of a centralised Collaboration Manager The Collaboration Manager consists of five components stored on the Mobility Gateway : • the Collaboration Proxy, • the Collaboration Server, • a Collaboration Console, • a Collaboration Client applet. • an HTML Optimiser The following chart shows how these components are used : Mobile Client Mobility Gateway Collaboration Console Collaboration Server <HTML> .. . Collaboration Manager Collaboration Proxy IS Collaboration Client Applet … HTML Optimiser </HTML> Figure 7.4: Architecture for collaborative browsing When a conference starts between two users, the Call Manager Proxy informs the Collaboration Server about « who is talking with whom ». Role of the Collaboration proxy: Once a user has started a conference, each HTML page returned by the IS following an HTTP request will pass through the Collaboration Proxy. The role of this proxy is to add specific data to the HTML page : • JavaScript code to catch some events and send them to the Collaboration Client applet, Page 42 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 43. • the Collaboration Client • a reference to the Collaboration console to be launched if it does not already exist. The proxy makes use of the HTML optimiser to reduce the size of the HTML code sent to VE- MASE users. Role of the HTML Optimizer: This module performs some HTML optimisations to reduce the size of the original web-page. This mechanism allows saving precious bandwidth when sending HTTP documents to mobile clients. Filter001 GetSignature() CORE (HTML) Optimise(String) Language specific analysis Language Filter002 specific Input filters buffer Read Engine Output Filter100 Write buffer Language CORE (Other) specific Language specific analysis filters Figure 7.5: Architecture for the HTML Optimiser It is designed to be as modular as possible. It shall support the evolution of HTML by allowing changing and adding filters without recompiling the engine. The architecture of this module is shown in the following chart: In this mechanism, each filter is able to inform the CORE about what it is able to do. The CORE, who knows the syntax of the language to optimise (HTML in our case), decides when a filter has to be called. Role of the Collaboration Console applet: Once the HTML page has been downloaded, the Java Collaboration Client applet checks if a browser window with a Collaboration Console exists on the client. If not, it creates a new small window and launches the Console applet in it. This applet initiates a socket with the Collaboration Server. This socket is maintained for the duration of the conference and will be used to make messages transit between Collaboration Client applets and the Collaboration Server. A switch is displayed on the Collaboration Console, allowing the user to choose his collaboration policy. He can choose to send documents only (refusing incoming documents), to receive documents AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 43 AC343 / Sie / WP2 / R / P / 02 / a1
  • 44. only (allowing browsing without sending documents), or to send and receive documents (default setting during a collaborative session). He can also choose to temporarily stop the collaboration. A small text field informs the user about the sender of the page. The following picture shows the Collaboration Console GUI: Figure 7.6: Collaboration CONSOLE GUI Role of the Collaboration Client applet: This applet is present at the top of each HTML page. Only one of them can be active at the same time (connected to the console). If one is switched on, the previous active applet is automatically switched off. Browsing in a page with an inactive applet allows the user to look for information without sending it to the other, and to follow the collaborative browsing session through the active window. The role of this applet is to: • send to the Collaboration Console the notification command when the page is fully loaded and displayed. • change its display when the notification has been sent by all users inside the conference, to inform the user that the page can now be discussed with all other participants, • send mirroring orders to the Collaboration Console when the user has asked for a new page, • load a specified URL in the current window when it receives this command from the Collaboration Console. If a client browses during the conference with the mirroring task stopped, and wants to mirror his current page to a user, he just has to switch the applet on (if it was currently off). The current URL will then be sent by the applet to the Collaboration server, so that it can be dispatched to all other users in the conference. Page 44 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 45. Following is a picture of this applet: Figure 7.7: Collaboration Client applet Role of the Collaboration Server This server, running on the MG is the central point of the architecture. It gets information about the clients that are inside a conference from the Call Manager Proxy on the MG. With this information, it has two roles, that concern the HTTP dispatching and the Notification functionality: • When it receives a mirroring call from one client, it dispatches this order to all the other MC in the same conference, so that all the MCs request the same page. • When it receives a notification call from one client, it waits until it has received the same call from all the MC in the same conference and then sends a global notification to all of them. The following picture shows a preliminary GUI for the Collaboration server Figure 7.8: Collaboration SERVER GUI AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 45 AC343 / Sie / WP2 / R / P / 02 / a1
  • 46. Limitations: • This mechanism requires that the browser support JavaScript, Java applets and calls to Java applets from JavaScript. These three conditions are met by Microsoft IE3.02 and above and Netscape Navigator 3.0 and above. • This mechanism requires that a proxy change the content of all the pages. Benefits of this solution: • It is completely independent of the client browser (except for the above limitations). • No specific plug-in or client application has to be installed; the client part is completely encapsulated in the HTML page. • It is completely independent from the call-centre approach used for the demonstrator [Ca98]. It can be used in any other context. • As the conference is managed by the Collaboration Server, there is no theoretical limitation on the number of users. • The users can choose whether they want to mirror their choices or not. They can decide which open window will be used for collaboration. • The network traffic needed for this solution is low. The Collaboration Client applet is downloaded once and stored in the cache so that it does not have to be loaded for each page. • The collaboration proxy optimises the HTML code before adding the specific JavaScript and Java code. In most cases, the resulting HTML file will be smaller in size than the original one. • A single socket is initiated at the beginning of the session and is used for both HTTP dispatching and Notification functions. Page 46 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 47. 7.4 Internal interfaces In order to cope with low bandwidth constraints, some amount of multimedia conversion is necessary. The conversion should be applied before sending the data to the MC, so that the V/D AC workstation screen reflects, in a dedicated area, exactly what is displayed by the client. The rationale behind this requirement is as follows: Knowing that the data has arrived is not sufficient from a functional point of view, since the data may have been transformed (from colour to black-and-white, for example), pruned or distorted in some way. This requirement implies that the VE-MASE should provide some data dispatching functionality so that both the MC and the V/D AS receive the same processed data. 7.5 External interfaces The Collaboration Manager is an independent module. It can manage the data conferences without any help from outside. Nevertheless, an application may need to drive it in order to offer services to registered users (e.g., banking, voice mail services). That is the reason why it offers an external API allowing to send pages to an active conference (to all the users in the conference), or to a specified user (whatever his current conference is). This API is detailed in chapter 14.2.3. AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 47 AC343 / Sie / WP2 / R / P / 02 / a1
  • 48. 8 SYSTEM ADAPTABILITY MANAGER (SAM) The function of the extension of the System Adaptability Manager (SAM) is to perform Quality of Service (QoS) trading for the complete transmission medium (e.g., voice and data), i.e. by co- ordinating per-stream QoS trading. In OnTheMove, the SAM takes care of QoS trading. The basic assumption is that there is one data stream at a time being transmitted over the network. QoS trading on a per-stream basis (as in OnTheMove) is not sufficient in the VE-MASE scenario. For example, if the available bandwidth decreases, the data streams (e.g., audio and HTTP) are treated according to the individual user's profile settings. But there is no trade-off between modifications to different streams. Thus, the OTM SAM does not take into account how data streams that are transmitted simultaneously interact and affect each other. The SAM has to offer a certain trading policy for voice and data in the case of, e.g., decreasing bandwidth on a wireless link. The SAM reacts according to an overall QoS service class for voice and data (e.g., change the encoding of the audio stream, ask multimedia conversion of the HTTP-Proxy to reduce the size of HTTP data (e.g., reduce number of colours), shut down the voice or collaborative web browsing session). The SAM can be conceived as a part of the OnTheMove System Adaptability Manager of the MASE architecture [OTM]. This manager collects events and measurements from the Audio Gateway, the Scheduler, and in principle also from the Collaboration Manager, the HTTP Proxy, and its multimedia conversion component. The SAM monitors QoS parameters dynamically and delivers the overall voice/data QoS level to the Call Manager according to the QoS trading policy. 8.1 Functional Specification The VE-MASE Call Manager uses the SIP protocol [HSSR98] for session initiation and the SDP protocol [HJ98] for session description (e.g., media description). During call set-up or termination, the SDP parameters are determined as described in chapter 13 (cf. Public Abstract Class SDP and Public Abstract Class MediaDescription). The V/D-API of the Call Manager allows accessing other attributes of the SDP protocol that are used for Quality of Service (QoS). During an ongoing SIP-initiated session, the media description can be changed by the SDP protocol. These attributes can be set and changed by the two methods getOtherAttributes(String key, String value) addOtherAttributes(String key, String value). The Call Manager API allows the setting of the QoS parameters by calling the JTAPI method Call.connect( ) via the terminal object. Basically, the VE-MASE supports real-time (e.g., audio) and data (e.g., HTTP and collaborative web browsing) transmission. Depending on certain conditions, only one of the two or both can be used during the voice/data conference. The QoS Manager monitors the basic events from the Scheduler, the Audio Gateway, and in principle also from the Collaboration Manager, the HTTP Proxy including its multimedia conversion [OTM], and, in case of availability, also network events (e.g., GSM field strength, QoS parameters of UMTS bearers). The basic internal events describe properties such as below/above threshold of bandwidth, jitter, delay, call set-up time, the network type currently in use (GSM, wireless LAN), transcoding, type of voice codec, etc. They are mapped into predefined QoS classes and passed by an internal API to the Call Manager or the HTTP Proxy. Page 48 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 49. 8.2 QoS Classification TIPHON [TIP] defines four QoS classes (levels) for the fixed network and for the interworking between the PSTN and Internet telephony (VoIP) via gateways. They are numbered 1), 3), 4), 5) in the following list which displays the levels in an ordering of increasing quality. The mobility aspect warrants the integration of another quality level, number 2), situated between Medium and Best Effort. 1) Best Effort: This quality level of service will provide a usable communication but with significantly impaired speech quality. End to end delays are likely to impact the overall conversational interactivity. No upper bound on delays is required. The perceived voice quality will be less than, for instance, GSM FR. It is expected to be provided over the public Internet. 2) Low This level is supposed to take into account that the quality of voice transmission over the Internet currently is often considerably below the standards that are usual in conventional telephony. 3) Medium This is a quality level of IP telephony service that will provide a user experience similar to common wireless mobile telephony services, e.g., GSM networks using FR codecs. It is expected to be implemented over uncongested IP networks. 4) High This is a quality level of IP telephony service that will provide a user experience similar to PSTN (or e.g. recent wireless mobile telephony services in good radio conditions, for instance GSM networks using EFR codecs or devices using G.726 [ITU]) but with increased delay. It is also expected to be implemented over QoS engineered IP networks when trying to optimise bandwidth usage. 5) Best This is a quality level of IP Telephony service that will provide a user experience similar to PSTN or even better. It is expected to be implemented over QoS engineered IP networks and LAN environments. By a straightforward interpolation of values in a table devised by TIPHON [TIP], the following values can be assigned to the VoIP quality levels above. AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 49 AC343 / Sie / WP2 / R / P / 02 / a1
  • 50. Best High Medium Low Best Effort MOS Quality 4.0 – 5.0 3.8 – 4.2 2.9 – 3.8 2.0 – 2.9 0.0 – 2.0 Mouth- to-Ear Delay 0 – 150 ms 150 – 250 ms 250 – 350 ms 350 – 500 ms ≥ 500 ms Call Set-up 0 – 1 sec 1 – 3 sec 3 – 5 sec 5 – 10 sec ≥ 10 sec Figure 8.1: VoIP QoS Classes In the figure above, "MOs" stands for "Mean Opinion Score", which is the average voice codec quality as evaluated by a number of test persons. The scale is between 1 (lowest, unacceptable) and 5 (excellent). Conventional telephone codecs usually have a MOS above 4.0. "FR" stands for "Full Rate", EFR for "Enhanced Full Rate" (there are also "Half Rate" codecs, where HR is of lower quality than FR and EFR is better than FR). More precisely, GSM voice channel bandwidth can be allotted to users by half, full or more enhanced rates, depending on the current traffic. Finally, G.726 is an ITU-T recommendation for, among others, the conversion of a single 64 kbit/s PCM channel encoded at 8000 samples/sec to and from a 32 kbit/s channel [ITU]. In general, the quality of voice transmission and data transmission may vary considerably, relative to each other. For instance, the data quality may be sustainable on a comparatively high level while the voice level drops below a required value, or vice versa. By assigning one of the quality levels 1) − 5) separately to both the voice and the data portions of transmitted data, one would arrive at 25 combinations of possible QoS value tuples. However, a classification according to the table below seems more plausible and closer to distinctions supposedly made by the typical user. In the 'voice' column, we have chosen to differentiate between three cases of quality levels: In the first, any of VoIP QoS levels 1) − 4) is guaranteed to be sustainable during a session, where a predefined amount of delay can be expected to be never exceeded. (In a more refined table, four separate subcases could be made out of each layer for which one of levels 1) − 4) is guaranteed.) In the second, only a best effort result (level 5) can be predicted. The last of the three classes into which the various degrees of VoIP are lumped together is the case that, for some reason, no voice transmission is feasible. This case is simply denoted by 'No'. In the 'data' column, we have settled with two polar cases: either it works or it doesn't. More precisely, the positive one of the two cases is that data transmission (e.g., collaborative web browsing) can be provided with state-of.-the-art multimedia conversion, which of course depends on the currently available mobile network (i.e. either GSM or Wireless LAN, essentially). We abbreviate this case with CWB / MMC. The negative complement of this case is that no data transmission (and thus no collaborative web browsing) is feasible because the real-time audio stream uses all available bandwidth to insure the corresponding QoS level. We simply denote this case by 'No'. Page 50 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 51. Combining the three 'voice' cases and the two 'data' cases, we arrive at the following six QoS classes for integrated voice/data services: QoS Voice Data 1 1) - 4) CWB / MMC 2 1) - 4) No 3 5) CWB / MMC 4 5) No 5 No CWB / MMC 6 No No Figure 8.2: Voice/Data QoS Classes In principle, there are two possibilities for determining the mapping of QoS parameters via the Call Manager API: a) During call set-up, only the network type is defined (GSM, wireless LAN), and predefined QoS parameter settings are used by the SAM. b) The QoS classes are chosen independently of the network type during call set-up via the V/D- API of the Call Manager. The QoS classes are required and then, the SAM controls the corresponding thresholds for these specific parameter sets. The Call Manager is able to change the conference QoS attributes (i.e. defined by SDP) in case the currently required QoS class cannot be guaranteed or sustained during a session. The HTTP Proxy could receive new settings for the multimedia conversion from the SAM. 8.3 Events A sufficiently flexible quality-of-service management will have to behave adequately with regard to various events that may occur during a voice/data session. More precisely, the potential occurrence of such events has to be monitored by potentially afflicted components, and the SAM has to react dynamically in an appropriate manner. The MOVE middleware architecture suggests a classification of events into four layers, as illustrated in figure 8.3. The events identified in that figure are going to be classified and explained informally in separate subsections. AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 51 AC343 / Sie / WP2 / R / P / 02 / a1
  • 52. Voice/Data Application Application Events (3) Application Layer Voice/Data API Session Events (2) Session Layer Call Manager (1) Transport Events (1) (1) Audio HTTP Proxy / MMC Gateway Collaboration Mgr Transport Layer (1) Scheduler Network Events (0) Network Layer GSM WLAN UMTS Figure 8.3: Events for Voice/Data Integration The events in the figure above are symbolised by directed arrows. Events of type (0) - (3) are explained in detail in the sequel of this chapter. Besides the four types of events just mentioned, there is also a class of OnTheMove MASE events which can originate from "anywhere", i.e., they are not related to the classification according to layers in figure 8.3. Such events have been dealt with in-depth in the OnTheMove project [OTM]. For completeness, these MASE events are added, later, in figure 8.4. For example, profile parameters are communicated by such MASE events, e.g. terminal and network capabilities (battery voltage, used band width, …), user preferences (e.g., reachability), etc. Similarly, location information about the MC (co-ordinates, accuracy, velocity, etc.) is provided by MASE events. Similar to transport events, as described in 8.2.2, MASE events reflect the mobility aspect of the VE- MASE architecture. 8.3.1 Network events Low-level events originating from the underlying network layer are labelled (0) in figure 8.3. For example, network events indicate which bearers are available, what is their state, what are their Page 52 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 53. capabilities and QoS parameters (bit error rate, latency, etc). In the OnTheMove architecture (MASE) the UMTS Adaptation Layer (UAL) handles such events. 8.3.2 Transport events Similar to MASE events (mentioned above, in the introductory part of section of 8.2), also transport events, labelled (1), are relevant with regard to future UMTS services. They are dynamic or static events related to the functionality and the current state of MG modules. Three kinds of transport events can be distinguished: Voice-related transport events are issued by the Audio Gateway and the V/D Scheduler, data-related transport events are issued by the HTTP Proxy and its multimedia converter module, and conference-related transport events are issued by the Collaboration Manager and the Call Manager Proxy (cf. fig. 8.4). For example, a transport event can trigger suspension of data communication due to high traffic congestion, in order to give way to voice communications with higher priority, or to free the lines for communication between partners with higher priority. A list of typical situations, which create such kind of events, follows. • Delay above voice threshold. • Delay variations (jitter) above threshold. • Bandwidth below threshold for Voice/Data conference. • Bandwidth used only for voice session (no additional data session possible). • Bandwidth below threshold for voice session. • Multimedia conversion is not possible or takes too much time for a certain kind of object. • Scheduler not working properly (may be something like audio buffer holds old data due to high delay and has to be flushed; cf. chapter 5). • No data, no voice traffic after a certain elapse of time. 8.3.3 Session events The SAM will monitor all the media (i.e. both voice and data) of the session according to the QoS setting, and dynamically reports events (1) of deviation and exception when the real time quality of service values of the session falls below the negotiated level of parameter values. The SAM could propose a new QoS setting for the session (e.g., new session description parameters for SDP) to the Call Manager if the overall quality cannot be expected to be sustained on a previously determined level. Typical session events, labelled (2) above, include possibilities to suspend, resume, or modify a conference session (e.g., overall OoS level 2: only audio session, no collaborative browsing session possible). 8.3.4 Application events Application events, labelled (3) above, are events related to specific applications running on the V/D Application Server. They are further dealt with separately in chapter 16: "How to use the V/D API". AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 53 AC343 / Sie / WP2 / R / P / 02 / a1
  • 54. 8.4 SAM architecture Figure 8.4, below, illustrates the functionality of the SAM on the Mobility Gateway. In 8.4, the MASE events originating from the Profile/Context/Location Manager are taken care of by the MASE Event Manager inside the General Support Layer. Mobility Gateway Audio Gateway / V/D Scheduler HTTP Proxy / (1a) Voice Transport Events Multimedia Conversion Collaboration Mgr (1b) Data Transport Events Q O SAM S (1c) Conference Events A P I (2) Session Events Call Manager (SIP) Proxy MASE Profile / Context / Location Mgr MASE Event Manager Profile / Context / Location Mgr events Figure 8.4: SAM Architecture Page 54 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 55. Network events (0) have been described in 8.2.1. Reactions to changes in profile, context and location have been treated in the OnTheMove project [OTM]. As indicated in 8.2.2, three kinds of transport events (1a,b,c) can be distinguished; they are either related to voice (1a), data (1b) or conference properties (1c). As a reaction to such events, conference participants are informed about the current state or about changes of these properties. Application events (3) are enabled by an external V/ D API and are further dealt with in chapter 16. Dashed arrows in figure 8.4, originating from V/D AS and pointing to Call Manager (SIP) Proxy or Collaboration Manager, symbolise reactions to events. 8.5 External Interfaces (none) 8.6 Internal Interfaces For a proper handling of various kinds of events as described above, it is sufficient to use existing APIs of MASE and VE-MASE components, as detailed below. • Audio Gateway / V/D Scheduler Interfaces of these components are described in chapters 4, 5 and specified in chapters 11, 12. For handling audio transport events, they should be made accessible to the SAM. No additional API functionality is needed. • HTTP Proxy / Multimedia Converter The corresponding QoS parameters are stored in the OnTheMove profile manager. Standard MASE events can be related to the change of these profile entries. No additional API functionality is needed. • Collaboration Manager For handling conference-related transport events, relevant interfaces should be made accessible to the SAM. No additional API functionality is needed. So far, no Collaboration Manager related events are identified. • Call Manager (SIP) Proxy A description of the interaction between the SAM and the Call Manager (SIP) Proxy is given in chapter 6. Moreover, interfaces between the SAM and the Call Manager Proxy are described in chapters 13 and 15. In case collaborative web browsing is not feasible (e.g., because of high priority for voice under the constraint of low bandwidth), the Call Manager will inform the Collaboration Manager. AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 55 AC343 / Sie / WP2 / R / P / 02 / a1
  • 56. 9 ONTHEMOVE MANAGERS The managers listed below have been identified as components in the overall VE-MASE architecture (chapter 3). The same components have already been realised as modules in the ACTS project AC043 OnTheMove [OTM] and can be re-used in MOVE without further ado. The design of the OnTheMove Managers is described in the public Deliverables D17 (MASE V1.0) and D33 (MASE V2.0). In particular, this also holds for the respective APIs (cf. [OTM] public Deliverables D13, D28, D46). • The Location Manager (MASE V1.0/2.0) offers the current position of the Mobile Client to applications on the Mobile Client and represents an independent component of the MASE. • The HTTP Proxy as part of the Communication Manager (MASE V1.0/2.0) and the Multimedia Conversion (MMC) as part of the System Adaptability Manager (MASE V1.0/2.0) enhance the VE-MASE by adapting images during the collaborative web browsing session. • The Profile Manager (MASE V1.0/2.0) on the Mobility Gateway is part of the MASE System Adaptability Manager and stores network, terminal, user, and application-relevant parameters. • The User Manager, a component of the General Support Layer (GSL), is essential to enable a multi-user capable MASE V2.0. The User Manager is responsible for management of users and enables access to user-specific information, like user profiles and accounting information. • The Directory Service (MASE V1.0) as part of the GSL can resolve the address of the mobile user. • The Event Management part of the GSL (MASE V1.0) enables the MASE to react to events generated by other entities or by the application. Some VE-MASE Managers are extensions of already existing MASE Managers. VE-MASE Manager extends OnTheMove Manager uses OnTheMove Manager SAM SAM Events Audio Gateway Communication Manager Events Scheduler UAL Events For reason of conciseness, we leave it with the reference to OTM documentation [OTM], instead of undue text expansion by including copies of already existing documents. Page 56 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 57. PART II: THE API 10 OVERVIEW OF THE V/D-API In this second part of the document, an API is specified for each of the components to which a separate chapter has been allotted in Part I. 10.1 General Concepts For taking into account the specifics of mobile communication and the heterogeneity of mobile networks, a set of functions and services are offered by the Voice-Enabled Mobile Application Support Environment to Mobile Applications through the so-called V/D-API. The V/D-API extends the existing Mobile-API of OnTheMove [OTM] and offers new functionality with respect to Voice over IP, transport of data (e.g., collaborative web browsing) and voice/data integration. 10.2 Functional Decomposition of the V/D-API The VE-MASE architecture has been based on a set of functional components and entities, as detailed in the first part of this document. Each of these components addresses a defined functional domain and has its own API. The V/D-API is essentially constituted by the union of these component- specific APIs. Thus, the V/D-API reflects closely the VE-MASE software architecture in term of functional entities, as described in part I (in particular, cf. chapter 3). This part II follows the sequence of respective chapters for VE-MASE components. 10.3 Distribution of the V/D API The physical view of the VE-MASE architecture (cf. section 3.1) identifies physical entities and the interfaces between them. The functional view of the VE-MASE architecture (cf. section 3.2) represents the conceptual VE-MASE entities as a logical abstraction of their implementation. The distribution of the V/D-API can be straightforwardly mapped to the distribution of the functional entities over the physical structure of the VE-MASE architecture, as shown in figures 3.2 and 6.2. 10.4 Notations and Conventions Standard notation and self-explaining nomenclature is used throughout, wherever possible. Due to the variety of partners contributing to this document, the formal specifications in different chapters may come in different forms and shapes. They may either be in OMG IDL syntax, Java syntax or a Java-like syntax. In particular, the formal definition of APIs is often provided in the respectively AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 57 AC343 / Sie / WP2 / R / P / 02 / a1
  • 58. adopted programming language, Java. Their notations and conventions are not recalled here, as they are commonly used in the application developers community. For a complete description of IDL, the reader is referred to chapter 3 of [CORBA]. Some notation features are recalled subsequently: - Comments: - The characters /* starts a comment, which terminates with the characters */. The characters // start a comment, which terminates at the end of the line on which they occur. Comments may contain alpha-numeric, graphic, space, horizontal tab, vertical tab, form feed and new line characters. - Identifiers: There is only one namespace for identifiers. Identifiers for the following kinds of definitions are scoped: • types • constants • enumeration values • exceptions • interfaces • attributes • operations - Integer Literals: An integer literal consisting of a sequence of digits is taken to be decimal (base ten) unless it begins with 0 (digit zero). A sequence of digits starting with 0 is taken to be an octal integer (base eight). A sequence of digits preceded by 0x or 0X is taken to be a hexadecimal integer (base sixteen).- Character Literals A character literal is one or more characters enclosed in single quotes, as in ‘x’. - String Literals A string literal is a sequence of characters (as defined in “Character Literals”) surrounded by double quotes, as in “....”. Due to the extensive use of the Java language for implementing the VE-MASE, several APIs are, for convenience, defined through Class methods, ensuring a common understanding between Application and MASE designers. Page 58 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 59. 10.5 Summary of the methods API Class Method Description Audio AudioChannel openChannel allocates AG resources for VoIP Gateway channel, connects sender and receiver closeChannel de-allocates resources for VoIP channel, disconnects sender and receiver Call DefaultJtapiPeer getName returns name of JtapiPeer object Manager instance. getService returns service supported by implementation getProvider returns instance of provider object DefaultSipProvider addIvdrObject installs interactive voice response unit createVirtualTerminal adds VirtualTerminal object removeVirtualTerminal removes VirtualTerminal object VirtualTerminal nil (empty) (Interface) CallManagerProxy getActiveSessions retrieves list of current sessions ((Interface) getSessionUsers retrieves list of current users of a specific session getGlobalSession retrieves the session ID of specified user's session getSession retrieves the session description (SDP) of specified user's session IVDR getMaxSessions gets maximum number of (Interface) supported sessions newSession initiates new IVDR session end point startSession starts session immediately stopSession stops session immediately stopAllSession stops all sessions in IVDR TerminalControl getTerminalMediaDescription gets MediaDescription (Interface) newMediaSession initiates new session end point stopSession stops ongoing session setVirtualTerminal registers VirtualTerminal AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 59 AC343 / Sie / WP2 / R / P / 02 / a1
  • 60. API Class Method Description Call Sdp createSdpResponse creates Sdp object Manager ctd. addMediaDescription adds media description replaceMediaDescription replaces media description getGlobasSessionID gets globally unique SDP session ID getMediaDescription gets the respective media description getOwner gets the creator of this SDP message getMessageVersion gets the SDP message version getSessionConnectionIP4Address returns the IP4 address getBindWidthInfo gets specified bandwidth getEncryptionKey gets default encryption key getOtherAttributes gets list of other attributes MediaDescription setGlobalSessionID sets GlobalSessionID setPort sets transport port setTransportProtocol sets transport protocol setFormat sets format setConnectinInfo sets connection information setMediaTitle sets media title setBandWidthInfo sets proposed bandwidth setEncryptionKey sets proposed encryption key addOtherAttributes adds other attributes getPort gets transport port getTransportProtocol gets transport protocol getFormat gets format getConnectinInfo gets connection information getMediaTitle gets media title getBandWidthInfo gets proposed bandwidth getEncryptionKey gets proposed encryption key Page 60 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 61. API Class Method Description Collaboration CollManager NewConf informs Collaboration Mgr of Manager conference start AddUser adds user to conference UserLeavesConfs deletes user from conference EndConf terminates conference CollMgrDriver SUPERREG registers super user URL dispatch URL to current users SUPERUNREG unregisters super user from conference SUPERSEND TOCONF sends single page to each user of specified conference SUPERSEND TOUSER sends single page to super user SAM ConferenceTrade newSession indicate creation of new session changeSession indicate change in session description startSession start monitoring session immediately stopSession stop monitoring session immediately stopAllSessions stop monitoring all sessions AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 61 AC343 / Sie / WP2 / R / P / 02 / a1
  • 62. 11 AUDIO GATEWAY API 11.1 Overview of the API The Audio Gateway offers an API to other processes for establishing, maintaining and terminating Voice over IP channels. The services provided by the Audio Gateway API (AG API) will generally be employed by the Session Manager in order to control an audio conference, but can also be directly accessed by VE-MASE aware entities. As the Audio Gateway is part of the Communication Manager, its API is a subset of the Communication Manager API (CM API). The AG API offers the following services to its clients: • Opening simplex VoIP channels to forward voice packets from one or more sources to a destination, optionally changing the encoding. The format of the output stream is either the same as the input stream (default setting) or is determined by the SAM. The SAM may chose to transcode the input stream to a more appropriate format supported by the gateway as well as the gateway client. • Closing VoIP channels to terminate an existing connection. • Providing information about existing channels, by the event mechanism of the MASE Event Manager. An event is generated when certain characteristics of a channel, such as the bandwidth consumed by outgoing packets, the average queue length, etc., exceed a threshold as stated in the corresponding profile. 11.2 Specification of the API The Audio Gateway interacts with other VE-MASE entities to perform its functions. In particular, the status of a channel can be accessed by a VE-MASE aware application through the Event Manager within the GSL to which the gateway reports operational events. A channel, in the context of the Audio Gateway API, is a unidirectional connection between two peers, i.e. for the purposes of an interactive audio conference two channels need to be opened, one for each sender. It is important to note that legacy Internet telephony applications do not use the Audio Gateway API. Instead, legacy applications directly establish a session with the gateway, unaware of the fact that it is not the endpoint of communication. In this case, the gateway’s functionality is either controlled by the user or by the Call Manager Proxy. 11.2.1Textual Definition The Audio Gateway API includes the following primitives: OpenChannel allocates Audio Gateway resources for a VoIP channel, connecting a sender and a receiver. This primitive has the following parameters. Page 62 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 63. Parameter name Parameter description In parameters srcAddr Transport level address of the source location destAddr Transport level address of the target location destTTL Requested Time To Live for packets destined for target location qos Requested Quality of Service according to a predefined profile Out parameters hChannel Communication handle for use on CloseChannel Completion code of the compCode operation reason Qualifier of the completion code The mixing of several different audio sources into a single stream is currently not supported by the VE-MASE and is thus not catered for by the V/D-API. Mixing could be provided for by replacing the srcAddr-argument of the call OpenChannel by a set of addresses. CloseChannel de-allocates Audio Gateway resources for a VoIP channel. This primitive has the following parameters. Parameter name Parameter description In parameters hChannel Communication handle returned from a call to OpenChannel Out parameters compCode Completion code of the operation reason Qualifier of the completion code 11.2.2State Tables The Audio Gateway API does not require a state table description. AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 63 AC343 / Sie / WP2 / R / P / 02 / a1
  • 64. 11.2.3IDL Definition module MASE { module CM { module AudioGateway { interface AudioChannel :GSL::Event::Producer { readonly attribute long inBandwidth; readonly attribute long outBandwidth; readonly attribute long avgQueueLength; readonly attribute long avgJitter; readonly attribute long lastPacketReceived; void openChannel( in string srcAddr, in string destAddr, in int destTTL, in any qos, out long hChannel, out long compCode, out long reason); void closeChannel( in long hChannel, out long compCode, out long reason); readonly attribute GSL::Event::Identifier thresholdExceeded; }; interface thresholdExceededEvent :GSL::Event::Package { readonly attribute AudioChannel channel; }; }; }; }; Page 64 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 65. 12 SCHEDULER API 12.1 Overview of the API The VE-MASE’s packet scheduler provides a means to prioritise different packet streams on the wireless link, e.g. to ensure that the transmission of real-time audio data is not delayed by other data. As the Scheduler is part of the UAL and the UAL API is a superset of the WinSock API version 2 [Hall97] it is not necessary to provide applications with a separate interface to the Scheduler. All packet stream characteristics and requested quality of service parameters can be accessed and modified by WinSock’s QoS structures and its notion of socket groups. Likewise, admission control can be conducted by rejecting the creation of a socket. Thus, new calls to access these functions are not required. Nevertheless, there is a need for informational services, indicating certain conditions, such as exceeding a certain queue length or delay boundary. This information can be passed to application processes or other VE-MASE entities being responsible for the overall QoS by means of the OnTheMove Event Manager. This chapter will present the scheduler events an application or VE- MASE entity can subscribe to. 12.2 Specification of the API 12.2.1Textual Definition The events generated by the Scheduler are always linked to a specific stream, i.e. not to the Scheduler or the link as a whole. These events fall into two categories: 1. Events indicating that a certain predefined threshold has been exceeded. This concerns the bandwidth of a stream’s incoming packets, their average delay variation and the current queue length. 2. Events indicating that the scheduler has performed a certain action, such as the fact that a packet has been dropped, e.g. due to lack of buffer space. 12.2.2State Tables The Scheduler API does not require a state table description. AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 65 AC343 / Sie / WP2 / R / P / 02 / a1
  • 66. 12.2.3IDL Definition module MASE { module UAL { module Scheduler { interface PacketStream :GSL::Event::Producer { readonly attribute long inBandwidth; readonly attribute long avgQueueLength; readonly attribute long avgJitter; readonly attribute long lastPacketReceived; readonly attribute GSL::Event::Identifier thresholdExceeded; readonly attribute GSL::Event::Identifier packetDropped; }; interface thresholdExceededEvent :GSL::Event::Package { readonly attribute PacketStream packetstream; }; interface packetDroppedEvent :GSL::Event::Package { readonly attribute PacketStream packetstream; }; }; }; }; Page 66 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 67. 13 CALL MANAGER API As already indicated in section 6.2, the Call Manager needs to provide the minimum external interface for the application to begin and end a voice/data conference. It also needs to inform the application about the state of the session. As the Call Manager modules are implemented in Java, the API will be expressed in terms of Java classes. 13.1 Overview of the API (External Interfaces) The Java Telephony API (JTAPI ) from Sun has been identified as the API for the basic call set-up. The external API of the Call Manager will be based on the core API of JTAPI version 1.2. The Call Manager will implement the JtapiPeer and Provider object of JTAPI. In addition to the core API, the Call Control extension package will also be implemented. However, the JTAPI 1.2 specification does not provide an interface for an application to dynamically attach an external interactive voice and data response unit (IVDR) to existing JTAPI implementation. The Call Manager defines an additional interface for this purpose. The interface will allow an external IVDR module to be added to a CallControlAddress object, so that all the incoming connections are in the call control. The CallControlConnection.QUEUED state will receive the media/ data streams that are emitted by the IVDR module. Also, in the JTAPI 1.2 specification, the JTAPI Provider begins with the knowledge of certain Terminal and Address objects defined as its local domain. An application cannot create Terminal objects and Address objects in the local domain. The Call Manager will allow dynamic creation of such objects. Thus, the Voice/Data Application Server (V/D AS) can add an additional Voice/Data Application Client (V/D AC) which could be modelled as a JTAPI Terminal object in the local domain. A single Java package called ve_mase.callmanager will be created as the API of the Call Manager. This package will be used in conjunction with the JTAPI 1.2. The following describes the ve- mase.callmanager package. AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 67 AC343 / Sie / WP2 / R / P / 02 / a1
  • 68. 13.2 Specification of the API (External Interfaces) This section contains a textually commented top-level Java specification of the Call Manager API (external). Package ve_mase.callmanager public class DefaultJtapiPeer implements javax.telephony.JtapiPeer Introduction: This is the VE-MASE implementation of javax.telephony.JtapiPeer. Constructor: Nil. This object will be returned by calling javax.telephony.JtapiPeerFactory.getJtapiPeer(null) Methods: public String getName() Returns the name of this JtapiPeer object instance. This name is the same name used as an argument to JtapiPeerFactory.getJtapiPeer() method. Returns: The name of this JtapiPeer object instance. public String[] getService() Returns the services that this implementation supports. This method returns null if no service is supported. Returns: The services that this implementation supports. public Provider getProvider(String providerString) throws ProviderUnavailableException Returns an instance of a provider object given a string argument that contains the desired service name. Parameters: ProviderString: A string which contains the desired service name. If it is null, the provider for default service will be returned. With null service name, this method returns the DefaultSipProvider object. In the current Call Manager implementation, this is the only type of provider available. The returned provider is in the Provider.OUT_OF_SERVICE state. Optional arguments may also be provided in this string, with the following format: Page 68 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 69. < service name > ; arg1 = val1; arg2 = val2; ... A semicolon separates each optional argument pair that follows. Following are the two defined keys: login: provides the login user name to the provider. passwd: provides a password to the provider. Returns: An instance of the provider object. Post-conditions: this.getProvider().getState() == Provider.OUT_OF_SERVICE Throws: ProviderUnavailableException -- Indicates that the provider corresponding to the given string is unavailable. public class DefaultSipProvider implements javax.telephony.Provider Introduction: This is the VE-MASE implementation of javax.telephony.Provider that provides the SIP session service. Constructor: Nil. This object will be provided by calling DefaultJtapiPeer.getProvider(). Methods: public void addIvdrObject(IVDR ivdrObject, CallControlAddress address) This method allows an application to install an Interactive Voice/Data Response Unit, IVDR to a particular CallControlAddress. The IVDR unit will be used to provide an interactive service to callers queuing at the CallControlAddress. Parameters: ivdrObject - The IVDR object that implements the IVDR interface. address - The CallControlAddress. Throws: InvalidIvdrObjectException - Error in accessing the IVDR object. public VirtualTerminal createVirtualTerminalObject(TerminalControl control, Address[] addresses) This method allows the application to add an additional terminal in the local domain. AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 69 AC343 / Sie / WP2 / R / P / 02 / a1
  • 70. Parameters: control - application object that implements TerminalControl interface. addresses - The addresses in the local domain that the created terminal will be associated with. If null is specified, all the addresses in the local domain will be associated with this created terminal. Throws: InvalidTerminalControlException - Error in accessing the TerminalControl object. Returns: The created terminal object. public void removeVirtualTerminal(VirtualTerminal terminal) To remove the VirtualTerminal. Parameters: terminal - The virtual terminal to be removed from the local domain. Throws: TerminalCouldNotBeRemoved - This occurs when the terminal is not a virtual terminal created by the application or in case of a timeout during the removal of the VirtualTerminal. public interface VirtualTerminal extends java.Telephony.Terminal Introduction: This interface differentiates the VirtualTerminals that are created by the application and those that are created by the provider when the provider is created. public interface IVDR Introduction: An IVDR object is a multimedia object that provides multimedia data to the callers when they are queuing for a CallControlAddress. There should only be one such object per address. The IVDR unit could be a simple object that plays some audio file to the caller's audio channel or a complicated object that provides web-page pushing, video, and other forms of information limited only by the capability of the caller. Page 70 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 71. Methods: public int getMaxSessions() Get the maximum number of concurrent sessions supported by the IVDR object. Returns: An integer indicating the maximum concurrent sessions allowed in the IVDR object. public Sdp newSession(Sdp caller, boolean autoStart) To initiate a new IVDR session end point. Parameters: caller - The session description of the caller. autoStart - If true, start the session immediately without the need for a separate startSession(String globalSessionID) command. Returns: The session description of the IVDR session end point for the created session. This description will be attached to the SIP response message for the caller. public startSession(String globalSessionID) To start a session immediately. Parameters: globalSessionID - A globally unique ID to represent a session as described in the SDP. Throws: InvalidSessionIDException - No session end point in the IVDR object is associated with this globalSessionID. public stopSession(String sessionID) To stop a session immediately. Parameters: globalSessionID - A globally unique ID to represent a session as described in the SDP. Throws: InvalidSessionIDException - No session end point in the IVDR object is associated with this globalSessionID. public void stopAllSessions() To stop all sessions in the IVDR. AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 71 AC343 / Sie / WP2 / R / P / 02 / a1
  • 72. public interface TerminalControl Introduction: With the provision of this interface, the application media object will allow the Call Manager to map the operations to the respective VirtualTerminal object created with this object. Methods: public MediaDescription getTerminalMediaDescription() To get the MediaDescription of this object. MediaDescription describes the transport protocol, network address, media format and other attributes of this media object. These attributes are all defined in the SDP. With this information, the Call Manager will be able to set up the media connection between the calling terminal and the VirtualTerminal that represents this media object. Returns: The MediaDescription of this object. public MediaDescription newMediaSession(MediaDescription callerMedia, boolean autoStart) To initiate a new session end point in the TerminalControl. Parameters: callerMedia - The media description of the caller. If null is specified, no media session is created; however, the MediaDescription of this object will still be returned. autoStart - If true, start the session immediately without the need for a separate startSession(String globalSessionID) command. Returns: The MediaDescription of the TerminalControl end point for the created session. This description will be attached to the SIP response message to the caller. Throws: ControlBusyException - When the control already has an active session. public MediaDescription newMediaSession(String globalSessionID, boolean autoStart) Initiate a new media session. Parameters: globalSessionID - The SDP sessionID of the session to be created. If null is specified, no media session is created; however, the MediaDescription of this object will still be returned. autoStart - If true, start the session immediately without the need for a separate startSession(String globalSessionID) command. Page 72 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 73. Returns: The MediaDescription of the media control object for the created session. This description will be attached to the caller's SIP request message. Throws: ControlBusyException - When the control already has an active session. public void stopSession(String sessionID) To stop an ongoing session. Throws: InvalidSessionIDException - No session end point in the IVDR object associated with this globalSessionID. public void setVirtualTerminal(VirtualTerminal terminal) This is for the Call Manager to register the respective VirtualTerminal at the media object. This will allow the implementation of the TerminalControl to observe the related JTAPI objects of the VirtualTerminal, e.g., the Call object. public abstract class Sdp Introduction: This class implements the Session Description Protocol [HJ98]. Constructor: public Sdp createSdpResponse() The created Sdp object will have the same globalSessionID, and the same session attributes supposed to be common to both ends of the session. The version of the SDP message will be incremented. All the media information will remain unchanged except the transport-specific information. Methods: public void addMediaDescription(MediaDescription media) To add a media description in the SDP message. Parameters: media - The media description to be added in the SDP message. AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 73 AC343 / Sie / WP2 / R / P / 02 / a1
  • 74. public void replaceMediaDescription(MediaDescription media) Replace the respective media description. Parameters: media - The new media description. Throws: NoExistingMediaDescriptionException - No existing media description for the type of media specified. public String getGlobalSessionID() To get the globally unique SDP Session ID. Returns: The globally unique SDP Session ID. It is formed by four fields in the "o=.." originator header: <username> - The user's login on the originating host. <session id> - This is up to the creating tool. Suggested is a Network Time Protocol timestamp to ensure the uniqueness. <network type> - This is a text string giving the type of network. So far, "IN" is defined to have the meaning of "Internet". <address type> - This is a text string giving the type of address. So far, IP4 and IP6 have been defined. <address> - This is the globally unique address of the machine from which the session was created. For an IP4 address type, it could be a fully qualified domain name of the machine, or the dotted-decimal representation of the IP version 4 address of the machine. It should never return null. public MediaDescription getMediaDescription(String mediaType) Get the respective media description. Parameters: mediaType - Currently, defined media are "audio", "video", "application", "data" and "control". The difference between "application" and "data" is that the former is a media flow such as web-collaboration, and the latter is bulk-data transfer such as transferring of program executables which will not typically be displayed to the user. "control" is used to specify the additional session/conference control channel for the session. Page 74 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 75. Returns: The MediaDescription of the media type is null when there is no media description for the media type. public String getOwner() Get the owner or creator of the session as specified in the "o=<username> <session id> <version> <network type> <address type> <address>" header of the SDP message. Returns: owner or creator of the session as specified in the "o=<username> <session id> <version> <network type> <address type> <address>" header of the SDP message. It should never return null. public getMessageVersion() The message version change when there is any modification of the SDP message. Note that with the change, the GlobalSessionID remains the same even when the message is modified. Returns: <version> field in the "o=..." header of the SDP message. It should never return null. public getSessionConnectionIP4Address() This returns the <connection address > sub-field of the "c=<network type> <address type> <connection address>" header if the address type is IP 4 and the network type is IN. Returns: String represents the IP 4 address. It could be a fully qualified domain name of the machine, or the dotted-decimal representation of the IP version 4 address of the machine. null is returned in the case when the address is not an IP 4 address or the "c=.." header is not in the SDP message. public String getBandWidthInfo() This specifies the proposed bandwidth to be used by the session. Refer to the SDP for its format. Returns: The formatted string represents the proposed bandwidth for the session. null is returned when "b=.." header is not part of the SDP message. public java.util.Property getEncryptionKey() Get the default encryption key description of the entire session. Refer to SDP for its format. Returns: The formatted string represents the proposed default encryption key for the session. null is returned when "k=.." header is not in the SDP message. public java.util.Properties getOtherAttributes() AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 75 AC343 / Sie / WP2 / R / P / 02 / a1
  • 76. Get a list of other attributes in the session which are specified as "a= key:value" line in the SDP. Returns a properties object containing all the additional session attributes specified as "a= key:value" in the SDP message. null is returned when "k=.." header is not in the SDP message. public abstract class MediaDescription Introduction: Constructor: MediaDescription(String mediaType) Methods: public void setGlobalSessionID(String globalSessionID) To set the GlobalSessionID in the media description. All the MediaDescriptions of an SDP message will share the same GlobalSessionID. Parameters: globalSessionID - String representing the globally unique session ID. Throws: GlobalSessionIDExistException - The globalSessionID has already been set. public void setPort(int port) To set the transport port to which the media stream will be sent. Parameters: port - The integer port number. For transport based on UDP, the value should be in the range of 1024 to 65535. For RTP compliance, it should be an even number. public void setTransportProtocol(String protocol) To set the transport protocol for the media. Parameters: protocol - String representing the protocol. So far the following protocols have been defined: Page 76 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 77. RTP/AVP - The IETF real-time Transport Protocol using the Audio/Video profile carried over UDP. udp - User Datagram Protocol public void setFormat(String formats) To set the media format. Parameters: formats - String representing a format or a list of formats separated by space. For audio and video, this will normally be a media payload type as defined in the RTP Audio/Video Profile. A list indicates that all of these formats may be used in the session, but the first in the list is the default one. public void setConnectionInfo(String connectionInfo) Set the connection information specific to this media only. If the media stream is going to use the default connection address of the session, there is no need to specify this information. Parameters: A formatted String representing the connection information, "<network type> <address type> <address>". <network type> - This is a text string indicating the type of network. So far, "IN" is defined to have the meaning of "Internet". <address type> - This is a text string indicating the type of address. So far, IP4 and IP6 have been defined. <address> - This is the globally unique address of the machine from which the session was created. For an IP4 address type, it could be the fully qualified domain name of the machine, or the dotted-decimal representation of the IP version 4 address of the machine. Throws: InvalidConnectionInformationException - When the format of connectionInfo is incorrect. public void setMediaTitle(String title) To set the displaying title for the media. Parameters: title - A text string representing the title. public void setBandWidthInfo(String bandwidthInfo) AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 77 AC343 / Sie / WP2 / R / P / 02 / a1
  • 78. To set the proposed bandwidth to be used by this media. Refer to SDP for its format. Parameters: bandwidthInfo - Formatted String representing the proposed bandwidth. Refer to SDP for its format. public void setEncryptionKey(String method, byte[] key) To set the proposed encryption key to be used by this media. Refer to SDP for its format. Parameters: method - String representing the encryption method. Refer to SDP for details. byte[] - Byte string representing the actual encryption key. Throws: InvalidEncryptionKeyMethod - When an invalid encryption method is specified. public void addOtherAttributes(String key, String value) To set additional attributes for the media. This attribute will be appended as the "a=key:value" line in the media description. Parameters: key - String representing the key of the attribute. value - String representing the value for the respective key. public int getPort() To get the transport port to which the media stream will be sent. Returns: The integer port number. For transport based on UDP, the value should be in the range of 1024 to 65535. For RTP compliance, it should be an even number. Throws: NoPortInformationException - When port information is not present. public String getTransportProtocol() To get the transport protocol for the media. So far the following types have been defined: RTP/AVP - The IETF Realtime Transport Protocol using the Audio/Video profile carried over UDP. udp - User Datagram Protocol Page 78 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 79. Returns: String representing the transport protocol, i.e., "RTP/AVP" or "udp" or null. public String getFormat() To get the media format. Returns: The string representation of the format. For audio and video, this will normally be a media payload type as defined in the RTP Audio/Video Profile. A list of formats may be given, indicating that all of these formats may be used in the session, but the first of the list is the default one. null if no format is defined. public java.util.Properties getOtherAttributes() To get the additional attributes defined for the media. These attributes are appended as "a=key:value" lines in the media description. Returns: The java.util.Properties object that contains the list of additional attributes for this media. null is returned if no "a=.." header is in the media description or the session description. public String getConnectionInfo() Get the connection information of this media. Returns: The string representation of the connection information. If no connection information is specified in the media description of this media, the default connection information for the whole session will be returned. The returned string has the format "<network type> <address type> <address>" where <network type> - This is a text string indicating the type of network. So far, "IN" is defined to have the meaning of "Internet". <address type> - This is a text string indicating the type of address. So far, IP4 and IP6 have been defined. <address> - This is the globally unique address of the machine from which the session was created. For an IP4 address type, it could be the fully qualified domain name of the machine, or the dotted-decimal representation of the IP version 4 address of the machine. Throws: NoConnectionInformationException - No connection information is available, not even the default connection information for the whole session. public String getMediaTitle() To get the displaying title for the media. AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 79 AC343 / Sie / WP2 / R / P / 02 / a1
  • 80. Returns: A text string representing the title, null if title is not available. public String getBandWidthInfo() To get the proposed bandwidth to be used by this media. Refer to SDP for its format. Returns: Formatted string representing the proposed bandwidth. Refer to SDP for its format. null if "b=.." header is not in the media description or the session description. public java.util.Vector getEncryptionKey() To get the encryption key of this media. Returns: A java.util.Vector object that stores 1. a String representing the encryption method. 2. a byte[] representing the actual encryption key. null is returned if "k=.." header is not present in the media description or the session description. public String getGlobalSessionID() To get the GlobalSessionID in the media description. All the MediaDescriptions of an SDP message will share the same GlobalSessionID. Returns: The string representing GlobalSessionID, null if it is unknown yet. 13.3 Overview of the API (Internal interfaces) Call Manager modules interact with the following VE-MASE modules: • AudioGateway Client at MC The Call Manager module at the MC will invoke the Audio Gateway module to start or stop a VoIP connection. The Call Manager will need to acquire the following minimum information from the Audio Gateway module before it can initialise a call set-up to the external VoIP module:  IP 4 Address: If different from the default MC IP 4 address.  Port Number: If a fixed port is used.  Transport Protocol: RTP/AVP or udp. Page 80 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 81.  Media Format: To set the media format. For audio and video, this will normally be a media payload type as defined in the RTP Audio/Video Profile. A list of formats may be given, indicating that all of these formats may be used in the session, but the first of the list is the default one.  Bandwidth Information. The Call Manager will make use of the API provided by the Audio Gateway and Scheduler to acquire required information to start/stop a VoIP session. Call Manager will implement the required call back interface required by the MASE's Event Manager to listen to the events from the Audio Gateway and Scheduler module. The minimum events that are required by the Call Manager are: VoIP session start success. VoIP session start failed. current qos value = ? (This will be useful as the Terminal in JTAPI representing the Audio Gateway client may have committed to some minimum QoS level). Refer to Internal/External Interface of Audio Gateway and Scheduler. • Collaboration Manager at the MG Once the Call Manager Proxy module at the MG receives a "182, Queued" response from the V/D AS, if the SDP message for the IVDR module is available in the SIP Response message, the Call Manager will start the Collaboration Manager. Once the Call Manager received the "200, OK" response from the V/D AS, it will refresh the Collaboration Manager with the new session description which is corresponding to the V/D AC instead of the IVDR. Once the Call Manager receives a "BYE" SIP request from either end of the session, it will stop the Collaboration Manager. Thus, the Collaboration Manager will at least have to provide the necessary interface for the above three operations. Refer to the Internal/External Interface section of Chapter 7. • System Adaptability Manager (SAM) at the MG In section 13.4 the interface called by the System Adaptability Manager (SAM) is described. In turn, SAM interfaces used by the Call Manager Proxy are discussed in chapter 15. In addition, the Call Manager Proxy provides an interface CallManagerProxy in the ve_mase.callmanager package for the Collaboration Manager, the SAM and other modules in the MG, in order to query session information. In section 13.4, this interface is specified. AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 81 AC343 / Sie / WP2 / R / P / 02 / a1
  • 82. 13.4 Specification of the API public interface CallManagerProxy Introduction: This interface provides methods to access the Call Manager Proxy specific information. Methods: public java.util.Vector getActiveSessions() Get a list of currently active sessions. Returns: A vector object storing the globally unique globalSessionID (conference ID) of the active sessions maintained at the Call Manager Proxy. public java.util.Vector getSessionUsers(String globalSessionID) Get a list of users participating in the session. Parameters: globalSessionID - String representing the globally unique session ID. Returns: A vector object storing all the SDP objects for each user. public GlobalSessionID getGlobalSession( String UserID) Get the GlobalSession ID of a specific user. Parameters: UserID - String representing the user's ID . Returns: A GlobalSessionID variable storing the GlobalSession ID of the specific user. public Sdp getSession( String UserID) Get the Sdp object of a specific user. Parameters: UserID - String representing the user's ID . Returns: A Sdp object storing the session description of the specific user. Page 82 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 83. 13.4.1Use of VE-MASE classes by the Call Manager This subsection discusses the use of the VE-MASE classes ve_mase.CallManager.Sdp.class and ve_mase.CallManager.MediaDescription.class by the Call Manager. These two classes in the ve_mase.CallManager package are intended to be used as parameters that are passed within the Call Manager module, as well as between the internal interface of the Call Manager module and other modules in the VE-MASE, and also between the external interface of the VE-MASE and the application layer. Sdp.class: The SDP class Sdp.class is supposed to represent a session description that includes all the possible headers and fields as described in the IETF RFC 2327 [HJ98], SDP (Session Description Protocol). SDP is purely a format for session description which is designed to convey conference set-up information to recipients. It should be noticed that it does not incorporate any transport protocol, and that it is intended to use different transport protocols as appropriate, including the Session Announcement Protocol (SAP), the Session Initiation Protocol (SIP), the Real-Time Streaming Protocol (RTSP), electronic mail using the MIME extensions, and the Hypertext Transport Protocol (HTTP). A session description consists of a session-level description (details that apply to the whole session and all media streams) and optionally several media-level description (details that apply onto a single media stream), which is represented by MediaDescripion.class in the ve_mase.CallManager package. Below, an example of an ITU H.332 SDP message is displayed. c = IN IP4 224.5.6.7 // session description a = type:H332 // session description m = audio 49230 RTP/AVP 0 // media description for audio stream m = video 49232 RTP/AVP 31 // media description for video stream m = application 12349 udp wb // media description for white board application m = control 49234 H323 mc // media description for H323 control channel c = IN IP4 134.134.157.81 // media description for audio stream MediaDescription.class The class MediaDescription.class is supposed to represent the session description dedicated to some particular medium, e.g., audio. In general, media can be of virtually any kind in the spectrum of the multimedia world. In SDP, a medium could be a real-time stream like audio, it could also be an application like web collaboration. MediaDescription Java class intends to include most of the important headers specified in the SDP to describe a medium. One important feature of SDP is that it allows additional types of session or media attributes to be defined easily. It allows one or more a = key:value headers to be added after the session description and each media description. In the VE-MASE context, this could be used to describe additional QoS attributes. In fact, a key (key=quality) has already been suggested for indicating the general QoS setting of the session, as described in page 26 of RFC 2327 [HJ98]. AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 83 AC343 / Sie / WP2 / R / P / 02 / a1
  • 84. 14 COLLABORATION MANAGER API The purpose of this chapter is to present the external API needed by the Collaboration Manager to work properly, and the API offered by the Collaboration Manager to be driven by an application 14.1 Overview of the API The Collaboration Manager mainly interacts with the Call Manager Proxy (CMP) on the Mobility Gateway. This component provides the Collaboration Manager with information about the current conferences and their respective users. Therefore, this chapter first presents the API needed in the Call Manager Proxy so that the Collaboration Manager can retrieve this information. Since the Collaboration Manager will need that information very often, this API may be sufficient if the implementation is efficient. Otherwise, if a delay is imposed on each call to these functions, we need to store this information redundantly in the Collaboration Manager. In that case, we need an API so that the CMP can alert the Collaboration Manager when a change occurs. This API is presented in 14.2.1. • The Collaboration Manager has to be able to obtain information about conferences whenever it needs them. To satisfy this requirement, there are in principle two solutions: Retrieve them on demand from the Call Manager Proxy. This is the best solution if the latter answers sufficiently quick. If not, another mechanism is required. • Replicate the information (users, conferences etc...) in the Collaboration Manager and provide the Call Manager Proxy with an API so that it can alert the Collaboration Manager when a change occurs. Then the data is maintained inside the Collaboration Manager so that it is available and up- to-date when needed. This solution is presented in 14.2.2. 14.2 Specification of the API Since the API will be implemented in Java, it is presented already in this format. 14.2.1API for the Call Manager Proxy The Collaboration Manager uses the API specified in Chapter 13. 14.2.2API for the Collaboration Manager This API is needed only if the usage of the previous API is inefficient and the information has to be stored redundantly in the Collaboration Server. The following functions will then be called by the Call Manager Proxy each time a change occurs in the conferences. Page 84 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 85. Package ve_mase.collabmanager public class CollManager { void NewConf(String ConfID) /* Informs the Collaboration Manager that a new conference has started */ void AddUser(String ConfID, String NewIP) /* Adds the user specified by its IP address in the specified conference */ void UserLeavesConf(String ConfID, String UserIP) /* Deletes the specified user from the specified conference */ void EndConf(String ConfID) /* Finishes the specified Conference. All users automatically leave the conference. */ } 14.2.3API for driving the collaboration Manager The Collaboration Manager is an independent module, allowing n users to exchange data through a collaborative web browsing session. From an application point of view, being able to drive such a conference by sending data to all the users of a conference, or to a specified user, is an important aspect. This can be done through the following protocol. The first step is of course to open a socket to the machine that hosts the Collaboration server (i.e., in principle, the Mobility Gateway).Then, those commands are available: SUPERREG NameOfConf This command allows registering as a super user in the specified conference; all the following commands will concern this conference. URL http://www.xyz.net This command dispatches this URL to all the users that are inside the conference. When this is done and all the users have received the page , the sender is informed through the command ALL_OK. SUPERUNREG This command allows unregistering from the current conference. SUPERSEND http://www.xyz.net TOCONF ConfName AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 85 AC343 / Sie / WP2 / R / P / 02 / a1
  • 86. This command allows sending a single page to a conference without having to register for it. An ALL_OK message is sent back when all the users have notified for the good reception of the document. SUPERSEND http://www.xyz.net TOUSER 192.25.42.156 This command allows to send a single page to a user, whatever his current conference is. An ALL_OK message is sent back after good reception. Through this API, an application can drive a conference, and send pages to users inside any conference. This may allow for example a service provider to send a list of available services to connected users, or to inform him of the availability of new services. Page 86 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 87. 15 SYSTEM ADAPTABILITY MANAGER (SAM) API The purpose of the SAM API is to provide function calls to be used by the Call Manager Proxy, in order to support the monitoring of the maintenance of previously specified QoS parameters. We point out that, in the MOVE context, the SAM is an extension of a namesake component in OnTheMove. In particular, QoS trading on a per-stream basis (as in OnTheMove) is not sufficient in the VE-MASE scenario. The function of the extension of the System Adaptability Manager (SAM) is to perform Quality of Service (QoS) trading for the complete transmission medium (e.g., voice and data), i.e. by co-ordinating per-stream QoS trading. 15.1 Overview of the API This section describes the interface between the Call Manager Proxy and the SAM. More precisely, only SAM methods called by the Call Manager Proxy are discussed. In turn, Call Manager Proxy methods called by the SAM are discussed in chapter 13. However, the method changeSession, as specified in 15.2, may be used in both directions, i.e., on one side it may serve as an indication about a change in the session from the Call Manager Proxy to the SAM, and, on the other hand, the SAM may also query such changes from the Call Manager Proxy. 15.2 Specification of the API As already indicated earlier on, there are no external interfaces of the SAM. Package ve_mase.SAM public class ConferenceTrade { public void newSession(Sdp mc, Sdp agent, boolean autoStart) Purpose: Indicate that a new session is created. Parameters: mc - The session description of the wireless mobile client. The SAM will retrieve the QoS attributes from this parameter. agent - The session description of the wired agent. autoStart - If true, start the session monitoring immediately without the need for a separate startSession(String globalSessionID) command. public void changeSession(Sdp mc, Sdp agent, boolean autoStart) Purpose: Indicate a change in the session description. AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 87 AC343 / Sie / WP2 / R / P / 02 / a1
  • 88. Parameters: mc - The session description of the wireless mobile client. The QoS Manager will retrieve the QoS attributes from this parameter. agent - The session description of the wired agent. autoStart - If true, start the session monitoring immediately without the need for a separate startSession(String globalSessionID) command. public void startSession(String globalSessionID) Purpose: Start monitoring of a session immediately. Parameters: globalSessionID - A globally unique ID to represent a session as described in the SDP. Throws: InvalidSessionIDException - Unknown globalSessionID. public void stopSession(String sessionID) Purpose: Stop monitoring of a session immediately. Parameters: globalSessionID - A globally unique ID to represent a session as described in the SDP. Throws: InvalidSessionIDException - Unknown globalSessionID. public void stopAllSessions() Purpose: Stop monitoring all sessions. } Page 88 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 89. 16 HOW TO USE THE V/D API FOR VOICE/DATA INTEGRATION SERVICES This chapter discusses the usage of the Call Manager (chapters 6, 13), the Collaboration Manager (chapters 7, 14) and standard technology for voice/data integration in advanced applications. Its structure does not conform to previous chapters in part II of this document, since applications, which use the VE-MASE, are not conceived as VE-MASE components. The basic idea of enabling an application to make use of VE-MASE functionalities in order to provide advanced services is to rely entirely on existing standard internet technology (e.g., collaborative web browsing) and to use functionality provided by the Call Manager, the Collaboration Manager and the SAM. 16.1 Principles of using voice/data integration for extended services In this section, we briefly mention some basic principles, which guide the usage of the VE-MASE Voice/Data API for voice/data-integrated services, from the Mobile Client's point of view. HTML pages needed for an application are located either on the Information Server, the V/D AS or on any web server. In the latter case, some additional security measures will have to be taken in order to provide authenticity and integrity of the content and its secure transmission. Less severe security measurements are needed if the Information Server and the V/D AS are located in a private Intranet. The Mobile Client is supposed to access VE-MASE functionality via a Java/JavaScript-based VE- MASE manager module. The basic approach to voice/data integration for extended services may either be more server- centric, more client-centric, or more gateway-centric. For simplicity, the latter case can be subsumed under the server-centric case. More precisely, profile information, subscription details and, most importantly, content for executing various application functions can be located either on the Mobile Client, the V/D Application Server or the Mobility Gateway. A client-centric approach is particularly useful for time-critical services. The continuing increase of available storage on small devices will render such client-centric solutions more and more feasible. On the other hand, in a server-centric approach, personal service HTML pages may need to be manipulated by the application and therefore may have to reside on the server. HTML pages have then to be downloaded by the Mobile Client with URLs, which are known or sent to the client. Additional measures for maintaining the consistency of HTML pages may have to be taken in the server-centric approach. Of course, hybrid forms of client- and server-centric approaches are conceivable. 16.2 A generic process scenario for using extended voice/data services A voice/data session can be initiated either by the client (who, e.g., presses the hotel service button, or requests to check voice mail), or by an external service provider (who, e.g., indicates that new voice mail messages have arrived, or that the technology stock market has crashed). However, it is possible AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 89 AC343 / Sie / WP2 / R / P / 02 / a1
  • 90. to use existing functionality of the Call Manager and the Collaboration Manager to cater for both kinds of situations. The numbering in the following list of steps of a generic kind of session reflects a typical sequence of function calls. For convenience, the functions are loosely denoted in procedural language style syntax. For each of them, we indicate by which of the existing APIs they can be realised. The function parameters are not explained separately since the mnemonics of their names speaks for themselves. (1) establishGSMconnection(string tel_nr) Independent of who starts a voice/data session, a data connection over GSM needs to be established at the beginning of a session. This function can be realised by using appropriate Windows NT or operating system calls. (2) startSession(string IPaddress, string profile) The session is started via SIP. For more details, see chapter 6. This function can be realised by using the Call Manager API. (3) indicateService(string serviceID, string IPaddress) The client is offered a service (which she might herself have requested, e.g., hotel search, banking, voice mail, etc). This function can be realised by using of Collaboration Manager API. (4) acknowledgeReceipt(string serviceID, string IPaddress, boolean Yes_No) In case the server has initiated the session, MC is asked to acknowledge the receipt, and also to request continuation or termination or delay of the offered service. In other words, the client acknowledges receipt of the service offer and requests (Yes) or rejects (No) to start the service. This function can be realised by HTTP and cgi script mechanisms or by downloading URLs, using the Collaboration Manager API. (5) sendMmenu(string IPaddress, string menuURL) If the client’s acknowledgement requests the start of the actual service, then the V/D AS sends an URL to the client with which a service menu can be downloaded. That menu may reside either on the V/D AS (who then has received that menu in conjunction with an initial external event originating from some service provider), or on some external server (e.g., the service provider itself, or some other information server), or even on the client itself. The latter option this is particularly interesting for time-critical applications. Depending on the location of the content pointed to by the URL, it may be necessary to have additional access control, for security reasons. This function can be realised by using of Collaboration Manager functionality. Page 90 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 91. (6) establishCall() As soon as voice communication between the service and the client is needed to start or continue the session, a VoIP connection between client and service provider, hosted by V/D AS, is started by V/D AS. In case the service is initiated by the client, that can be realised by Java applets or JavaScript code inside of an HTML page, by which the Call Manager is accessed. This function can be realised by using the Call Manager API. (7) terminateSession(string IPaddressMC, string IPaddressVDAS) Session is properly terminated. This function can be realised by using the Call Manager API. Obviously, steps (1), (3), (4), (5) above are concerned with the transmission of data, while step (6) also involves voice transmission over IP. In general, step (5) can be recursively iterated in the following manner. In (5), the client receives a URL that points to a service menu. After the client has downloaded the menu, the choice of a menu option may lead to offers of various subservices and downloads of further submenus. Only when a bottom element of the menu hierarchy is reached, step (6) will be taken. An outer iteration loop which incorporates the inner loop of step (5) just sketched involves the indication of the possible continuation (or termination) of the service with further submenus, by going back to step (3) after (6) is terminated. As an example for a session that runs through steps (1) to (6), we consider a multimedia mail service. To get right into the heart of the matter, we suppose that steps (1) and (2) have already been accomplished, i.e., the mail service has notified the V/D AS that there are new mail messages for a specified client. The V/D AS then indicates a corresponding service offer to the client (step 3), who accepts that the service is going to be started (step 4). Then, a URL to download a top-level service menu is sent to the client (step 5). That menu may offer to check the new mailbox entries, or to delete or move the new messages to some directory, or to check only entries of a certain format (e.g., with our without attachments) or of a certain provenance (e.g., only from the US) or type (e.g., senders with .com or .edu extensions), or to revisit older messages. Say, the client chooses to check the most new unseen messages. Then, a URL will be sent to the client with which she can download a list of headings of those messages, with a menu to (partially) display, delete or move any of them (step 5 again). The client chooses to see or listen to, say, the first of the new messages (and skip the rest), for which a voice connection needs to be established (step 6). After that is finished, the client can be offered to continue or stop the service (step 3 again). If the client wants to continue, she reacts positively (step 4), and then will be provided with another URL for downloading a menu for continuing the session (step 5 again). If the client wants to stop, then the session is terminated (step 7). The comments to the following figure summarise the seven steps sketched above. AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 91 AC343 / Sie / WP2 / R / P / 02 / a1
  • 92. V/D Integration Services 1) establishGSMconnection(tel_nr) Services => Windows NT or operating system call 2) startSession(IPaddress, profile) => Call Manager API Voice/Data AS 3) indicateService(serviceID, IPaddress) => Collaboration Manager API 4) acknowledge(serviceID, IPaddress, Yes_No) V/D API => Collaboration Manager API 5) sendMenu(IPaddress, menuURL) => Collaboration Manager API 6) establishCall() => Call Manager API 7) closeSession(IPaddrClient, IPaddrServer) => Call Manager API Collaboration Call Manager Manager Figure 16.1: V/D API for generic voice/data integration services 16.3 A possible technique to use the Voice/Data API This section sketches a possible technique for using the VE-MASE voice/data API for extended voice/data integration services on the Mobile Client. The basic idea is to use dedicated code inside of a HTML page containing Java Applets or JavaScript calls which call the appropriate managers. Figure 16.2 illustrates this approach from the point of view of the Mobile Client, figure 16.3 from the V/D AS point of view. Page 92 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 93. HTML page local JavaScript on MC Profile Location Collabor. Call Java Manager Manager Mgr Applet Mgr Classes VE - MASE / MASE Figure 16.2: V/D API Integration on Mobile Client Application Service local on Java V/D AS or remote Call Event Collabor. Mgr Manager ... Java Client Mgr Classes VE - MASE / MASE Figure 16.3: Voice/Data Integration on V/D Application Server AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 93 AC343 / Sie / WP2 / R / P / 02 / a1
  • 94. 17 REFERENCES [Ber98] Y. Bernett: „A Framework for Use of RSVP with Diff-serv Networks“, Internet Draft, June 1998. [Ca98] D. Carrega: Improved Scenario for MOVE Demonstrator, May 1998. http://move.rwth-aachen.de [CORBA] Common Object Request Broker: Architecture and Specification, document revision 2.1, 23 September 1997, ftp://ftp.omg.org/pub/docs/formal/97-09-01.pdf [CFM98] D. Carrega, E. Fournier, H. Muyal: „Requirements for VE-MASE and V/D-API“, Deliverable W1D1, ACTS MOVE, July 1998. http://move.rwth-aachen.de [Cox97] R. V. Cox: „Three Speech Coders from the ITU Cover a Range of Applications“, IEEE Communications Magazine, November 1997. [CSZ92] D. Clark, S. Schenker, L. Zhang: „Supporting Real-Time Applications in An Integrate services packet network: Architecture and Mechanism", Proc. SIGCOMM'92, 1992. [CT90] D. D. Clark and D. L. Tennenhouse: "Architectural considerations for a new generation of protocols" in SIGCOMM Symposium on Communications Architectures and Protocols , (Philadelphia, Pennsylvania), pp. 200--208, IEEE, Sept. 1990. Computer Communications Review, Vol. 20(4), Sept. 1990. [FER90] D. Ferrari, D. C. Verma: „A Scheme for real-time channel establishment in Wide area networks“, IEEE Journal on Selected Areas of Communications, Vol 8. pp. 368-379, 1990. [FJ95] S. Floyd, V. Jacobson: „Link Sharing and Resource Management for Packet Networks“, IEEE/ACM Transactions on Networking, Vol. 3 No. 4, August 1995. [Hall97] M. Hall: „Windows Sockets 2 Application Programming Interface: An Interface for Transparent Network Programming Under Microsoft Windows, Revision 2.2.2“, Stardust Technologies, August 1997. [HJ98] M. Handley, V. Jacobson, „SDP: Session Description Protocol“, IETF Request For Comments 2327, April 1998. [HSSR98] Handley, Schulzrinne, Schooler, Rosenberg, “SIP: Session Initiation Protocol”, IETF Internet Draft ietf-mmusic-sip-10.txt, November 1998. [ITU] ITU-T Recommendation, Series G, http://info.itu.ch/itudoc/itu-t/rec/g.html, 1998. [ITU2] ITU-T H-Series Recommendations: Audiovisual and Multimedia Systems H.323 Version 2 - Packet based multimedia communications systems. Page 94 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 95. [JTAPI] The Source for Java Technology, http://java.sun.com/products/jtapi/, Febr. 1998. [Kre+98] B. Kreller, A. Park, J. Meggers, G. Forsgren, E. Kovacs, M. Rosinus: „UMTS: A Middleware Architecture and mobile API Approach“, IEEE Personal Communications Magazine, April 1998. [MSP97] J. Meggers, T. Strang, A. Park: „A Video Gateway to Support Video Streaming to Mobile Clients “, ACTS Mobile Communication Summit, Aalborg, October 1997. [OTM] http://www.sics.se/docs/~onthemove, link Publications. D09 - Preliminary Requirements for Mobile-API D13 - Specification of the Mobile-API for MASE V1.0 D17 - Design of MASE V1.0 D20 - Revised Requirements for Mobile-API D26 - Initial architecture of the MASE V2.0 D27 - Initial services and Mobile-API specification of the MASE V2.0 D28 - Specification of the Mobile-API for MASE V2.0 D33 - Design of MASE V2.0 D46 - Final architecture, services and Mobile-API specification of the MASE [Per+97] C. Perkins, et al: „RTP Payload for Redundant Audio Data“, IETF Request For Comments 2198, September 1997. [Ro98] Jonathan Rosenberg: Slides on Gateway Location Framework Open Issues, presented at the 42nd IETF, August 1998. http://www.cs.columbia.edu/~jdrosen/papers/ietf_iptel_aug98.ppt [Sch96a] H. Schulzrinne et. al, “RTP: A Transport Protocol for Real-Time Applications“, IETF Request For Comments 1889, January, 1996. [Sch96b] H. Schulzrinne, “RTP Profile for Audio and Video Conferences with Minimal Control”, IETF Request For Comments 1890, January 1996. [Sch98] H. Schulzrinne and J. Rosenberg, “A Comparison of SIP and H.323 for Internet Telephony”, Network and Operating System Support for Digital Audio and Video (NOSSDAV), (Cambridge, England), July 1998. http://www.cs.columbia.edu/~hgs/ papers/Schu9807_Comparison.pdf [TIP] ETSI Seminar, Project TIPHON, WG 5, http://www.etsi.fr/tiphon/, end to end quality of service aspects, ETSI Seminar tiphon.ppt and IP-Tel-ETO by R.Stasny.ppt, http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/96- presentations [WAP] Wireless Telephony Application Specification (WTA), Draft, April 1998. Specification (WTA), Draft, April 1998. http://www.wapforum.org/docs/technical.htm [Wro97] J. Wroclawski: „ The Use of RSVP with IETF Integrated Services“, Request for Comments 2210, September 1997. AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 95 AC343 / Sie / WP2 / R / P / 02 / a1
  • 96. 18 ABBREVIATIONS Several abbreviations and acronyms are used in this document. Expansions are provided below. API Application Programming Interface CM Communication Manager DECT Digitally Enhanced Cordless Telephony GSL General Support Layer GSM Global System for Mobile communications ITU International Telecommunications Union MASE Mobile Application Support Environment VE-MASE Voice-Enabled MASE MD Mobile Device MG Mobility Gateway MU MASE User PC Personal Computer PCMCIA Personal Computer Memory Card International Association - now PC-Card PDA Personal Digital Assistant QoS Quality of Service RTP Real-time Transport Protocol SAM System Adaptability Manager SDP Session Description Protocol SIP Session Initiation Protocol TCP Transport Control Protocol UDP User Datagram Protocol UMTS Universal Mobile Telecommunication System VoIP Voice over IP WPi MOVE workpackage i, i = 1, 2, 3. WWW World Wide Web Page 96 Design of V/D-API and Architecture of the VE-MASE AC343 MOVE Deliverable D2 AC343 / Sie / WP2 / R / P / 02 / a1
  • 97. AC343 MOVE Deliverable D2 Design of V/D-API and Architecture of the VE-MASE Page 97 AC343 / Sie / WP2 / R / P / 02 / a1