2
Understanding Oracle Web Conferencing

2.1 Overview

This chapter explains Oracle Web Conferencing concepts and architecture. This chapter describes:

• Terms and definitions
• Real-Time Collaboration processes of Oracle Web Conferencing, including the function of each and their interactions.
• The detailed runtime flow of various kinds of clients connected to the Web Conferencing Server for a conference.
• Ports required for Web Conferencing and all network connectivity issues
• How to create clusters for a distributed deployment

2.2 Terminology

2.2.1 Host

A physical machine.

2.2.2 Real-Time Collaboration Instance

A Real-Time Collaboration instance is a grouping of Real-Time Collaboration components installed within the same Oracle home. These components work together to deliver a well-defined set of services to end-users, other Real-Time Collaboration instances, or external applications.

Three basic installation types--the Core Components, Document Conversion Server, and the Voice Conversion Server--are created when they are installed by the Oracle Collaboration Suite installer. If all are installed on the same machine, there is one instance only. The Real-Time Collaboration Repository is either present in the information store database when Oracle Collaboration Suite information store is installed, or it is created during installation of first Core Components installation.

See Also: Oracle Collaboration Suite Installation and Configuration Guide for Solaris for details.

2.2.3 Real-Time Collaboration Component

An Oracle Real-Time Collaboration component is a set of processes within an instance that have identical functionality. Each component has a component type and component name.

The following table contains Real-Time Collaboration component types and names:

Table 2-1 Real-Time Collaboration Components

Component Type	Component Name	Number of Processes/Component	Full Component Name
clbsvr	imt-collab	1-N	Oracle Web Conferencing Server
oc4j	oc4j_imeeting	1-N	Web Conferencing OC4J
mxcomm	rtc-mx	1-N	Multiplexor
voiceconv	imt-voiceconv	1	Voice Conversion Server
docconv	imt-docconv	1	Document Conversion Server
imt-pm	imt-pm	1	Real-Time Collaboration Process Monitor

Use the listComponents imtctl command to see a list of components in an instance. See Chapter 10, "imtctl Command Line Utility" for more information.

The following illustration shows an instance with three components and each of their multiple processes.

Figure 2-1 Component and Processes of a Real-Time Collaboration Instance

Text description of the illustration instcomp.gif

A--Component OC4J_imeeting (one process)

B--Component Real-Time Collaboration mx (two processes)

C--Component Web Conferencing (four processes)

2.2.4 Real-Time Collaboration Cluster

A grouping of Real-Time Collaboration instances that have the same value of "InstanceLocation" property and which use the same Real-Time Collaboration Repository.

2.2.5 Real-Time Collaboration System

The set of all instances that share the same Oracle Real-Time Collaboration Repository. Because instances can be part of clusters, the Oracle Real-Time Collaboration system can be thought of as a set of all clusters.

Figure 2-2 Real-Time Collaboration System

Text description of the illustration sys_hier.gif

2.3 Real-Time Collaboration Components

Figure 2-3 Real-Time Collaboration Architecture

Text description of the illustration archtect.gif

2.3.1 Oracle Web Conferencing Server

There can be one or more Web Conferencing Server processes in a Real-Time Collaboration instance. The set of Web Conferencing Server processes in an instance constitutes a Web Conferencing Server component. It has the following functions:

• Manages all the conference attendees' states and their permissions within the conference
• Intelligently distributes real-time data for all the collaboration modes that are active during the conference
• Provides services for the recording and archiving of the conference

2.3.2 Real-Time Collaboration mx (Multiplexor)

There can be one or more mx process in an instance. The set of mx processes in an instance constitutes a mx component. The process has the following functions:

• Accepts inbound connections from clients, Web Conferencing Servers, and other Real-Time Collaboration processes.
• Routes data traffic between all clients and all Web Conferencing Servers on a machine.
• Acts as a communication hub for all components.

2.3.3 OC4J_imeeting

The Oracle Web Conferencing J2EE Application running in the Oracle9iAS Containers for J2EE. Some of the functions it provides are:

• Provides the Web-based user interface to Oracle Web Conferencing for end-users.
• Provides integration with external applications like Oracle Calendar.
• Interfaces with Oracle Internet Directory for user management.

2.3.4 Real-Time Collaboration Process Monitor (imt-pm)

