Microsoft Office Communications Server Resource Kit Chapter 5: Conferencing Scenarios (Part 2)

by [Published on 10 Jan. 2008 / Last Updated on 10 Jan. 2008]

In this section, we describe the technical details behind Office Communications Server 2007 conferencing scenarios. First, we introduce the conferencing component architecture. We then discuss the life cycle of a conference. Finally, we reveal more technical details on data collaboration conferences.

If you would like to read the other articles in this series please go to:

A WindowsNetworking.com exclusive! The following is part 2 of a 3 part series of articles that represent an entire chapter of the soon-to-be-released Microsoft Office Communications Server Resource Kit. This Resource Kit will be the definitive reference for deploying, configuring, and supporting Office Communications Server 2007 and includes lots of expert insights direct from the Microsoft Office Communications Server Team. The Resource Kit provides in-depth technical guidance concerning architecture, deployment, security, administration, performance tuning, and troubleshooting Office Communications Server 2007.

The content for these articles has been excerpted from Chapter 5 by Hao Yan of the Microsoft Office Communications Server Resource Kit by Jeremy Buch, Jochen Kunert, and Rui Maximo with Byron Spurlock, Hao Yan, James O’Neill, John Clarkson, Kintan Brahmbhatt, Mitch Tulloch, Rick Kingslan, Stephanie Lindsey, and the Microsoft Office Communications Server Team. Reprinted by permission of Microsoft Press. All rights reserved. For more information, go to http://www.microsoft.com/MSPress/books/10482.aspx.

Understanding the Conferencing Architecture

Many components participate in an Office Communications Server on-premise conference. They handle functionalities such as authentication, authorization, signaling, conference control, storage, and media mixing and processing. Figure 5-1 shows the logical component architecture for conferencing.


Figure 5-1: Conferencing component architecture

Understanding Conferencing Clients

There are two types of client conferencing applications, scheduling clients and conferencing clients.

Scheduling Client

  • A scheduling client is a client application that handles the creation, modification, or deletion of a conference. The client can also handle the scheduling aspect of a conference, such as start and end time, participant list, and recurrence. Optionally, the client can send invitation notifications for conference participants.

Conferencing Client

  • A conferencing client is a client application that can join and participate in an Office Communications Server conference. The main functionalities of a conferencing client include joining a conference, showing a list of conference participants and their status, and providing a user interface for the user to control different aspects of the conference.

The separation between a scheduling client and a conferencing client is only logical, based on the set of conferencing-related functionalities that each performs. In reality, client applications can have both scheduling and conferencing capabilities. There are three main client applications used for on-premise conferencing hosted by Office Communications Server:

Microsoft Office Live Meeting Console 2007

Microsoft Live Meeting Console 2007 is the primary conferencing client for scheduled Web conferences. It provides support for a full range of modalities that enable participants to have an effective collaborative meeting. Those modalities include the following:

  • Data collaboration, such as with PowerPoint presentations, whiteboarding, polling, shared notes, and so on. Microsoft Live Meeting Console is the only client offering that supports application sharing.
  • Audio and video. Microsoft Live Meeting Console supports real time multiparty audio and video, complete with active speaker detection and display.
  • Audio Conferencing Provider integration. Microsoft Live Meeting Console is the only client offering that supports integration between an Office Communications Server conference and a phone-based audio conference hosted by an outside Audio Conferencing Provider. The console provides user interfaces for users to control the audio conference, such as mute self, mute all, and so on.
  • In-meeting chat. Microsoft Live Meeting Console supports peer-to-peer text chat between two conference participants.

Microsoft Office Live Meeting Console 2007 is also a scheduling client. It provides a Meet Now functionality that allows users to create an instant conference and invite other participants from within the conference. The following is a screen shot of the client:

Microsoft Office Communicator 2007

Microsoft Office Communicator 2007 is the primary client application for instant communications and ad hoc collaboration. It provides the following capabilities:

  • Multiparty IM conference, based on multiple contacts in a contact list or an Active Directory Distribution Group
  • Multiparty audio/video conference
  • Seamless escalation from IM and/or audio/video conferences to Microsoft Office Live Meeting Console–based data collaboration conferences.

