Project Number:                                        AC343

Project Title:                                         MOVE
...
HISTORY OF THIS DOCUMENT

        Date         Version                        Status
    July 07, 1998   D2_01.DOC        ...
Table of Content

1 EXECUTIVE SUMMARY .......................................................................................
6.3 INTERNAL INTERFACES......................................................................................................
13.1 OVERVIEW OF THE API (EXTERNAL INTERFACES)...............................................................................
1        EXECUTIVE SUMMARY
   The Deliverable D2 ‘Design of V/D-API and Architecture of the VE-MASE’, prepared by
Workpack...
•     The Call Manager is part of the distributed VE-MASE architecture and is responsible for the
          set-up and the...
2        INTRODUCTION
   This Deliverable provides a high level specification of the architecture of the VE-MASE and the V...
PART I: THE ARCHITECTURE

3                    THE VE-MASE OVERALL ARCHITECTURE


                     3.1   Physical View...
The following figure shows the software architecture of the MOVE architecture.




                                       ...
3.1.1 The Mobile Client (MC)
   The mobile client (MC) is used by a mobile user to access the voice/data services. It shou...
3.2     Functional View


   Application
                         Mobile          Location-aware                Call Centr...
The VE-MASE components Audio Gateway, Scheduler, Call Manager, Collaboration Manager and
System Adaptability Manager are d...
4         AUDIO GATEWAY
   The Audio Gateway is a central component of the VE-MASE since it provides for real-time audio
c...
S ta tio n a r y
                                                                  T e r m in a l




                    ...
To achieve wide acceptance within the user community and in order to allow for simple
implementation by reuse of existing ...
stating, e.g., bit rate and frames per second. According to the network conditions the selector will
choose channel and me...
constantly require additional bandwidth, ARQ (automatic repeat request) schemes add additional delay.
The choice of applic...
Application Server in the context of H.323 usage and the new ITU standard H.450 is beyond the scope
of the MOVE project.

...
Gatekeeper Cloud
          1    ARQ
          2    ACF/ARJ
          3    Setup
          4    Setup                      ...
SIP for conference setup


                 MC                                                       MG
                  ...
•   UAL – UMTS Adaptation Layer (OnTheMove)
    The UAL offers a uniform API to transport services provided by different a...
5          SCHEDULER

    Mobile users demand different kinds of data to be serviced, which are generated by interactive a...
5.1    Functional Specification

   The Audio Gateway and other VE-MASE components such as the HTTP Proxy make use of the
...
5.1.1 The VE-MASE Scheduler
                                                                                             F...
5.3   Internal Interfaces

   The Scheduler provides several services to other parts of the VE-MASE that allow the set-up,...
6          CALL MANAGER

           6.1        Functional Specification (Services)
   The Call Manager is the component of...
•   Requirement MOVE/R/20: The initiation of the voice session should be fast after the Mobile
    User asks for it.
    -...
♦ User agent server (UAS): A user agent server is a server application that contacts the user when
       a SIP request is...
Mobility Gateway (MG)
                                                                           Information Server (V/D A...
6.1.5 Operation

Session Initiation (typical sequence of events):

Refer to figure 6.3: Message Sequence Chart of Session ...
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...
6.2        External interfaces
   The Call Manager needs to provide a minimum external interface for an application to beg...
7         COLLABORATION MANAGER

   We presuppose a scenario that conforms to the proposal of the VE-MASE Distributed Arch...
Several degrees of granularity and fine-tuning can be imagined, concerning the amount of
synchronised attributes of shared...
A disadvantage of the alternative approach mentioned above is that decentralised notification and
HTTP dispatching would i...
of the particular browser tool which supports collaboration. A description of the flow of requests and
messages after an i...
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
D2
Upcoming SlideShare
Loading in...5
×

D2

790

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
790
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

D2

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×