This process monitors all the other Real-Time Collaboration processes, except OC4J_imeeting processes, and provides high availability by restarting processes if they are down. This process itself is monitored by the Oracle Process Management and Notification system.

2.3.5 Voice Conversion Server

This process dials in to a voice conferencing system, captures the analog voice stream, digitizes it, and streams it to a Web Conferencing Server process through the mx.

2.3.6 Document Conversion Server

This process converts Microsoft Office documents to HTML for document presentation. The Web Conferencing Application provides the front end for a user to convert a document.

2.3.7 HTTPD + mod_imeeting

mod_imeeting is the Real-Time Collaboration plug-in to Oracle HTTP Server. It makes it possible for Oracle Web Conferencing to use Oracle HTTP Server as the only listening point to listen for end-user connection requests. Connections are handed off to the mx using socket hand-off, after the connection has been established using Oracle HTTP Server as the listener.

2.4 Process Interaction

2.4.1 Within an Instance

Within an instance, each Web Conferencing Server process is always connected to each multiplexor process.

Each OC4J process can connect to any mx in the cluster to which the instance belongs. OC4J initially connects to one of the mx processes when required, and from then on caches the connection.

Through the Oracle Web Conferencing Console, each conference participant connects to one of the mx processes, either directly or through a socket hand-off. mod_imeeting connects to all the mx processes in the same instance.

2.4.2 Across Instances

• Across instances, the Voice Conversion Server process in an instance connects to all the mx processes in another instance, which it has been configured to service.
• The Document Conversion Server process in an instance connects to all the mx processes in another instance, which it has been configured to service.

2.4.3 Connections

2.4.3.1 Virtual Channels

Given that all processes connect to the mx, which acts as a communication hub, the following essential virtual channels are created:

• Web Conferencing Console to the Web Conferencing Server process through the mx during a conference.
• The Oracle Web Conferencing OC4Js to the Document Conversion Server process through the mx used for document conversions.
• Each Web Conferencing Server process to the Voice Conversion Server process through the mx for voice streaming during a conference.

2.4.3.2 Database Connections

• Each Web Conferencing Server process maintains a pool of connections to the Real-Time Collaboration Repository.
• Each Oracle Web Conferencing OC4J process maintains a pool of connections to the Real-Time Collaboration Repository.
• Each Document Conversion Server maintains a connection to Real-Time Collaboration Repository.
• Each Real-Time Collaboration Process Monitor maintains a connection to Real-Time Collaboration Repository.

2.5 Runtime Flow

2.5.1 Client Connection Details

All conference attendees fall into one of three categories:

• Attendees connect directly to Oracle Web Conferencing without traversing any firewall. Example: all attendees are in the corporate intranet.
• Attendees connect to Oracle Web Conferencing from the Internet crossing a company firewall. Example: Web Conferencing is deployed in a company demilitarized zone (DMZ), and attendees from the Internet connect to the conference.
• Attendees are coming through the Internet from another company's corporate intranet through their proxy.

Figure 2-4 Client Connection

Text description of the illustration cliconne.gif

The Web Conferencing Console attempts to connect to the mx in the following way:

1. Direct TCP/IP--This method is typically successful for clients/computers within a corporate intranet and from the Internet, if the mx port is open to the Internet.
2. HTTPS direct (through Oracle HTTP Server/mod_imeeting)--If direct TCP/IP fails, the Web Conferencing Console tries to connect through HTTPS. This connection is typically successful for client/computers in the open Internet or across transparent proxies. Once a connection is established by Oracle HTTP Server, it is handed off to the mx by mod_imeeting using socket hand-off. Mx and the Web Conferencing Console then communicate directly with each other.
3. HTTPS tunnel (through Oracle HTTP Server/mod_imeeting)--If both direct TCP/IP and HTTPS direct fail, this is the only way to connect for client/computers that are part of a different intranet coming through their own internal proxy. The Web Conferencing Console tries to retrieve proxy information from the browser settings on the client machine and establish a connection to the Oracle HTTP Server using the proxy. Once established, the connection is handed off to the mx by mod_imeeting. Only this time, the Web Conferencing Console and mx communicate over the HTTPS tunnel through the remote proxy.

The connection information required to connect using the methods in this section is provided to a Web Conferencing Console (transparent to a user) when a user tries to join a conference. The details are explained later in this chapter.

2.5.2 Create Conference Flow

The create conference flow occurs when a host uses the application to create a scheduled or instant conference. The conference is created, and a conference ID is associated with it.