The following screen shot shows a group IM session in the Microsoft Office Communicator 2007 client:

Microsoft Conferencing Add-in for Microsoft Office Outlook

The Microsoft Conferencing Add-in for Microsoft Office Outlook is the primary scheduling client. The add-in allows users to use the familiar Microsoft Office Outlook interface for scheduling an Office Communications Server conference. In addition to the usual conference information that Outlook handles—such as meeting start and end time and recurrence—the add-in allows users to apply meeting settings that are specific to an Office Communications Server conference, such as meeting access type, presenter list, and audio information. It also generates a preformatted meeting invitation that contains all the necessary information for joining the conference. The meeting invitation is sent to all the invited participants via e-mail.

Users can schedule two types of conferences:

Schedule a Live Meeting

  • This option schedules a conference that will happen in the Microsoft Office Live Meeting Console 2007 client. All modalities will be provisioned for the conference.

Schedule a Conference Call

  • This option schedules a conference that will happen in the Microsoft Office Communicator 2007 client. Only computer-based audio modality is provisioned at the start of the conference. (Conference participants can add other modalities later.)

The following is a screen shot of the Microsoft Conferencing Add-in for a Microsoft Office Outlook client in action:

Understanding the Conferencing Database

In the Office Communications Server conferencing architecture, two databases (RTC and RTCDyn) provide storage for conference properties and conference state, respectively. Those databases are hosted in the SQL back-end server.

The RTC database stores persistent user data, including the contact list, access control information, and static conferencing information. Static conference properties are stored in this database from the time the conference is created until the time the conference is deleted from the server. Following is a list of included conference properties:

  • Conference identifier. The conference ID along with the SIP URI of the organizer uniquely identifies a conference.
  • Conference expiration date. This setting indicates when it is safe for the server to delete the conference automatically.
  • Conference access type—for example, open authenticated.
  • Conference access key for anonymous users.
  • Supported media types
  • A list of meeting participants and their roles.

The RTCDyn database stores transient conference state information, such as the up-to-date participant list and the roles of participants, subscription information, conference lock, and so on. That information is specific to each instance of a conference and is removed when a conference ends. It is, however, important to persist that information in a database during the conference. Doing this ensures high availability for the conference. If one server component fails or stops responding, another server with the same role can easily take over and continue to serve the same conference using information from the database.

Direct from the Source: Where Conference Scheduling Information Is Stored

The RTC database does not contain conference scheduling information. Supporting a meeting start time and end time, recurrence schedule, and exceptions to recurrence are all important for a prescheduled conference. However, that information is maintained outside of the conferencing database and Office Communications Server. Instead, conference calendar information is maintained by scheduling clients as appropriate. For example, the Microsoft Conferencing Add-in for Microsoft Outlook client saves the time information as part of a Microsoft Exchange Server calendar item.

–Hao Yan,  Senior Program Manager, OCS Server

Understanding Focus

The Focus is a conference state server that acts as the coordinator for all aspects of a conference. It is implemented as a SIP user agent that is addressable by using a conference URI. The Focus runs in the User Services module of all front-end servers. A separate instance of the Focus exists for each active conference.

The Focus is responsible for the following tasks:

  • Activating conferences
  • Enlisting required conferencing servers
  • Authenticating participants before allowing them to enter a conference
  • Managing conference participant roles and privileges
  • Authorizing conferencing control commands from participants based on the conference organizer’s meeting policy
  • Managing conference state
  • Maintaining SIP signaling relationships between conference participants and conferencing servers, providing a conduit for control commands to flow between clients and the conferencing servers
  • Accepting subscriptions to conferences, and notifying clients of changes in conference state, such as the arrival and departure of participants and the addition or removal of media

