Integration of Commercial Internet Applications in a TINA Environment
Gianni Canal
Intelligent Network Dept., CSELT, Torino, Italy, gianni.canal@cselt.it
Patricia Lago
Dept. of Control and Computer Engineering, Politecnico di Torino, Torino, Italy, patricia.lago@polito.it
Abstract-Services on the Internet rely on Internet applications, that is software applications distributed between clients and an Internet server relying on IP-based communication. This work* demonstrates that they can benefit from the TINA session concept, and especially from the service session.
In detail, our objective was to study both the impact on, and the applicability of the TINA standard, whenever commercial applications are reengineered as TINA services.
To achieve this objective, the work described here integrates two commercial conferencing applications in a TINA compliant telecom framework, and it extends the applications features to support distance education and traditional conference sessions in a flexible and intuitive way.
This paper describes the solution implemented by the authors by showing its overall architecture, and the internal composition of each service component. For each of them, the internal behavior is mapped on a common example scenario.
Also, the paper points out the problems encountered and the results achieved, by focusing especially on the enhancements brought by the integrated TINA/Internet solution, and on the benefits added by TINA.
Some topics for further work are also discussed.
I. I
NTRODUCTIONHere some background information provides context for the work, i.e. our integrated TINA/Internet service (named TINA NetMeeting). Section A presents TINA, the TINA session model, and service components. Section B gives an overview of the commercial applications integrated into TINA NetMeeting, namely Microsoft NetMeeting and WhitePine MeetingPoint.
A. TINA
TINA (Telecommunications Information Networking Architecture) has been under development at the TINA Consortium (TINA-C, [2][7]) core team since 1993, and final specifications have been released at the end of 1997 [1]. The TINA Service Architecture (TINA SA) can be defined as a software architecture for global telecommunication and information services.
TINA defines the concept of "TINA session" [5] that logically maps service provisioning on a well-defined time framework. As sketched out in the example of Fig. 1, the TINA session model defines three main sessions. All activities carried out between consumers and providers (e.g. authentication, service provisioning authorization,
*
This work has been carried out in the context of the ACTS VITAL (Validation of Integrated Telecommunication Architectures for the Long-Term) Project.
subscription, etc.) take place in the context of an access session. The service session represents service provisioning and usage: each user can participate in multiple service sessions, and a single service session relates all interacting consumers. At last, whenever network resources are to be dedicated to a certain service session, the communication session is settled down to allocate resources and handle associated Quality of Service.
Consumer domain Provider domain Consumer domain
Access Session (AS) Access Session (AS)
Service Session (AS)
Communication Session (CS)
Fig. 1. The TINA Session Model
From the time perspective, each Consumer needs to first open an access session by a certain provider to be able to start service sessions afterwards, and should a service need network resources, a communication session is then created.
The TINA session model is the ideal environment to integrate Internet service applications with other telecom services. In detail, the TINA access and service sessions are the enabling factor for integrating Internet applications with traditional telecom service applications.
asUAP USM CSM ssUAP TCSM PA IA UA SF
Consumer domain Retailer domain Consumer domain
Access related Usage related Communication related IA UA SSM USM asUAP TCSM PA ssUAP
establish establish establish istantiation
This work concerns the service session, only. In fact, the TINA NetMeeting service is provided by a certain provider, to a group of potential consumers interacting in a common videoconference service session. Further, the communication session is not explicitly represented in an information model: the provider controls the audio- and video- information exchanged among session participants over IP, without any resource allocation.
From a computational perspective, Fig. 2 shows a generic TINA SA example of Retailer service provisioning between two consumers involved in a common service session. In the TINA NetMeeting service, the service components involved in a service session are the grayed ones. I.e. the Service Factory (SF) is in charge of instantiating service session components according to current parameters. The Service Session Manager (SSM) controls and coordinates the service-specific logic in the Retailer domain. The service session related User Application (ssUAP) in the Consumer domain permits consumers to interact with the service session. An additional component (not depicted in the Figure) is the Service Support Object (SSO) that is used by the SSM to control special resources for the particular service. In our case (see Fig. 4) the TINA NetMeeting service uses the InteRA component to control the commercial Internet conference server. Differently from the figure, TINA NetMeeting does not implement any USM component, because it does not need to manage any user-specific service session information in the Provider domain [5].
The TINA session concepts used and/or specialized for the TINA NetMeeting service, are highlighted in Fig. 3 that represents the information part of the TINA service session graph [3].
Service Session Graph
Party Resource
Stream Interface StreamFlowEndPoint
{}Control SR Ownership SR {}Session Relationship
Stream Binding SR {}Comp SR Peer {}Session Member {}Permission SR 1+ participate_in participate_in association aggregation zero or more one or more 1+ Read Per.SR Write Per.SR
Fig. 3. Service Session Graph Information Model To support the service logic handling, the SSM maintains a service session graph in terms of both service-common information (represented by a Common Session Graph) and service-specific information (represented in TINA NetMeeting by a Conference Graph).
The Conference Graph specializes the concept of Party (on the left side of the Figure) by introducing two new party roles, Conductor and Participant. The Conductor is the party who created the session and who has an ownership relationship (Ownership SR) arc with the session in the session graph. The Participant is each party that joins an existing conference session. Hence, the Conference Graph is described in terms of
a set of Participants, a Conductor, and audio/video stream flows between them (specialization of the Stream Binding SR).
The role played by each party assigns special permissions during the conference. In fact, according to the role, a party can (or cannot) do certain operations.
For instance, audio and video flows are defined between parties according to the type of the conference, which is decided by the Conductor (i.e. Point-to-MultiPoint uni- or bi-directional, from the Conductor toward the Participants1, or MultiPoint-to-MultiPoint). The Conductor can also change the conference topology, e.g. by enabling or disabling audio or video flows for certain parties. On their own, also the Participants can modify the conference topology, but the modification request must always be accepted by the Conductor, too (being the Conductor the session owner).
Therefore, the specialization of the Party into two specific roles represents the semantics associated with lecturer and students in the distance education domain.
B. The commercial Applications
The TINA NetMeeting service developed in the work here reported integrates and enhances two commercial applications, Microsoft NetMeeting and WhitePine MeetingPoint. These applications provide typical audio/video conferencing capabilities based on the ITU H.323 protocol [6].
Microsoft NetMeeting is an end-user audio and video conferencing application [9] providing a Software Development Kit (SDK) that enables developers to integrate NetMeeting core functionality.
It allows easy to use features, but it has some drawbacks, e.g. it uses IP addresses to identify end-users, and it supports only two-party communication. Therefore, to extend conferencing features to multi-party sessions, the TINA NetMeeting service integrates a commercial Internet Conference Server (also named MCU, Multi-point Control Unit), that is WhitePine’s MeetingPoint™ V3.0 [8]. It permits overall conference configuration and monitoring, and management of external access. Further, it allows three alternative configuration methods: via a Web graphical interface accessible on an HTTP address, by directly editing the MCU configuration files, or by issuing proprietary Telnet commands.
In general, the TINA NetMeeting service supports each Consumer in starting or joining a conference session in an easy way (e.g. by only knowing that a lecture titled "Distributed Systems II" is being carried out somewhere). Further, it allows Consumers to play a specific role (i.e. a Participant/Student or a Conductor/Lecturer), and to interact with an intuitive graphical user interface that permits to non-technical end-users to actively interact with the session.
In particular, Section II gives first an overview of the overall architecture of the TINA NetMeeting service and presents an example scenario of overall functionality. It then describes in details all TINA NetMeeting service components
1 In TINA NetMeeting, a Point-to-MultiPoint conference models a Lecture
in which the Conductor acts as the Lecturer. Further, if audio/video flows are bi-directional, the Participants (who play the role of the Students) can interact with the Lecturer.
in both the Consumer and the Retailer domain: for each component, the example scenario is used to show how the functionality is executed internally.
Section III highlights technological problems encountered in the integration of the commercial applications. At last, Section IV explains the value added by TINA to the stand-alone commercial applications, whereas Section V presents some conclusions, and topics for further work.
II.
A
NI
NTEGRATEDI
NTERNET/TINA
SERVICE The TINA NetMeeting architecture can be represented on three classification levels (see Fig. 4): the upper level identifies the Internet Commercial Applications, the medium one represents the Service Specific Layer whilst the lower represents the Service Common Layer which supports the Access and the Service Session components.The Internet Commercial Application Layer comprises the existing commercial applications that have been chosen to be integrated in the TINA SA to implement a TINA video conference service based on commercial applications: Microsoft NetMeeting and WhitePine MeetingPoint.
The Service Common Layer provides the common features to establish and manage the Access and Service Sessions in the Retailer domain.
Consumer Consumer Retailer Telnet Internet Commercial Application Layer Service Specific Layer Service Common Layer IP flow NetMeeting Multi-point Control Unit H323 H323 ssUAP ssUAP NetMeeting Meeting Point IP flow PA PA UA SF InteRA SSM UA GSS GSC
Fig. 4. The TINA NetMeeting architectural components The Service Specific Layer is the glue between these two layers. It is in charge of performing the service logic, to control the service and to maintain the Conference Graph.
The service logic maintains the consistency between the service-specific data stored in the Conference Graph and the information stored in the Common Session Graph in the GSC (Global Session Control, [3]). The service logic relies on the Service Common Layer to exploit all the common features like inviting a new participant, deleting a participant, announcing a session, requesting to join an announced session.
The SSM has a service-specific part called Global Service Segment (GSS, [3]) that supports these service-specific capabilities that are shared among participants in the service session.
The ssUAP is in charge of both controlling Microsoft NetMeeting, and managing its life cycle by interacting with the SSM in the Retailer domain. The ssUAP activates Microsoft NetMeeting to interact with the MCU via the H.323 protocol.
The GSS manages the MCU via the Internet Resource Adapter (InteRA) SSO that controls Internet access to the
service session for H.323 clients and MCUs. It authorizes the access to the H.323 conference by receiving from the GSS the invocations that depend on the service-specific logic, and by configuring the MCU accordingly.
To give a flavor of the overall behavior of the TINA NetMeeting service, the following gives an Example Scenario in which a user (playing the role of the Conductor) invites a second user in an existing conference session. In TINA NetMeeting, each party is offered with the core2 Graphical User Interface (GUI) depicted in Fig. 5. As introduced in Section A, according to the role played and the semantics associated with the conference type, the GUI presents functionality's either enabled or disabled. For instance, the GUI presented in the Figure is the one of the Conductor, as only the Conductor can decide to accept or deny a join request from a remote user (see lower part of the GUI).
The Example Scenario supposes that:
1) the Conductor invites Fabrizio (selected from the Address Book) with the message "Would U like to join?")
2) Fabrizio then requests to join the session,
3) the Conductor (presented with the possibility of accepting or rejecting Fabrizio's request) accepts the join.
Fig. 5. The TINA NetMeeting core GUI during a join If we map this Example Scenario on the TINA NetMeeting architectural components of Fig. 4, the scenario is accomplished by the following steps:
1) the Conductor invites Fabrizio:
a) the ssUAP of the Conductor sends the invitation to the GSS;
b) the GSS checks if the invitee is the Conductor;
2
For sake of simplicity, the Figure shows the "core" GUI, only. In reality, it is accompanied by: two windows showing the transmitted and received video, a Toolbar to configure the conference (opened by clicking on button
Modify), and a window that shows the graphical representation of the Conference Graph opened by clicking on button Show (see Fig. 9).
c) the GSS forwards the invitation to the GSC that contacts Fabrizio;
2) Fabrizio requests to join in the session: a) the request is invoked on the GSC;
b) the GSC forwards the request to the session Owner (the Conductor in the Conference Graph) to decide about request acceptance or deny, i.e. the request is passed to the GSS;
c) the GSS forwards it to the ssUAP of the Conductor; 3) the Conductor accepts the join request:
a) the ssUAP of the Conductor sends the acceptance to the GSS;
b) the GSS forwards it to the GSC;
c) the GSC acknowledges the Conductor, i.e. it sends the invocation to the GSS that forwards it to the appropriate ssUAP;
d) also, the GSS instructs the InteRA SSO to enable the new party in the MCU;
e) the GSS updates the Conference Graph with the new Participant;
f) the ssUAP of the new participant is created;
g) the GSS informs all ssUAPs (of the other
Participants) of the change. A. The Consumer domain
This Section describes the TINA NetMeeting ssUAP internal structure.
The modularity applied in the design phase of the TINA NetMeeting ssUAP has been driven by the objectives to reuse as much as possible the code and to define a common structuring model that could ease the design phase of future services.
According to this approach, the ssUAP instance has been divided into three types of objects: an object maintaining the ssUAP logic, some objects implementing specific proxy functionality and a generic object managing their life cycle. This model has been applied in the GSS design too (as it will be explained in Section A).
tinaNmSsuapInitial tinaNm Ssuap Impl UMM Session Members tinaNmSsuapParty tinaNmClientSSO tinaNmGUI (NetMeeting COM Object) ssuap instance tinaNmCOM ii_ProviderNMControlInd ii_ProviderNMControlInfo ii_PartyMultipartyInfo ii_PartyVotingInfo ii_PartyMultipartyInd ii_PartyBasicExe ii_PartyMultipartyExe ii_AccessInitialise ii_Unstore
JAVA Interface. External Use Launch CORBA Interface.
Fig. 6. TINA NetMeeting ssUAP structure
As depicted in Fig. 6 the ssUAP server of the TINA NetMeeting service is composed by the following objects:
tinaNmSsuapInitial: is in charge of managing the life cycle of the ssUAP instance.
tinaNmSsuapImpl: can be considered the object that maintains the overall logic of the ssUAP. In fact, it captures all requests selected by the Consumer, and translates them into external invocations towards the GSS.
User Member Manager (UMM): implements the manager of the ssUAP. It is in charge of instantiating and deleting the instances associated with the current conference session (see Session Members in Fig. 6).
tinaNmGUI: this class implements all the graphical components of the ssUAP.
tinaNmSsuapParty: provides all the interfaces whose operations are used to interact with the user or to notify the user about conference changes at both a service and session level.
tinaNmClientSSO: acts as a proxy towards the
Microsoft NetMeeting COM component. The TINA NetMeeting service exploits the Audio/Video capabilities of the Microsoft NetMeeting application by integrating its COM component. (For technology-related details, see Section III).
In summary, at service session creation the tinaNmSsuapInitial object creates the tinaNmSsuapImpl, which on its own creates the UMM in charge of instantiating the other ssUAP objects, including the tinaNmClientSSO that creates and destroys the NetMeeting COM component.
To explain how the ssUAP internal objects accomplish functionality, we detail the Example Scenario (given in Section II) for the steps involving ssUAP instances that are: 1) the Conductor invites Fabrizio:
a.1)the invitation is invoked on the tinaNmGUI;
a.2)the tinaNmGUI forwards it to the tinaNmSsuapImpl; a.3)the tinaNmSsuapImpl sends the invitation to the
GSS;
2) Fabrizio requests to join the session:
1) the GSS forwards the join request to the ssUAP of the Conductor, i.e. it arrives to the tinaNmSsuapParty;
2) the tinaNmSsuapParty invokes the tinaNmGUI that prompts the Conductor GUI with the join request; 3) the Conductor accepts the join request:
a.1)the ssUAP of the Conductor sends the acceptance to the GSS, by following the same procedure as in step 1.
f.1) the ssUAP of the new participant is created, i.e. the creation is invoked on the tinaNmSsuapInitial interface;
f.2) the tinaNmSsuapInitial creates the ssuap instance by following the service session creation steps;
f.3) the tinaNmSsuapImpl exports its IDL external interface whose reference is returned to the GSS for successive invocations.
g.1)the GSS informs all ssUAPs of the change, i.e. it invokes the tinaNmSsuapParty of each ssUAP; g.2)the tinaNmSsuapParty invokes the tinaNmGUI that
informs the party GUI of the new participant with both a message shown in an information box (see lower part in Fig. 5), and the update of the graphical representation of the Conference Graph (visible by clicking button Show in Fig. 5).
B. The Retailer domain
The TINA NetMeeting service-specific components in the Retailer domain are the SF, the GSS and the InteRA SSO.
The separation of the SSM into GSS and GSC had an impact on the design of the SF and of the GSS since, as explained in the following Section, there are two control points in the interaction flow and this can have potential drawbacks in terms of inconsistency.
A. The Service Session Manager Service Component The service session manager (SSM) of the TINA NetMeeting service consists of a service-specific part, accessible through a service-specific feature set, and a service-common part, composed by a number of TINA Session Model Feature Sets [4]. In general, there are two different approaches for integrating the service-specific and service-common logic: SSM GSS server GSC server SSUAP proxy SSUAP GSC proxy GSC
Ret interfaces ssUAP Ret interfaces
Fig. 7. TINA NetMeeting SSM structure
the Interaction Approach, in which the service-specific and service-common logic execute in different contexts, and all interactions occur by invoking IDL operations on each other. In this case, the service-common logic is reused at run-time.
the Inheritance Approach, in which the SSM class is constructed by inheriting from the service-common session model class. In this case, the service-common logic is reused at compile-time.
The SSM of the TINA NetMeeting service has been implemented according to the Interaction Approach, i.e. it is composed of two different CORBA servers: the GSS that stores the service-specific logic, and the GSC that implements the service-common features.
The idea behind the adoption of this approach is twofold. On the one side, it reflects the conceptual layering of the architecture presented in Fig. 4, which suggests a service-common platform providing the access session and the session control capabilities on top of which the service logic is implemented. The main motivation is to start thinking about a scenario in which different components manage and control the same service session graph.
On the other side, a motivation is to adopt a telecom operator approach, which aims at building its service platform in a multi-vendor scenario. In this case, the separation of the SSM into two components permits them to be developed by different companies.
A ssUAP proxy and a GSC proxy have been introduced in the GSS to implement this approach: as depicted in Fig. 7, the ssUAP proxy object offers the ssUAP Ret interfaces to the GSC, and it filters the invocations towards the ssUAP.
Similarly, the GSC proxy offers the GSC Ret interfaces to the ssUAP, and it filters the invocations towards the GSC.
Section B gives some details about how the SF (at component creation) manages the substitution of the interface references of the ssUAP and GSC with respectively the ssUAP proxy and the GSC proxy ones.
By using the ssUAP proxy, the GSS is informed about any change in the service session coming from the Access Session components, e.g. the request to join an existing session. In this way, the GSS can upgrade the Conference Graph accordingly, keeping at the same time the use of this proxy completely transparent to the GSC.
ii_ProviderNMCQueryReq ii_ProviderNMCControlReq ii_ProviderBasicReq ii_ProviderMultypartyReq ii_ProviderVotingReq ii_PartyBasicExe ii_PartyMultipartyExe ii_PartyMultipartyInd ii_PartyMultipartyInfo ii_PartyVotingInfo tinaNm Ssm Impl SMM tinaNmSsuapProxy tinaNmServiceGraphSSO GSCProxy inteRAProxySSO SessionMembers ssminstance ii_Init ii_Unstore tinaNmSsmInitial
Fig. 8. TINA NetMeeting GSS structure
As depicted in Fig. 8 the TINA NetMeeting GSS server is composed of the following objects:
TinaNmSsmInitial: is in charge of managing the life cycle of the SSM instance.
TinaNmSsmImpl: receives the external invocations from the ssUAP. It can be considered the object that maintains the logic of the GSS, providing it the main service-specific interface supported by the GSS, i.e. the ii_ProviderNMCControlReq interface. This interface, used for conference control, supports a set of methods, some of which are:
• setConfReq() changes the conference topology according to the passed conference type.
• setConfPwdReq() sets a password-based conference protection. Access control is changed from IP-based to password-based.
• switchVideoSourceReq() is used to switch the video source for all the conference participants to the participant specified as parameter.
• setVideoSourceReq() sets the video source for the participant specified to the participant specified.
• clearVideoSourceReq() clears the video source for the destination participant. The video source is automatically returned to the default value.
• enableVideoReq() and enableAudioReq()
enable respectively the video and audio connection of all participants in the conference.
Session Member Manager (SMM): implements the generic manager of the GSS internal objects (see the Session Members in Fig. 8). It is in charge to instantiate and to delete the instances of such objects.
GSCProxy: mirrors the interface offered by the GSC. The ssUAP invokes the methods on this interface, and the GSCProxy interprets the invocation according to the service-specific logic before transferring it to the GSC.
InteRAProxySSO: is in charge of invoking the InteRA object interfaces.
TinaNmSsuapProxy: mirrors the interface of the ssUAP. The GSC invokes the methods on this interface, and the TinaNmSsuapProxy behaves in a symmetric way with respect to the GSCProxy.
TinaNmServiceGraph: maintains the representation of the Conference Graph.
As described in Section A, the Conference Graph represents the conference topology, in which graph nodes model the users, and arcs between nodes model audio and video transmission between users. Fig. 9 presents an example of the graphical representation of a Conference Graph, as presented to the user via the ssUAP GUI. Different nodes represent differently the Conductor and the conference Participants. The arcs between nodes represent audio and video flows (colored differently in the GUI). Furthermore, the arrowheads are directed from the source toward the destination of the transmission. Filled arrowheads model enabled connections, whereas empty arrowheads model disabled connections.
Fig. 9. A conference graph
The Example Scenario (given in Section II) involves the GSS in the following steps:
1) the Conductor invites Fabrizio:
a) the ssUAP of the Conductor sends the invitation to the GSS, i.e. it is invoked on the GSCProxy;
b) the GSCProxy asks the tinaNmServiceGraphSSO to check in the Conference Graph if the invitee is the Conductor;
c) the GSCProxy forwards the invitation to the GSC; 2) Fabrizio requests to join in the session:
b.1)the GSC forwards the request to the session Owner (the Conductor in the Conference Graph) to decide about request acceptance or deny, i.e. the request is passed to the tinaNmSsuapProxy;
c.1)the tinaNmSsuapProxy forwards it to the ssUAP of the Conductor;
3) the Conductor accepts the join request:
a) the ssUAP of the Conductor sends the acceptance to the GSS, i.e. to the GSCProxy;
b) the GSCProxy forwards it to the GSC;
c) the GSC acknowledges the Conductor, i.e. it sends the invocation to the tinaNmSsuapProxy that forwards it to the appropriate ssUAP;
d) the tinaNmSsuapProxy instructs the InteRA SSO to enable the new party in the MCU, i.e. it invokes (via the SMM) the inteRAProxySSO that forwards the request to InteRA;
e) the tinaNmSsuapProxy asks the
tinaNmServiceGraphSSO to update the Conference Graph;
f) the ssUAP of the new participant is created;
g) the GSS (via their tinaNmSsuapProxy's) informs all ssUAPs of the change.
B. The Service Factory Service Component
The SF is the service-specific object that creates and manages the life cycle of all service session computational objects. Internally the SF server is composed of the following two objects, as shown in Fig. 10:
tinaNmSfInitial: is in charge of managing the life cycle of the SF instances.
tinaNmSfImpl: receives the external invocations from the Access Session. It implements the logic of the SF.
tinaNmSfImpl ii_SSCreate
ii_SSManage
tinaNmSFInitial
Fig. 10. The SF structure
During service session creation, the SF performs the following steps:
1) it creates a new tinaNmSfImpl instance. This object represents the service session;
2) it interacts with the GSS server to create the service-specific objects;
3) it interacts with the GSC server to create a generic service session instance.
At this point, in the traditional TINA session creation scenario the SSM interface references (both service-specific and service-common) are returned back to the ssUAP.
Since we chose the Interaction Approach to implement the SSM, the SF has to return back to the ssUAP the interface references of the GSC proxy in place of the "real" GSC interfaces. Consequently:
4) the SF interacts again with the GSS to substitute the interface references. It gives as input to the GSS the GSC "real" interface references, and it receives as output parameter the GSC proxy interface references;
5) the SF returns these GSC proxy interface references back to the ssUAP.
C. The Internet Resource Adapter SSO Component The InteRA SSO controls the commercial MCU by considering it as a special resource. Therefore, the InteRA object is in charge of adapting the MCU to a TINA-based service architecture.
This component supports two kinds of functionality: • Control: InteRA translates service session invocations on
CORBA interfaces, into MCU proprietary Telnet commands issued on the MCU Telnet port. These commands configure and control the MCU as a whole. Also, they control the life cycle of H.323 conferences and the access to them (detailed in Section I).
• Management: InteRA supports the recovery of various kinds of failure (detailed in Section II).
I. The InteRA architecture
The internal architecture of the InteRA server is depicted in Fig. 11:
InteRAInitial: manages the life cycle of the conferences. It creates and deletes the InteRAImpl instances.
InteRAImpl: represents the conference service session. When it is created, it gets an MCU hostname from the MCUOptimizer, and it instructs the MCUtelnetIO to create the conference in the suggested MCU. It exports the following interfaces:
• ii_SSControlInteRAExe: this interface is used for service session control. It supports the following methods:
• resumeConfExe() is used for the conference
resumption during the failure recovery of the MCU. • setConfExe() changes the conference topology
according to the passed conference type.
• setConfPwdExe() sets a password-based conference protection. Access control is changed from IP-based to password-based.
• addPartyExe() adds and registers a new party to the conference.
• deletePartyExe() deletes and de-registers a party from the conference.
• ii_CControlInteRAExe: this interface supports conference control via a set of methods that reflect the ones in the GSS ii_ProviderNMCControlReq interface (see Section A) by translating the operation into MCU Telnet commands.
MCUtelnetIO: carries out all the interactions with the MCU through its Telnet port.
MCUOptimizer: checks the status of each MCU that can be used by the InteRA SSO, and it chooses the one that will serve the current conference session, according to a list of optimization indexes that characterize all MCUs. This index depends on both the number of conferences currently held by the MCU, and a parameter that expresses the elaboration capacity of the machine where the MCU is executing. Therefore, if a Retailer domain offers multiple MCUs, this object optimizes the MCU workload by choosing the MCU with the best index.
The following steps describe the creation of a conference: 1) The GSS requests the InteRAInitial object to create a
new conference with a specific conference name and according to a specific conference type (e.g. a Lecture or a MultiPoint-to-MultiPoint).
2) The InteRAInitial object creates the InteRAImpl instance, which represents the new conference.
3) The InteRAImpl object requests the MCUOptimizer the IP address of the "best" MCU.
4) The InteRAImpl, via the MCUtelnetIO, creates a new conference in the chosen MCU (and configures it) via MCU Telnet commands.
5) Finally the InteRAImpl returns a unique identifier for that conference, which contains the IP address of the MCU serving the conference, the conference name, and the conference number generated by the MCU.
During session deletion, the InteRAInitial object removes the selected conference from the MCU, and cleans up all associated components.
InteRAInitial
InteRA
Impl MCUOptimizer
InteRA instance ii_InteRAInit MeetingPoint Ii_SSControlInteRAExe ii_CControlInteRAExe MCUtelnetIO Telnet invocations
Fig. 11. The InteRA structure The InteRA SSO supports the following exceptions: • “No MCU available”: if no MCU is currently registered
in the Retailer domain.
• “MCU not responding”: if the contacted MCU is not responding on the network (see failure management in Section II)
• “This resource modification is not allowed”: if the resource is not modifiable according to the semantics of the current conference type.
At last, in the Example Scenario (given in Section II) the InteRA instance associated with the conference session is involved in step 3.d) only, when the GSS requests it to enable the new party in the MCU. The request is activated on the InteRAImpl and forwarded to the MCUtelnetIO. The MCUtelnetIO maps the IDL invocation on the set of Telnet commands translating the semantics of the invocation into steps comprehensible by the commercial MCU. The commands are invoked on the MCU in a Telnet connection. II. Failure management
Failure management is based on persistent information stored periodically by the InteRAInitial object, and describing the last recorded InteRA status previous to the failure. This information mirrors the Conference Identifier and the Conference Graph for all active conferences, including e.g. the conference name, conference participants, etc.
It recovers the following failure categories:
Failure of the whole TINA NetMeeting service. In this case, the InteRA server, at service session creation reads the
local persistent failure record that identifies the conferences that were running when the failure occurred, and cleans up the commercial MCU from the conferences that were created and that are not accessible via TINA anymore.
Failure of the MCU. It can happen that during a conference service session, the MCU does not respond to Telnet commands issued by InteRA even though the TINA NetMeeting service session is still active. In this case, when the SSM invokes a method on the InteRA CO, this cannot be translated (via the MCUtelnetIO instance) into MCU commands, and an exception is raised on the GSS that activates a recovery procedure on the InteRA CO. This either waits until the MCU is restored before a timeout expires, or assigns to the session another available MCU that is configured with the current state of the conference session. In the latter case, the recovery procedure takes care of notifying the ssUAPs of the session parties of the IP address of the new MCU. Of course, this procedure is completely transparent to the users.
Failure of the InteRA server. If the InteRA CORBA server crashes, it is restarted, and the GSS invokes a method on the InteRAInitial object interface that restores the new references to the InteRA interfaces. In this way, InteRA can restore the MCU assigned to the conference.
By recovering InteRA and MCU failures, a TINA NetMeeting service session can be carried out without being forced of closing the session and restarting it by repeating the whole join/invitation procedure.
III. T
ECHNOLOGY ISSUESIn this chapter some technology issues related to problems encountered during the integration of Microsoft NetMeeting in the ssUAP are described.
This integration is a client-server relation between the ssUAP and the COM component.
The ssUAP, that plays the client role, needs the interface reference of the COM component in order to use it. The interfaces of the COM component are identified uniquely by a Global Unique Identifier (GUID) which contains information related to the machine in which the COM component runs.
In order to get this interface reference, the ssUAP calls a generic COM function passing as input parameter the class identifier of the COM component that it wants to create, and the identifier of the interface to be used.
Finally the ssUAP can interact with the NetMeeting COM instance via this interface reference.
COM components are conceptually similar to Microsoft Java objects. Their interfaces are described by a proprietary IDL (Microsoft-IDL) whose syntax is quite similar the C++ language.
Specific Microsoft tools like NetMeeting SDK, translate the Microsoft-IDL definition of the COM interface in a Microsoft-Java representation that is not pure 100% Java.
This allows accessing the COM component functionality by Microsoft-Java classes that have to be compiled for the Microsoft JVM (Java Virtual Machine).
Consequently these classes cannot be used directly in the ssUAP that is implemented using IONA OrbixWeb as CORBA platform (a commercial ORB based on Sun Java) and thus compiled for the Sun JVM.
To solve this problem we implemented a client stub (C in Fig. 12) for the ssUAP and a server stub (S in Fig. 12) using Java functionality supported by both the JVM environments.
NetMeeting COM wrapper ssUAP server tinaNmClientSSO NM COM C S
Fig. 12. The ssUAP-COM interaction
The conclusive step was to transform the wrapped NetMeeting COM into an executable. This allowed controlling the life cycle of the NetMeeting COM component directly by the ssUAP. In fact it is launched when the tinaNmClientSSO is created and it is destroyed when the participation in the session is terminated.
IV. T
HETINA
ADDED VALUESIn the traditional context of an audio/video conference service based on the common commercial products described in this work, the main aspect is that both the end-user application, and the MCU have to be pre-configured.
If the commercial applications are used on an as is basis, each user has to choose the personal computer (s)he is going to use in the conference and must provide its IP address to the MCU manager in order to be admitted in the conference. Afterwards, in order to join a conference (s)he must know both the IP address of the machine where the MCU is currently running, the kind of transmission protocol used by the user's personal computer, and the conference name as registered in the MCU.
On the other hand, the MCU must be pre-configured to both support a conference suitable for the features that the users intend to use, and accept the connections from the machines where the users are currently located. This means that the person in charge of administering the MCU should manually do the following operations:
1) Create a conference with the suitable characteristics, 2) Allow a list of personal computers to join that conference
(or leave it free for everyone),
3) Program the conference topology by identifying the audio- and video- stream sources and destinations for each participant according to their requirements.
In summary we can identify the following characteristics: 1) The participants in a conference are identified by the IP
address of the machine they are currently working on. 2) Any new participant has to be added manually via a
configuration management procedure that cannot be done dynamically by any participants.
3) A participant cannot invite any other participant to join the conference.
4) Every participant must know the MCU location and the conference name in order to join it.
5) The conference topology is pre-defined, and only the MCU manager can change it manually via a configuration management procedure.
6) It is not possible, for instance, to assign roles to users (e.g. teacher or students) and to associate roles with different levels of conference control.
7) There is no service session representation. For instance, it is not possible to visualize which users are participating in the conference, or who is able to transmit/receive audio or video.
These characteristics make the commercial applications unsuitable to the needs of an audio/video conference service for non-technical users, e.g. in the distance education domain that was the theme of our work. In fact it requires rules and a communication scheme mapping standard education communication onto computer-supported protocols.
One objective of this work is to integrate the commercial conferencing applications in a TINA compliant framework in order to extend the application features to support tele-teaching conference sessions in a flexible and intuitive way. As a consequence, it also demonstrates that by adding TINA session-based service control, Internet applications gain an added value.
In fact the added values of our TINA/Internet solution are: 1) Transparent location of resources: the MCU location is
transparent to the users. A TINA SSO (InteRA) manages the choice of the MCU and its location. A user can start a conference session by simply requesting the service. (S)He must just provide the conference type, and decide a conference session name.
2) Dynamic configuration of resources: the MCU is configured dynamically by the service logic whenever the user does a modification in the conference. A TINA SSO (InteRA) controls the dynamic configuration of the MCU.
3) Multi-resource support: the service can rely on a pool of MCUs and can decide to use one of them depending on, for example, their workload. A TINA SSO (InteRA) checks the status of each MCU that can be used by the service, and chooses the one that will serve the current conference session, according to an optimization algorithm.
4) Higher availability: new MCUs can be easily added to the list of managed MCUs without stopping the sessions currently active. Further, the InteRA SSO can manage the failure of a MCU by moving all the conferences running on it to another MCU without stopping their sessions.
5) User identification by a logical name: users' location is completely transparent A user can participate in a conference from any location, and (s)he will be identified with his/her logical name. An important TINA concept is personal mobility, i.e. a user is associated with a terminal just when (s)he accesses the Retailer domain and (s)he is authenticated.
6) Invitations: a participant can invite another one to participate in the conference just by using the service GUI and by providing the logical name of the participant to be invited. The TINA Access and Service session allow inviting new participants to join existing service sessions. The current location of the participant to be invited is registered in a TINA SA component (the User Agent, UA).
7) Role based service features: a Conductor is allowed to control the conference characteristics (included the admission of new Participants), whereas the Participants have a restricted set of privileges, and must be subject to the grant from the conductor. Instead, according to the TINA access session principles, users are authorized to participate in a service session according to their personal subscription information. Authorization foresees two user categories: the users authorized to start a service session, and the users that can only join (or be invited in) an existing service session.
8) Pre-defined conference types: the service provides the user with three pre-defined conference types:
• Lecture: it resembles a registered lesson transmitted on television.
• Point-to-MultiPoint: it models a face-to-face lecture in which the teacher is the central point, and (s)he interacts with all the students.
• MultiPoint-to-MultiPoint: it models the most flexible conference type, in which all parties can modify everything.
The centralized service logic (managed by the GSS) allows implementing the concept of conference type as scripts of statements used to configure the MCU via a TINA SSO (InteRA).
9) User-defined conference types: the service provides the participants with a suite of operations to modify dynamically some settings of the ongoing conference. The TINA service session allows the participant to request specific modifications to the conference by appropriately instructing the MCU.
10) Service Session representation: the participants can visualize the conference topology in the service GUI. The SSM manages the Conference Graph as a specialization of the TINA Service Session Graph that is graphically represented to the participants.
V. C
ONCLUSIONS ANDF
URTHERW
ORK The work objective is to study both the impact on, and the applicability of the TINA standard, whenever commercial Internet-based audio/video conferencing applications are reengineered as TINA services.The adopted approach:
1) Takes advantage of the commercial applications as far as the audio/video conferencing support is concerned. 2) Considers the TINA service session as a common
execution environment. This enables the management and the control of commercial applications by exploiting a common service logic that coordinates overall service behavior.
The main result of the integration of commercial conferencing applications in a TINA-based framework is to make the service user-friendlier and more robust, and to add new service features.
Also, the TINA framework abstracts the concept of resources by making their access and use transparent to the user.
Further, TINA provides the separation between the concept of user and the location (s)he is registered from. This aspect enhances commercial applications by rendering user location transparent to them.
Finally, the TINA Session Graph and the concept of roles allow adding new service features like to visualize the status of a service session.
From a more pragmatic perspective, the challenging complexity of the integration aspects of this work has been divided into three sub-problems:
The integration of the COM component in the ssUAP: The choice of Microsoft NetMeeting as end-user application was due to the availability of its SDK tool that allows using the NetMeeting COM interface by providing specific tools that translate the Microsoft-IDL definition of the COM interface in a Microsoft-Java representation. Most of the problems we faced were due to the poor Microsoft documentation and by the well-known confusion about the definition of Java-compliant code.
The interaction between the service logic and the conference server:
The chosen conference server (WhitePine MeetingPoint) offers a rich set of commands and associated features that permit to control a conference in a very flexible way via a proprietary protocol based on proprietary Telnet commands. Unfortunately, the behavior of H.323 audio and video streams actually exchanged among conference parties often does not reflect the expected behavior, and (even worst) the observed behavior changes randomly. In the context of this work, it has been carried out a detailed analysis of the MCU functionality’s, for both the Windows NT, and Sun Solaris versions. The result is that for this purely technological reason, TINA NetMeeting offers a sophisticated feature set that successfully demonstrates the advantages of the TINA session model with respect to a commercial product, but this feature set often is not semantically reflected in the H.323 conference. As an example, consider that a conference of type Lecture behaves correctly if the parties are at least three, but with two parties, the MCU behaves in a way that differs from the one represented by the Lecture conference graph.
The specification of the Service Session Manager: The SSM comprises the service specific and generic session control segment [3] of the Service Session in the Retailer domain. The particularity of our design is due to the adopted Interaction Approach modeling the service-specific part and the common one. The ideas and the advantages behind this choice are:
a) It reflects the conceptual layering of the architecture presented in this work which suggests a service-common on top of which the service logic is implemented.
b) It is an open design solution since it supports a scenario in which two different service logic can manage and control the same session graph.
c) It allows to recovery the service-specific part independently of the service-common one.
d) It is compliant to a telecom operator approach, which aims at building its service platform in a multi-vendor scenario. In this case this permits to commit the development of the two components to different companies.
On the other side it presents the following critical points: a) The service-specific part has to be informed explicitly of
any change in the Session Graph managed by the service-common one.
b) There are two possible control points and this can have drawbacks in terms of inconsistency.
Consequently, this had an impact on the internal structure of the GSS since it has to be synchronized to the Session Graph changes: the ssUAP proxy and a GSC proxy have been introduced in the GSS to solve these criticisms.
At last, all the service components rely on two commercial ORBs named IONA Orbix and IONA OrbixWeb. These two products are respectively a C++-based ORB and a Java-based ORB. From our viewpoint, for a work of this complexity these ORBs can be considered of enough quality. Nevertheless they are not suitable for realistic telecom services, needing them a higher degree of reliability to cope with the telecom services environment.
On-field tests carried out for distance education demonstrated that TINA NetMeeting still presents some lacks due to the commercial application it integrates, especially because "real" scenarios like tele-teaching require a better quality of service (QoS). In this perspective, a further work is the enhancement of the service to support dynamic user requests for a better QoS. To this aim, the underlying service architecture needs to be extended to control and allocate the necessary network resources by exploiting the same concept of Service Support Object (SSO) introduced for the MCU. We foresee to enhance the service by introducing new resources and consequently a new controller with the same structure as the implemented SSO.
An e-mail server and a gateway for GSM SMS messages are the next resources whose capabilities are going to be added to the service. We expect to support various priority levels in the invitation of new users: i.e. when inviting a user that is not logged in the Retailer domain, the user could be notified asynchronously, by using different mechanisms according to different associated priorities.
Further, an ongoing work is the provisioning of the TINA NetMeeting service toward "general-purpose" end-user terminals: currently, both the code that wraps Microsoft NetMeeting and the Microsoft JVM needs to be pre-installed on the end-user terminal as discussed in Section III. Our objective is to let the user start the TINA NetMeeting service session on a general-purpose terminal, on which all the code of the ssUAP will be dynamically and transparently downloaded from the Retailer domain.
In conclusion, thanks to both internal and European projects investigating the applicability of TINA concepts, we gained significant experience in the use of TINA in various contexts like the Internet.
As a result, we think that TINA is a promising environment for the marketplace of the future. Nonetheless, it has to demonstrate its maturity in both integrating existing products and solutions, and supporting existing standard de facto protocols.
This work can represent a successful step in the achievement of this objective.
A
CKNOWLEDGMENTThe authors would like to thank all the other members of the development team. A special thanks goes to Mr. Carlo
Alberto Licciardi for his valuable suggestions and comments on draft versions of this paper.
R
EFERENCES[1] T. Hamada, S. Hogg, J. Rajahalme, C. Licciardi, L. Kristiansen, P.F. Hansen, Service Quality in TINA: Quality of service trading in open network architecture. In IEEE Communications Magazine, Vol. 36(8), Aug. 1998, pp. 122-130.
[2] Y. Inoue, D. Guha, H. Berndt, The TINA Consortium. In IEEE Communications Magazine, Vol. 36(9), Sep. 1998, pp. 130-136.
[3] TINA service architecture, Version 5.0, TINA-C, June 1997. [4] TINA Ret reference point specification 1.0, TINA-C, 1997. [5] TINA service component specification 1.0b, TINA-C, 1997. [6] The ITU-T Recommendation H.323 for multimedia
communications systems, available at http://www.itu.int/. [7] The TINA Consortium, available at http://www.tinac.com. [8] The White Pine MeetingPoint Conference Server, available
at http://www.wpine.com/products/MeetingPoint/.
[9] Microsoft NetMeeting, available at
http://www.microsoft.com/netmeeting/.
A
CRONYMSCOM Component Object Model
CORBA Common Object Request Broker Architecture GSC Global Session Control
GSS Global Service Segment InteRA Internet Resource Adapter MCU Multi-point Control Unit ORB Object Request Broker SA Service Architecture
SF Service Factory
SSG Service Session Graph SSM Service Session Manager SSO Service Support Object
ssUAP service session User APplication
TINA Telecommunications Information Networking
Architecture
UA User Agent