2.5.3 Join Conference Flow

The join conference flow occurs when an attendee joins a conference through the Oracle Web Conferencing Application, an e-mail invitation, or through an application that is integrated with Oracle Web Conferencing. The sequence of events follows:

1. The application looks up the conference record from the database and retrieves hosting server process information, that is, the list of Web Conferencing Servers that can host the conference. Then, the application authorizes the request based on the person joining and the attributes of the conference the person intends to join.
2. The server load balancer functionality in the Oracle Web Conferencing Application (OC4J_imeeting) chooses a Web Conferencing Server process, initiates the session there, and records the conference ID-Web Conferencing Server process association.
3. The list of client parameters for the Web Conferencing Console to connect is generated:
   • mx load balancer (running in OC4J) functions in the Oracle Web Conferencing Application (OC4J_imeeting). It chooses one mx, which can be used to connect to that server process.
   • HTTPS connection information is taken from the mx description (a description of which Oracle HTTP Server/mod can be used to redirect the connection to the given mx) based on how it has been configured.
   • Encrypted client authentication token is generated.
   • URLs to send user feedback information and retrieve Java/JSP components used in the console is also generated.
4. The Oracle Web Conferencing Application response causes a pop-up window on the user's Web browser (Internet Explorer 5.5 or above) to open, which contains a Web Conferencing Console Installer (an ActiveX control) with all these parameters.
5. If the user does not have the Web Conferencing Console Installer yet or has an earlier version, the most recent version is downloaded and installed by Internet Explorer automatically (with a permission alert).
6. The Web Conferencing Console Installer performs compatibility checks. If compatibility checks are successful, it checks the version of the Web Conferencing Console available on the client system.
7. If the Web Conferencing Console is not installed on the client machine, or if the Web Conferencing Console version does not match the current one, the new console package is downloaded and installed.
8. The Web Conferencing Console Installer starts the Web Conferencing Console (as a separate process) with all parameters.
9. The Web Conferencing Console tries to establish connection to mx using the algorithm mentioned earlier in Section 2.5.1, "Client Connection Details".
10. If all attempts fail, the client receives an error message.
11. If a connection is established, then the Web Conferencing Console creates a virtual channel through mx to the conference session.
12. The Web Conferencing Console sends an authorization token identifying the client to the server.
13. The Web Conferencing Server sends all conference state (list of attendees, shared content, chat transcripts, and so on) to the Web Conferencing Console to initialize it.
14. The Web Conferencing Console starts to work.

2.6 Ports and Network Connectivity

The following table contains port and network connectivity information.

Table 2-2 Ports and Network Connectivity

Component	Protocol	Port	IP	Number of Ports	Accessibility (Mandatory)	Accessibility (Recommended)
Oracle HTTP Server/mod_imeeting	HTTP	80	Primary	1	All clients
Oracle HTTP Server/mod_imeeting	HTTPS	443	Primary	1	All clients
Oracle HTTP Server/mod_imeeting	HTTPS tunnel	443	SecondaryFoot 1	1	All clients
mx	mxFoot 2	2400-2700Foot 3	Primary	n	Voice Conversion Server and Document Conversion Server must be able to access the mx(s) on the instances they serve.	Intranet clients could connect using direct TCP/IP. Given that Real-Time Collaboration Core Components are deployed in a DMZ, accessing these port(s) from the intranet is not an issue.
mx (on NT)	redirectFoot 4	2400-2700	Primary	n	Local host
voiced	HTTP	2400-2700	Primary	1	All machines with the Real-Time Collaboration Core Components it is servicing.	For remote status
imt-pm	HTTP	2400-2700	Primary	1	Local host from all Real-Time Collaboration instances.

1 Second IP address required only if Oracle9iAS Web Cache is present on the machine with the Real-Time Collaboration Core Components. 2 mx is a Real-Time Collaboration internal proprietary protocol. 3 Port will be chosen from this range. 4 redirect is a Real-Time Collaboration internal proprietary protocol.

For deployments that are accessible from the extra-net, it is enough for Internet- or extranet-facing firewalls of the DMZ to have just the traditional ports (443 and 80) open.

2.7 Real-Time Collaboration Clusters