When a new media type needs to be activated for a conference, the Focus also instantiates the conference on the appropriate conferencing server, communicates with the conferencing server about adding a new user, fetches the authorization credentials so that the client can connect to that conference, and then sends the media information to the client. The same sequence is repeated for all clients who want to add this media. When a new media type is added to the conference, the sequence is repeated with the new conferencing server for that media type. By centralizing security enforcement and roster management, the Focus relieves each of the conferencing servers of this duty.

Understanding the Focus Factory

The Focus Factory is an entity that creates, deletes, and modifies meetings in the conferencing database. It is also implemented as a SIP user agent that is addressable by using a Focus Factory URI. When a client application creates a new conference, the client sends a SIP SERVICE message (which carries C3P commands as the message payload). to the Focus Factory. (See the “Understanding the Conferencing Protocols” section for more information about C3P commands.) The Focus Factory creates a new instance of the meeting in the conference database and returns information, including the conference URI, about the newly created conference to the client.

Note
The Focus Factory runs in the same process as the Focus.

Understanding Conferencing Servers and the Conferencing Server Factory

Supporting multiparty conferences requires using the conferencing server   role (also known as an MCU or multipoint control unit). Each type of conferencing server is responsible for managing one or more media types. Office Communications Server 2007 includes four conferencing servers:

Web Conferencing Server

  • Manages conference data collaboration, including native support for Microsoft Office PowerPoint presentations, Microsoft Office document sharing, whiteboarding, application sharing, polling, questions and answers (Q&As), compliance logging, annotations, meeting summaries, handouts, and various multimedia formats. The Web Conferencing Server uses the Persistent Shared Object Model (PSOM), a Live Meeting protocol, for uploading slides to a meeting.

A/V Conferencing Server

  • Provides multiparty IP audio and video mixing and relaying, by using industry standard Real-Time Protocol (RTP) and Real-Time Control Protocol (RTCP).

IM Conferencing Server

  • Enables group IM by relaying IM traffic among all participants. All messages among the participants are routed through the IM Conferencing Server.

Telephony Conferencing Server

  • Responsible for Audio Conferencing Provider (ACP) integration. Supports both dial-out and dial-in, as well as standard third-party call control features such as mute and eject.

A conferencing server consists of two logical pieces: a media controller (MC) and a media processor (MP). The MC on a conferencing server is responsible for managing the control commands between the Focus and a conferencing server. In the Office Communications Server architecture, all conference control commands are sent by clients to the Focus, which then relays these commands to the appropriate conferencing server or servers after verifying that the client that sent the request has the privileges to perform that operation.

Media is exchanged directly between clients and the conferencing server or servers. The media processor is responsible for media management, such as mixing, relaying, and transcoding (direct digital-to-digital translation from one signal encoding format to another). In a Web Conferencing Server, the media processor is a software component that is responsible for managing data collaboration. In an A/V Conferencing Server, the media processor mixes audio streams, switches video streams, and converts the media for clients who are on slow links. Of all the conferencing components, the MP can be the most CPU and network intensive component. In the Office Communications Server conferencing architecture, an MC and MP are co-located on the same machine to simplify deployment.

In a conference, when a media type needs to be added, the Focus requests a conferencing server for that media type through the Conferencing Server Factory. The Conferencing Server Factory is a lightweight logical component responsible for provisioning a conference for a particular media type on a conferencing server. The MCU Factory takes into account the current load on the conferencing servers before assigning a conferencing server to a conference. There is one MCU Factory instance on each front-end server that handles all media types.

Direct from the Source: Office Communications Server 2007 Conferencing Scale

Early in the planning phase of Office Communications Server 2007, we knew a critical decision point would be the size of meetings we supported on the server. After reviewing competitive products, speaking with customers, and mining the experience from our own Live Meeting service, it became clear that the vast majority of meetings were actually small (4 to 6 participants). Digging deeper, we discovered that 80 percent of meetings had less than 20 participants and 99.98 percent of meetings had less than 100 participants. We then polled customers to see if a figure of around 200 to 250 participants would meet their needs. We found out that it would—with the caveat that there were occasionally larger meetings, such as all-hands meetings, that would exceed this limit. We considered supporting much larger meetings but made the decision to instead focus on the typical information worker meeting (4 to 6 users) and allow room for growth up to 200 to 250 participants. Meetings larger than that would need to take advantage of the Live Meeting hosted service, which can scale beyond 1000 participants in a meeting. Apart from the raw server scaling characteristics of such meetings, it was clear from our own operational experience that it takes dedicated staff and processes to make such large meetings effective. In essence, it is a different solution altogether if done properly.