Without explicit partitioning of the instances in the system, all Web Conferencing Server processes in all instances are considered part of one group. Whenever a new conference is created and a Web Conferencing Server process needs to be chosen for a conference, the conference could be assigned to any one of the Web Conferencing Servers in the system. But, sometimes, it is useful to partition the system into clusters based on geographical distribution.

Figure 2-5 Real-Time Collaboration Clustering

Text description of the illustration cluster.gif

Please note the following points regarding the InstanceLocation property:

• Instances that have the same value for the InstanceLocation property are part of a Real-Time Collaboration cluster. The advantages of creating a Real-Time Collaboration cluster are:
  • Load balancing. For example, all Web Conferencing Server processes in all instances that are part of the cluster become part of one pool of available servers, and the load is balanced intelligently between the different Web Conferencing Servers.
  • High availability. An instance could be down, which means that all Web Conferencing Servers in the instance are down, but other Collaboration Servers from other instances that are part of the same cluster could provide undisrupted service to users.
  • Load separation. With proper us of LBRs, geographically distributed users can be served by separate Real-Time Collaboration clusters that are more locally situated to the users. For geographically distributed companies, you might need to partition the group into smaller groups, with each group servicing a set of users. Use the InstanceLocation property for this purpose. By assigning a different value to the location attribute for the different sets of instances, you can create Real-Time Collaboration clusters in the system. For example, you could set the InstanceLocation property of each instance in a set of Real-Time Collaboration Core Components machines in the United Kingdom to "UK," and set the InstanceLocation property of each instance in the set of Real-Time Collaboration Core Components in the United States to "US."

2.7.1 Real Time Collaboration Clusters for Load Separation

Leveraging the InstanceLocation property requires that geographically separated users are routed to Oracle Web Conferencing Application (OC4J_imeeting) in their respective areas. This can be accomplished automatically with a geographically enabled load balancer or manually by having users in different locations access different Web Conferencing URLs. The Oracle Web Conferencing Application (OC4J_imeeting) in an instance is the component that picks the Web Conferencing Server process for a conference. The Oracle Web Conferencing Application (OC4J_imeeting) knows the Web Conferencing Server process location and picks a Collaboration Server process in an instance which has the same value as its own location.

The instance created by a Document Conversion Server or Voice Conversion Server installation must be assigned a value for the location attribute (like all instances) and it can be assigned to provide service to an Real-Time Collaboration Core Components machine with a specific value for the location attribute instead of all Core Components machines. For example, each instance of the Document and Voice Conversion Servers in the United Kingdom is assigned to service a set of Real-Time Collaboration Core Components whose location attribute value is "UK." Each instance in the set of Document and Voice Conversion Servers in the United States is assigned to service a set of Real-Time Collaboration Core Components whose location attribute value is "US."

2.8 Load Balancer Configuration

While there are no special requirements for configuring the LBRs themselves, please note the following:

• Oracle Real-Time Collaboration provides the capability for an administrator to partition the system into different Real-Time Collaboration clusters based on geographical distribution. To leverage this feature, set up the LBR to partition user requests based on geographical distribution, as well.
• All machines behind the LBR should have external routable IP addresses and must be directly accessible from the Internet at least on standard HTTP and HTTPS ports (80 and 443). See Section 2.6, "Ports and Network Connectivity" for more information.

See Chapter 6, "Sample Deployments" for more information.

2.9 User Management

2.9.1 User Creation and Provisioning

Oracle Real-Time Collaboration uses the Oracle Internet Directory store, which uses LDAP (Lightweight Directory Access Protocol), to authenticate its users. Any Oracle Internet Directory user can use Real-Time Collaboration. Users are created using the standard mechanisms available through Oracle Internet Directory.

See Also: Oracle Internet Directory Administrator's Guide for details

2.9.2 Roles

Real-Time Collaboration users can be assigned different roles. Roles determine the Oracle Web Conferencing functionality to which a user has access. There are three roles in Web Conferencing:

2.9.2.1 End-User Role

The end-user role, enduser, is the default role given to any user who logs in to the system for the first time. This role is intended for all regular users of Oracle Web Conferencing.

2.9.2.2 Business Monitor Role

The business monitor role, businessmonitor, is intended for those Oracle Web Conferencing users who want to monitor the system and have access to various reports that can be run on the system. Users with this role have access to the Monitor and Reports tabs, in addition to all end-user tabs in the Oracle Web Conferencing Application.

2.9.2.3 Business Administrator Role