How We Have Tested That Goal

Our user model for performance testing of conferencing takes into account a number of factors:

  • How many users are on the pool
  • The effective concurrency rate for meetings
  • The media types (mixes) that are available for each meeting
  • Where users come from: inside the enterprise, outside the enterprise, federated, or anonymous

To determine the number of meetings we test with, we take the total number of users (for example, 50,000) and multiply by a concurrency rate (for example, 5%). That gives us the number of users we expect to be in a meeting at any given time (in this example, 2500 users). We can then divide this by the number of conferencing servers in the deployment (for example, 2), and that gives us a figure for the number of participants per conferencing server (in this case, 1250). We can then divide that number by the average meeting size (for example, 6), and that gives us the average number of meetings per conferencing server (in this example, ~ 210). We test a variety of meeting sizes to ensure the server scales appropriately. This calculation represents an average load that we test.

One specific test we do is to ensure that we can indeed support a meeting with up to 250 participants. This includes audio, video, and data. In that test, we run one such large meeting on a given conference server (a multipoint control unit, or MCU). We do not attempt to run multiple such meetings on a single conference server. The reason we don’t do this goes back to our data, which indicates that these type of meetings are relatively rare.  

No Magic Numbers

When you see numbers like 250 (the largest meeting size), 1250 (the number of users on a single conferencing server), and so on, it can be easy to think that these are hard-coded values. But there really are no such magic numbers in our software. Rather, these numbers represent the capacity we have tested for given a particular user model and a particular set of hardware. (All of this can be found in the Planning Guide for Office Communications Server 2007.) Let me repeat that: you will not find the number 250 hard-coded in our server. We do have a notion of the maximum number of participants in a meeting that is controlled by the administrator through meeting policy. This is an administrator policy that can be set either through the Microsoft Management Console (MMC) or Windows Management Instrumentation (WMI). (More details can be found in the deployment documentation which can be found at http://technet.microsoft.com/en-us/library/bb676082.aspx.)

If you take a look at these policies in MMC, you will note that the default is actually much lower than 250. This is not by accident. It is assumed that users who are allowed to create such large meetings are privileged users and therefore have a nondefault policy. Meeting policies apply to the organizer of the meeting. Some organizers might be allowed to have 200-person meetings; others might be allowed to have only 10 people in a meeting. This is an administrator decision, which our software will enforce.

Pushing the Limits

If 250 is not hard-coded in the server software, you might logically wonder what happens when you exceed this limit. First let me explain how aConferencing Server manages its load dynamically. When the first user joins a meeting, a conferencing server for the appropriate media type or types is allocated. (See the “Understanding Conferencing Servers and the Conferencing Server Factory” section later in this chapter for an explanation of conferencing servers and a list of available types in Office Communications Server 2007.)The conferencing server that is allocated comes from a set of conferencing servers associated with the pool.

In the preceding example, there are two web conferencing servers in a pool for 50,000 users. Each conferencing server is responsible for managing its load and reporting its ability to host additional meetings. If a conferencing server has exceeded its capacity, it can report this and the pool will allocate a different conferencing server. This is all done in real-time at the time of the meeting; we do not reserve resources in advance. We also do not prioritize certain meetings over others when allocating resources. A large 250-person meeting is likely to take up the resources of a single conferencing server, and other meetings will be allocated on other conferencing servers in that pool. So, say that you have a large meeting with 250 people on a single conferencing server and the 251st user tries to join that meeting. If the meeting policy allows this and the conferencing server has spare capacity, the user will be allowed to join. This test is performed for each user that joins, and it is possible for two large meetings to compete for resources on the same conferencing server. Smaller meetings are easier to pack into the same server because each requires fewer resources.

The capacity of the conferencing servers is gated by CPU and memory, for the most part. We test and recommend dual-processor/dual-core servers with 4 GB of memory. If you use more powerful hardware, you will have more capacity and be able to host larger meetings. This is not just theoretical; we deploy larger servers in our Live Meeting service to scale to larger audio/video meeting sizes. You can as well. Our hardware recommendation was chosen based on a reasonable balance of cost vs. typical usage (again, 99.98 percent of meetings have fewer than 100 users). Achieving as many as 1000 participants in a meeting is possible given the right hardware; it simply has not been a goal of the Office Communications Server 2007 release and is not something we directly support at this time.

Keep in mind, though, that there is more than server scale at issue here, do you have the right support and processes in place to make a 1000-user meeting successful? Supporting a meeting of this size typically means having dedicated IT staff on hand to deal with any support calls or “operator assistance” needs, as well as having the infrastructure to manage invitations, follow-up on problems, distribute handouts, and so on. You also need to ensure that you have the appropriate network infrastructure in place with the required bandwidth to host such a large meeting. 

Proper monitoring and capacity planning will ensure that you have the right hardware to scale to your needs. As your needs change, you can add more conferencing servers (or front-end servers in the consolidated topology) to meet your growing needs.

Recommendations for Larger Meeting Sizes

Here are a few recommendations if you want to push the limit on the meeting size:

  • Create a dedicated meeting policy for those (limited) organizers authorized to host such large meetings.
  • Ideally, create a dedicated pool for those organizers so that you can dedicate hardware resources particularly for these meetings. This is one form of resource reservation.
  • Invest in the support infrastructure needed to make these meetings run smoothly (people, processes, network, and hardware)

– Sean Olson, Principal Group Program Manager, OCS Server

Understanding Web Components

Web Components are the set of ASP.NET applications and virtual directories that are created on Internet Information Services (IIS) during the deployment of Office Communications Server 2007. The Web components support the following functionalities:

  • The data collaboration content of a conference is hosted using the conf web component in encrypted format. The Web Conferencing Server instructs clients to download the content through HTTPs and provide an encryption key to the client for decryption.
  • The Office Communicator client uses IIS to download Address Book Server files when the client is outside the corporate firewall.
  • An ASP.NET application running on top of IIS is used for the Group Expansion Web Service.
  • An ASP.NET application running on top of IIS is used for the Web Scheduler Resource Kit tool, which is a Web-based scheduling solution.

Understanding Process and Machine Boundaries for Conferencing Components

Figure 5-2 shows the machine and process boundaries for all the conferencing components that we discussed in previous sections.


Figure 5-2: Conferencing component process and machine boundary

The Focus, Focus Factory, Conferencing Server Factory, IM Conferencing Server, and Telephony Conferencing Server all run as part of the front-end server. They cannot be separated and installed on different machines.

The Web Conferencing Server and the A/V Conferencing Server can be run on the same machine as the front-end server (in an Office Communications Server 2007 Standard Edition or Enterprise Edition consolidated topology). However, they can also be a separate server role and installed on their own hardware (Office Communications Server 2007 Enterprise Edition expanded topology). This configuration allows enterprises to scale out their Office Communications Server 2007 deployment by deploying as many conferencing servers as necessary to meet their usage model. The host for Web components (IIS) can be installed as part of every Office Communications Server 2007 Standard Edition server or Enterprise Edition consolidated topology server, or as a separate Web farm behind a hardware load balancer in the Enterprise Edition expanded topology.

Understanding Edge Servers

Office Communications Server 2007 allows enterprise users working outside the enterprise network to participate in on-premise conferences. In addition, it also enables enterprise users to invite federated users and anonymous users to participate in on-premise conferences. Enabling conferencing and the ability to share data and media with users outside the corporate firewall requires the following four server roles in the perimeter network:

Access Edge Server

  • Formerly known as the Access Proxy, the Access Edge Server handles all SIP traffic across the corporate firewall. The Access Edge Server handles only the SIP traffic that is necessary to establish and validate connections. It does not handle data transfer, nor does it authenticate users. Authentication of inbound traffic is performed by the Director or the front-end server.

Web Conferencing Edge Server

  • The Web Conferencing Edge Server proxies PSOM traffic between the Web Conferencing Server and external clients. External conference traffic must be authorized by the Web Conferencing Edge Server before it is forwarded to the Web Conferencing Server. The Web Conferencing Edge Server requires that external clients use Transport Layer Security (TLS) connections and obtain a conference session key.

A/V Edge Server

  • The A/V Edge Server provides a single trusted connection point through which inbound and outbound media traffic can securely traverse network address translators (NATs) and firewalls. The industry-standard solution for multimedia traversal of firewalls is Interactive Connectivity Establishment (ICE), which is based on the Simple Traversal Underneath NAT (STUN) and Traversal Using Relay NAT (TURN) protocols. The A/V Edge Server is a STUN server. All users are authenticated to secure both access to the enterprise and use of the firewall traversal service that is provided by the A/V Edge Server. To send media inside the enterprise, an external user must be authenticated and must have an authenticated internal user agree to communicate with him or her through the A/V Edge Server. The media streams themselves are exchanged by using Secure Real-Time Protocol (SRTP), which is an industry standard for real-time media transmission and reception over IP.

HTTP Reverse Proxy

  • Office Communications Server 2007 conferencing support for external users also requires deploying an HTTP reverse proxy in the perimeter network for the purpose of carrying HTTP and HTTPS traffic to the Web components (IIS) for external users.

Figure 5-3 shows the conferencing component architecture with edge servers.


Figure 5-3: Conferencing component architecture with edge servers

Understanding the Conferencing Protocols

This section discusses various protocols for the communication between different components in the conferencing architecture. On a high level, there are two classes of protocols involved in an on-premise conference: signaling and media.

Signaling Protocols

Signaling protocol refers to protocols that facilitate session establishment, capability exchange, state exchange, and conference control.

Session Initiation Protocol (SIP) is the primary signaling protocol used by Office Communications Server. SIP is the industry-standard protocol described in Internet Engineering Task Force (IETF) RFC 3261, which defines a standard way to perform session setup, termination, and media negotiation between two parties.

The SIP NOTIFY/BENOTIFY methods are used to convey changes in conference state. Conference state describes the various entities associated with a conference. It is described using the IETF RFC Conference Event (http://www.ietf.org/rfc/rfc4575.txt) package.

Various conference control and state modification tasks are achieved using C3P protocol. C3P stands for Centralized Conferencing Control Protocol. It is an XML-based protocol that provides a thin wrapper around the Conference Event package and also provides various media-specific extensions. C3P commands can be carried through SIP INFO or SERVICE methods. In general, C3P commands can be classified into three categories:

  • Commands that terminate on the Focus and do not involve conferencing server interaction (for example, renameUser)
  • Commands that are authorized by the Focus but are simply proxied to conferencing servers, so no Focus state is modified unless the conferencing server generates a notification (for example, modifyEndpointMedia)
  • Commands that are processed by the Focus as well as by conferencing servers (for example, deleteConference, modifyConferenceLock)

The Focus and conferencing servers communicate using C3P and use HTTPS as the carrier protocol for C3P. Clients communicate with Focus and Focus Factory using SIP INFO or SERVICE methods. SIP INVITE, ACK, BYE, UPDATE, and CANCEL methods are used to establish a signaling dialog between a conferencing client and the Focus. The client signals conferencing servers with the corresponding supported protocols: SIP for the IM Conferencing Server, Telephony Conferencing Server, and A/V Conferencing Server; and PSOM for the Web Conferencing Server. 

Media Protocols

Media protocol refers to protocols that facilitate exchange of specific types of media between clients and a conferencing server.

The Web Conferencing Server uses PSOM, a Live Meeting protocol, for exchanging data collaboration content and control with conferencing clients. The concept of a distributed object is central to PSOM Operations. A distributed object is a set of two interfaces: one interface for the object’s client side, and one interface for the object’s server side. Protocol messages are mapped to methods of these interfaces. The client interface contains messages sent to the client side of a connection. The server interface contains messages sent to the server side of a connection.

The IM Conferencing Server uses the Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions (SIMPLE) to communicate with IM conferencing clients. SIMPLE is an open standard defined by IETF RFC 3428 (http://tools.ietf.org/html/rfc3428).

RTP/RTCP is standard protocol employed by the A/V Conferencing Server to exchange audio and video streams with conferencing clients. RTP defines a standardized packet format for delivering audio and video over the Internet. RTCP provides out-of-band control information for an RTP flow. In Office Communications Server, all communications are encrypted. The A/V Conferencing Server actually uses the SRTP/SRTCP protocol, which provides encryption over RTP/RTCP.

Figure 5-4 provides an overview of how the various conferencing protocols interact with different Office Communications Server components.


Figure 5-4:
Conferencing protocols

Understanding the Conference Life Cycle

Each Office Communications Server conference has the life cycle shown in Figure 5-5. A conference is created by a scheduling client via the Focus Factory. The conference can be activated/joined and deactivated at any time after it is created and after it is cleaned up (has expired) from the server. The conference expires only after the specified expiration date has passed.


Figure 5-5: Conference life cycle

Understanding Conference Creation

An Office Communications Server 2007 conference can be created in one of the following ways:

  • By scheduling a Web conference or conference call from the Microsoft Conferencing Add-in for Microsoft Outlook
  • By creating a multiparty IM or A/V conferencing session from the Office Communicator 2007 client
  • By using the Share Information Using Live Meeting option in the Office Communicator 2007 client
  • By creating an ad hoc meeting by using the Meet Now functionality of the Microsoft Office Live Meeting 2007 client
  • By scheduling a Web conference or audio conference by using the Web Scheduler Resource Kit tool

In all the preceding scenarios, the scheduling client communicates with the Focus Factory, which actually creates records in the conferencing database. Only authenticated enterprise users who are home on an Office Communications Server 2007 pool can create conferences. The key inputs to the Focus Factory include the following:

  • Organizer SIP URI, which is the SIP URI that identifies the organizer of the conference.
  • Conference Id, which is an alpha-numeric string that identifies the conference. The Conference Id has to be unique for the same organizer.
  • Subject, which is the subject of the conference. This is used for display in the conferencing client.
  • Conference access type, which can be Open/Closed Authenticated or anonymous allowed.
  • Conference key, which is an alpha-numeric string that is used to authenticate anonymous users.
  • Participant list and roles.
  • Expiration time. The scheduling client can specify an optional expiration time at which it is safe to delete the conference completely from Office Communications Server.
  • Provisioned conferencing servers. This specifies the type of media that is required in the conference.
  • Conferencing server specific information, such as numbers to dial in for the Telephony Conferencing Server.

The key output from the Focus Factory is the conference URI. A conference URI is a globally unique identifier that represents the conference. A sample conference URI is shown here:

sip:ben@contoso.com;gruu;opaque=app:conf:focus:id:5D3747C1DEEB684B8962F4078723A65A

The opaque parameter identifies the type of the resource that has generated or owns this URI. For a conference URI, this is always the Focus component, and hence the opaque parameter of the URI always contains the app:conf:focus prefix. The conference URI also contains the organizer SIP URI and the conference ID, which together uniquely identify the conference.

The conference URI is used by the scheduling clients to construct a conference join URL. For Microsoft Office Live Meeting Console–based conferences, a meet: URL is used—for example:

meet:sip:ben@contoso.com;gruu;opaque=app:conf:focus:id:5D3747C1DEEB684B8962F4078723A65A

For Microsoft Office Communicator–based audio-only conferences, a conf: URL is used—for example:

conf:sip:ben@contoso.com;gruu;opaque=app:conf:focus:id:a291a144d9764f38973835f816e52db1
%3Fconversation-id=b2796a94efe040cb9afadc49157557e6

Understanding Conference Activation

A conference is activated when the first participant successfully joins the meeting. The first user who joins the meeting can be an enterprise user, a federated user, or an anonymous user. Users are allowed to join the meeting regardless of their presenter or attendee role. A conference can be activated any time after it is created and before it is permanently deleted from the conferencing database.

The following happens when a conference is activated:

1. An instance of the meeting, called the Focus, is created on the Office Communications Server front-end server. This conference instance maintains the following instance-specific pieces of information:

  • A list of participants in the conference that includes the following:
  • Participants connected to the Focus
  • Participants connected to each conferencing server
  • State for each Server

2. A SIP dialog between client and the Focus is established; the conference event subscription/publication is established.

3. The Focus provisions a conferencing server of each required media type in the conference. This information is specified when the conference is created.

4. An addConference C3P command is sent to all provisioned conferencing servers. Each conferencing server allocates resources for the conference and becomes ready for the conference.

5. The client establishes a direct connection with each provisioned conferencing server.

Understanding Conference Deactivation

A meeting is deactivated when the Focus instance of the conference is removed from the front-end servers. A conference can be deactivated any time after it is activated in the following ways:

  • The organizer or a presenter manually ends the meeting.
  • All participants leave the meeting.
  • Twenty-four hours (the default) pass since the last participant joined the meeting.
  • Ten minutes (the default) pass without an authenticated enterprise user being in the meeting.
  • An administrator disables the meeting organizer for Office Communications Server or deletes the meeting organizer’s user account from Active Directory.

The following happens when a conference is deactivated:

  1. The instance of the conference, the Focus, is removed. All associated instance-specific information is removed from memory and from the RTCDyn conferencing database.
  2. All client-Focus dialogs are ended.
  3. All conferencing servers involved in the conference receive a deleteConference C3P command from the Focus.
  4. All client–conferencing server dialogs are ended. All remaining attendees are disconnected. All resources that are allocated for the conference from all conferencing servers are released.

A deactivated conference still exists in the RTC conferencing database and can be reactivated at any time until the meeting expires as described in the following section.

Understanding Conference Expiration

To save disk space and improve performance, Office Communications Server does not store conferences and their content indefinitely. When a conference is created, the conference is given an expiration time. When a conference expires, the conference data record is deleted from the back-end conferencing database and all content data associated with the meeting is deleted. After a meeting expires, no participants, including the organizer, can join the meeting.

The front-end server runs a low-priority expiration thread for the RTC database. When woken up, the thread searches for conferences that meet all of the following criteria:

  • There is an expiration time associated with the conference, and the expiration time has passed; or there is no expiration time associated with the conference, and six months have passed since the last recorded conference activation.
  • The conference is not currently active.

Any meetings that satisfy the preceding criteria are deleted from the RTC database.

It is up to the scheduling client to specify the expiration time when creating a conference on the server. The expiration time is communicated to each conferencing server that is involved when the conference is activated. Here are some recommendations based on the conference type:

  • For one-time scheduled conferences, set the expiration time to be the scheduled end time plus 14 days.
  • For recurring scheduled conferences with an end date, set the expiration time to be the scheduled end time of the last occurrence plus 14 days.
  • For recurring scheduled conferences without specified end dates, do not set an expiration time or set null as the expiration time.
  • For ad hoc IM or A/V conferences, set the expiration time to be eight hours.

Note
If no expiration time is specified by the client, the maximum grace period (six months) allowed by the server is used as the expiration time. This maximum allowed grace period is reset whenever a conference is activated. For example, after a conference is activated and deactivated, it will expire in six months. After three months, the meeting is activated again, and then the conference will expire in another six months, not three months.

Similarly, the Web Conferencing Server also runs a low-priority expiration thread similar to the one that runs on the front-end server. When woken up, the thread scans the conference content metadata file share and checks for the expiration time for each conference. The Web Conferencing Server adds a grace period (by default 14 days) on top of the expiration time. It deletes the content folder associated with a conference only if the conference expiration time plus the grace period has passed. (to be continued)

If you would like to read the other articles in this series please go to:

Featured Links