The business administrator role, businessadmin, is intended for those Web Conferencing users who are in charge of administering the Web Conferencing deployment. This includes users who are responsible for supporting the end-users. Users who have this responsibility have access to the Site Management and the System Configuration tabs in the Web Conferencing Application.

2.9.3 Assigning Roles to Users

Use the imtctl command, modifyRole, to assign roles to Web Conferencing users. See Chapter 10, "imtctl Command Line Utility" for more information on imtctl.

2.10 Web Conferencing Sites

As an enterprise-class platform for real-time collaboration, Oracle Web Conferencing allows a single deployment instance to easily be configured to meet the requirements of various lines of business. This objective can be achieved by creating individual sites and customizing system, application, and conference level properties.

Note: Users with the businessadmin role can click the Sites tab in the Web Conferencing Application to access the Sites functionality.

Web Conferencing sites are created by the Web Conferencing business administrator. For every site created, the integrating application or line of business uses a unique authentication token along with site ID to communicate with the Web Conferencing Application. Creating a site provides the following benefits:

• Customized system, application, and conference properties.
• Support for custom integrated flows which can bypass the Web Conferencing Application.
• Support for custom Web Conferencing Console behavior based on the properties set for the site.
• Site-level reports that are similar to global Oracle Web Conferencing reports, except they use site-specific data.
• Custom user interfaces, including a separate Oracle Web Conferencing prelogin application page with full support for listing public conferences only for the specific site.
• Custom branding to uniquely identify the integrating site/line of business.

  Note: The global site is pre-created and cannot be deleted. By default, all users belong to site "iMeeting," which is a global site. However, a user can belong to more than one site.

2.11 Reports

Oracle Real-Time Collaboration provides various reporting capabilities, including e-mailed reports and usage trend information available within the Oracle Web Conferencing Application. Some aspects of these features require post-installation configuration, such as including sender's and receiver's e-mail addresses. See Chapter 4, "Post-Installation" for details on the properties that must be configured.

Anyone with the businessadmin or businessmonitor role can access the reports functionality by clicking the Reports tab in the Oracle Web Conferencing Application.

2.11.1 Usage Report

The usage report is designed to give high-level Oracle Web Conferencing usage metrics to business administrators and business managers. This report contains data which is based on one of the following two metrics:

• Time (minutes/hours)
• Usage numbers (count of conferences, users, and so on)

The Key Performance Indicators (KPI) are then summarized with a trending pattern that displays the count and percentage change over the previous time period. The report gives business administrators and business managers an idea of what collaborative modes and features are used, top users, and line-of-business information. The usage report is computed for a weekly period. Any user who has access to the report can view historical data in addition to the current data by keying in the relevant dates.

The following metrics are captured in the usage report:

• Conference minutes summary:
  • Total user minutes
  • Total conference minutes
  • Total voice minutes
  • Total recorded minutes
  • Total playback minutes
  • Host rating
  • Average conference length
  • Longest conference (minutes)
• Conference usage summary:
  • Conferences
  • Voice conferences
  • Total users
  • Total recordings
  • Total playbacks
  • Users in conferences
  • Voice users
  • Average users per conference
  • Largest conference (users)
• Top 10 lists
  • Users
  • Sites

In addition to the weekly KPIs table, the conference minutes and usage details are displayed in a time series of week, month, quarter, and year. The weekly average over the highest period is also computed.

2.11.2 Feedback Reports

The feedback report is designed to give high-level system performance feedback through user ratings to the business administrator and to business managers. The report contains data which is based on performance ratings given by conference hosts at the end of every conference.

The host of the conference can give a comment (raw text feedback) and can rate a conference excellent, good, or poor. The host can also decide to not rate the conference, in which case the conference is classified with no response. The KPIs are then summarized with a trending pattern displaying the count and percentage change over the previous time period.

Below the KPIs table, the top ten conferences with poor, good, excellent, and no response ratings with user comments are listed. These are grouped into four individual tables. Only conferences with host comments are listed in the tables. This convenient format allows administrators to respond proactively to the users who rate the conferences poor.

2.11.3 Uptime Reports

Oracle Web Conferencing provides tests that can be used by monitoring infrastructures to periodically monitor the system for service availability. This data can then be used to produce uptime reports. See Section 7.6, "Real-Time Collaboration Interfaces" for more information on the tests and how to integrate them with your monitoring infrastructure.