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.
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.
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:
The following image 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:
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 by using information from the database.
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
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.
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.
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.
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.
Figure 5-2 shows the machine and process boundaries for all the conferencing components that we discussed in previous sections.
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.
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.
This section discusses various protocols for the communication between different components in the conferencing architecture. On a high level, there are two clas asses 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 by 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 protocols 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.
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.
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:[email protected];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:[email protected];gruu;opaque=app:conf:focus:id:5D3747C1DEEB684B8962F4078723A65A
For Microsoft Office Communicator–based audio-only conferences, a conf: URL is used. For example:
conf:sip:[email protected];gruu;opaque=app:conf:focus:id:a291a144d9764f38973835f816e52db1 %3Fconversation-id=b2796a94efe040cb9afadc49157557e6
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:
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
A SIP dialog between client and the Focus is established; the conference event subscription/publication is established.
The Focus provisions a conferencing server of each required media type in the conference. This information is specified when the conference is created.
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.
The client establishes a direct connection with each provisioned conferencing server.
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:
The instance of the conference, the Focus, is removed. All associated instance-specific information is removed from memory and from the RTCDyn conferencing database.
All client-Focus dialogs are ended.
All conferencing servers involved in the conference receive a deleteConference C3P command from the Focus.
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.
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.
In this section, we discuss some technical details of data collaboration conferences and Web conferences. In particular, this section covers technical details of the following scenarios:
A user can join a conference primarily in two ways:
Figure 5-6 illustrates the client conference join process.
Both Microsoft Office Communicator 2007 and Microsoft Office Live Meeting Console 2007 clients register an operating system protocol handler when they are installed. Microsoft Office Communicator 2007 registers a protocol handler for the conf: protocol. Microsoft Office Live Meeting Console 2007 registers a protocol handler for the meet: protocol. When users click the Join link in an invitation e-mail or in the IM conversation window, the client that will launch depends on the conf: or meet: prefix of the join URL.
The first step that the conferencing client performs after launch is to discover Office Communications Server for the user, based on the configured user SIP URI in the client. This discovery logic performs a series of DNS SRV queries based on the domain portion of the user's SIP URI. The following four cases could result from the DNS SRV queries:
An Office Communications Server is found, and it is the server that hosts the conference. In this case, the client sends the join SIP INVITE targeted at the server. The user joins as an enterprise authenticated user.
An Office Communications Server is found, and the server is federated with the Office Communications Server that hosts the conference. In this case, the client sends the join SIP INVITE targeted at the Office Communications Server 2007 server that hosts the conference. The user is authenticated by the Office Communications Server 2007 server in her own domain, and the SIP INVITE is successfully routed to the Office Communications Server pool that hosts the conference. The user joins as a federated user.
An Office Communications Server 2007 server is found, and the server is federated with the Office Communications Server 2007 server that hosts the conference. In this case, the client sends the join SIP INVITE targeted at the Office Communications Server 2007 server that hosts the conference. The user is authenticated by the Office Communications Server 2007 server in her own domain. However, the SIP invite cannot be successfully routed because there is no federated link between her own Office Communications Server domain and the conference organizer's Office Communications Server domain (indicated by the SIP 504 response to the SIP INVITE). In this case, the conferencing client will try to join the conference as an anonymous user. The conferencing client must be able to generate a sufficiently unique and random anonymous SIP URI of the form <ID>@anonymous.invalid when joining a conference as an anonymous participant.
An Office Communications Server 2007 server is not found. In this case, the conferencing client will try to join the conference as an anonymous user. The conferencing client must be able to generate a sufficiently unique and random anonymous SIP URI of the form <ID>@anonymous.invalid when joining a conference as an anonymous participant.
The SIP INVITE that the client sends has an addUser C3P command as the body of the SIP message. Following is an example:
INVITE sip:[email protected];gruu;opaque=app:conf:focus:id: 5D3747C1DEEB684B8962F4078723A65A SIP/2.0 From: <sip:[email protected]>;tag=958d8a3fbc;epid=c5574cd6b6 To: <sip:[email protected];gruu;opaque=app:conf:focus:id:5D3747C1DEEB684B8962F4078723A65A> Content-Type: application/cccp+xml Content-Length: 736 <request C3PVersion="1" to="sip:[email protected];gruu;opaque=app:conf:focus:id: 5D3747C1DEEB684B8962F4078723A65A" from="sip:[email protected]" requestId="0"><addUser><conferenceKeys confEntity="sip:[email protected];gruu;opaque=app:conf:focus:id: 5D3747C1DEEB684B8962F4078723A65A"/> <ci:user entity="sip:[email protected]"> <ci:roles> <ci:entry>attendee</ci:entry> </ci:roles> <ci:endpoint entity="{339F927D-6AD4-4090-9104-8414B99EE045}" /> </ci:user></addUser></request>
The addUser request contains the conference URI and the user SIP URI, which must be the same as the SIP To and From URIs, respectively. In addition, it can contain a requested role. The endpoint entity is optional, and the Focus ignores the body of the endpoint entity and just uses the entity URI supplied by the client.
Figure 5-7 shows the server handling logic for such an SIP join INVITE.
When the addUser C3P command is accepted, the Focus responds with the granted role in the 200 response:
SIP/2.0 200 Invite dialog created Contact: <sip:sip.contoso.com:5061;transport=tls>;isfocus Content-Length: 1095 From: "Ben Miller"<sip:[email protected]>;tag=958d8a3fbc;epid=c5574cd6b6 To: <sip:[email protected];gruu;opaque=app:conf:focus:id: 5D3747C1DEEB684B8962F4078723A65A>;tag=CC020080 Allow: INVITE, BYE, ACK, CANCEL, INFO, UPDATE Content-Type: application/cccp+xml <response requestId="0" C3PVersion="1" from="sip:[email protected];gruu;opaque=app:conf:focus:id: 5D3747C1DEEB684B8962F4078723A65A" to="sip:[email protected]" code="success"><addUser><conferenceKeys confEntity="sip:[email protected];gruu;opaque=app:conf:focus:id: 5D3747C1DEEB684B8962F4078723A65A"/> <ci:user entity="sip:[email protected]"> <ci:roles> <ci:entry>presenter</ci:entry> </ci:roles> </ci:user></addUser></response>
At this point, the signaling dialog is successfully established between the joining client and the Focus. The Focus then notifies existing conference participants that the user has joined the conference.
NOTIFYsip:157.56.67.50:2383;transport=tls;ms-opaque=02e9ae1f28; ms-received-cid=00031600;grid SIP/2.0 To: <sip:[email protected]>;tag=ccb81c3509;epid=c5574cd6b6 Content-Length: 2373 From: <sip:[email protected];gruu;opaque=app:conf:focus:id:5D3747C1DEEB684B8962F4078723A65A>;tag =183C0080 Content-Type: application/conference-info+xmlEvent: conference subscription-state: active;expires=3600<conference-infoentity="sip:[email protected];gruu;opaque=app:conf:focus:id: 5D3747C1DEEB684B8962F4078723A65A" state="partial" version="2"> <users state="partial"> <user entity="sip:[email protected]" state="full"> <display-text>Ben Miller</display-text> <roles> <entry>presenter</entry> </roles> <endpoint entity="{339F927D-6AD4-4090-9104-8414B99EE045}" msci:session-type="focus" msci:endpoint-uri="sip:[email protected];opaque=user:epid:AD0UTS5DclOh9zyK1XWK2AAA;gruu"> <status>connected</status> </endpoint>
After a SIP signaling dialog is successfully established, the conferencing client and the Focus establish a subscription dialog. The client first sends a SIP SUBSCRIBE:
SUBSCRIBE sip:[email protected];gruu;opaque=app:conf:focus:id: 5D3747C1DEEB684B8962F4078723A65A SIP/2.0 From: <sip:[email protected]>;tag=958d8a3fbc;epid=c5574cd6b6 To: <sip:[email protected];gruu;opaque=app:conf:focus:id:5D3747C1DEEB684B8962F4078723A65A> Event: conference Accept: application/conference-info+xml Supported: com.cotoso.autoextend Supported: ms-benotify Proxy-Require: ms-benotify Supported: ms-piggyback-first-notify Content-Length: 0
The Focus then processes the subscription. If no corresponding active signaling dialog is found, the Focus fails the subscription. Once the subscription is accepted, the Focus responds to it, and then generates a notification.
SIP/2.0 200 OK
Content-Length: 3611
From: "Ben Miller"<sip:[email protected]>;tag=0dc4a6c3d2;epid=c5574cd6b6
To: <sip:[email protected];gruu;opaque=app:conf:focus:id:
A24F0AA5223B4B478801FA8F60D2191D>;tag=31740080
Expires: 3546
Content-Type: application/conference-info+xml
Event: conference
subscription-state: active;expires=3546
ms-piggyback-cseq: 1
Supported: ms-benotify, ms-piggyback-first-notify
...The subscription dialog is periodically refreshed. The lifetime of the subscription dialog is the same as the lifetime of the signaling dialog. Even though these are two independent dialogs, the Focus terminates the subscription dialog when the signaling dialog is terminated.
After both the signaling and subscription dialogs are established, the conferencing client can receive conference state change notifications, such as another user join, from the Focus. Figure 5-8 illustrates the client focus join sequence.
The addUser C3P command is used by conferencing clients to join themselves to the conferencing servers involved in the conference. The addUser command works in two modes: dial-in and dial-out. In dial-in mode, the client sends addUser to the conferencing server (with the message being proxied by the Focus) to request permission to create a session with it. In the addUser response, the conferencing server responds with connection information that is used by the client to establish signaling and media sessions. In addUser dial-out mode, the client requests that the conferencing server initiate the signaling/media session establishment, and hence, the addUser command completes only after the session is established.
Conferencing clients use the addUser dial-in mode to join the Web Conferencing Server. Figure 5-9 illustrates the flow for a client to join the Web Conferencing Server.
Some of the notifications that conferencing clients receive from the Focus after they join a conference are about conferencing server URIs. For example:
NOTIFY sip:[email protected] SIP/2.0 ... <conference-info xmlns="urn:ietf:params:xml:ns:conference-info" entity="sip:[email protected];gruu; opaque=app:conf:focus:id:5D3747C1DEEB684B8962F4078723A65A" state="full" version="5" > <conference-description> <display-text>Weekly Sales Meeting</display-text> <subject>Agenda: This month's goals</subject> <conf-uris> <entry> <uri>sip:[email protected];opaque=conf:meeting: id:5D3747C1DEEB684B8962F4078723A65A</uri> <display-text>meeting</display-text> <purpose>meeting</purpose> </entry> <entry> <uri>sip:[email protected];opaque=conf:audio-video: id:5D3747C1DEEB684B8962F4078723A65A</uri> <display-text>audio video mcu</display-text> <purpose>audio-video</purpose> </entry> </conf-uris> </conference-description> ... </conference-info>
To join the Web Conferencing Server, the client then constructs an addUser C3P request and sends it to the Focus requesting to dial in to the Web Conferencing Server. The request contains a role that matches the current role of the user in the conference, specifies a joining-method value of dialed-in, and also supplies an endpoint that is usually a GUID for the session. The From URI of the SIP request must match the from attribute of the C3P request. An mcuUri attribute must be present in the addUser element, and it specifies the MCU (conferencing server) to which this request should be routed. In the case just shown, the Web Conferencing Server URI is as follows:
sip:[email protected];opaque=conf:meeting:conf-id
Here is an example of this addUser C3P request:
INFO ConfURI To: ConfURI From: sip:[email protected];tag=f7588dc66124429ab736;epid=1 ...SIP headers.. <request xmlns="urn:ietf:params:xml:ns:cccp" requestId="2" from="sip:[email protected]" to="sip:[email protected];gruu; opaque=app:conf:focus:id:5D3747C1DEEB684B8962F4078723A65A"> <addUser mscp:mcuUri="sip:[email protected];opaque=conf:meeting: id:5D3747C1DEEB684B8962F4078723A65A"> <conferenceKeys confEntity=" sip:[email protected];gruu; opaque=app:conf:focus:id:5D3747C1DEEB684B8962F4078723A65A"> <user entity="sip:[email protected]"> <roles> <entry>presenter</entry> </roles> <!-Exactly one endpoint node may be present --> < endpoint entity=" {F43E937E-6C66-4649-9481-13133FCF64FE}"> <!-Exactly one joining-method and it must be equal to dialed-in --> <joining-method>dialed-in</joining-method> <!-- Optional MCU specific parameters --> </endpoint> </user> </addUser> </request>
The Focus forwards the dial-in request to the Web Conferencing Server after stamping the request with the originator URI and proper authorization. If the Web Conferencing Server decides to accept the C3P request, it should construct a standard addUser response and return it to the Focus, which will then proxy the response to the client.
All conferencing servers must supply contact information that the client can use to connect. For conferencing servers that use SIP as a signaling protocol (such as the A/V Conferencing Server), this takes the form of supplying a SIP Contact URI and SIP To URI. The SIP To URI must always be equal to the mcuUri supplied in the addUser call. The SIP Contact URI refers to the Conferencing Server URI (a listening address/port/transport on which the conferencing server is listening and can receive SIP requests). For a Web Conferencing Server that uses PSOM instead of SIP, this takes the form of supplying a suitable URL that the client understands.
Some conferencing servers might supply an authorization token or some other parameter to the client. The semantics of such parameters are a contract between the conferencing server and the client. Following is an sample response to the addUser request to join a Web Conferencing Server:
From: < sip:[email protected];gruu; opaque=app:conf:focus:id:5D3747C1DEEB684B8962F4078723A65A>; tag=052B0080 To: <ben:[email protected]>;tag=d1991b44ef;epid=10caaf88e2 ... <response from=" sip:[email protected];gruu; opaque=app:conf:focus:id:5D3747C1DEEB684B8962F4078723A65A" to="sip:[email protected]" responder=" sip:[email protected]; opaque=conf:meeting: id:5D3747C1DEEB684B8962F4078723A65A" code="success"> <addUser><conferenceKeys confEntity=" [email protected];gruu; opaque=app:conf:focus:id:5D3747C1DEEB684B8962F4078723A65A"/> <user xmlns="urn:ietf:params:xml:ns:conference-info" entity="sip:[email protected]"><display-text>Hao Yan</display- text><roles><entry>presenter</entry></roles><endpoint entity="{1D3F15F1-68CA-4EF0-9805- 704EB5795F60}"><joining-method>dialed-in</joining-method><media id="1-id002"><type>meeting</ type><label>meeting</label></media><authMethod xmlns="http://schemas.microsoft.com/rtc/ 2005/08/confinfoextensions"> enterprise</authMethod><accessMethod xmlns="http://schemas.microsoft.com/rtc/2005/08/ confinfoextensions"> internal</accessMethod> </endpoint></user><info xmlns="http://schemas.microsoft.com/rtc/2005/08/ cccpextensions"><contact>pod/ben/check/check1.html</contact></info><connection-info xmlns="http://schemas.microsoft.com/rtc/2005/08/cccpextensions"><entry><key>serverURL</ key><value>https://conference.contoso.com/etc/place/null</value></ entry><entry><key>pw.eName</key><value>sip:[email protected];gruu; opaque=app:conf:focus:id:5D3747C1DEEB684B8962F4078723A65A </value></ entry><entry><key>PodName</key><value> [email protected];gruu; opaque=app:conf:focus:id:5D3747C1DEEB684B8962F4078723A65A</value></ entry><entry><key>pwuid</key><value>sip:[email protected]</value></ entry><entry><key>sAuthId</key><value>71C00000000000001A36B1629961D219</value></ entry><entry><key>pwrpc.modes</key><value>tls</value></entry><entry><key>pwrpc.port</ key><value>8057</value></entry><entry><key>pwrpc.authPattern</ key><value><sAuthId></value></entry><entry><key>pw.rtcp.enabled</ key><value>false</value></entry><entry><key>pwrpc.tcpEnableSig</key><value>false</ value></entry><entry><key>locale</key><value>en_US</value></ entry><entry><key>directURL</key><value>https://conference.contoso.com:8057</value></ entry><entry><key>pwrpc.pwsURI</key><value>https://conference.contoso.com:8057</value></ entry><entry><key>uType</key><value>pre</value></entry><entry><key>alternativeName</ key><value>conference.contoso.com</value></entry></connection-info></addUser></response>
The information included in the C3P response includes the following:
The Fully Qualified Domain Name (FQDN) or IP address of the Web Conferencing Server and port number.
The URL for HTTPs content download.
Access information (FQDN and port) for zero, one, or more Web Conferencing Edge Servers if the client connects from outside of the corporate firewall.
An authorization cookie for the Web Conferencing Edge Server if the client connects from outside of the corporate firewall. The cookie is base64 encoded. The client needs to present this cookie when establishing a connection with the Web Conferencing Edge Server.
An authorization cookie for the Web Conferencing Server. This cookie is also encoded in base64. The client needs to present this cookie when establishing a connection with the Web Conferencing Server.
A unique identifier for the meeting (for example, the Conference URI). This is necessary for the client to identify which conference it is joining when making a connection to the Web Conferencing Server.
Once a signaling dialog is established with the Focus, clients can send conference control CP commands on the dialog. In general, conference control commands can be classified into three categories:
Commands that terminate on the Focus and do not involve MCU interaction (for example, renameUser)
Commands that are authorized by the Focus but are simply proxied to MCU, so no Focus state is modified unless the MCU generates a notification (for example, modify-EndpointMedia)
Commands that are processed by the Focus as well as by MCUs (for example, delete-Conference and modifyConferenceLock)
A typical conference control command operates as follows:
The client sends a SIP INFO request to the Focus, with the body containing a C3P command.
The Focus operates on the C3P request and generates one or more SIP responses back to the client containing C3P pending or a final response.
The Focus might proxy or fork the request to one or more conferencing servers as necessary. Responses from the conferencing servers are proxied back to the client except in the forking-command case, where they are consumed by the Focus.
All entities maintain C3P transaction timers to control the lifetime of the request.
When the Focus accepts the command from the sender, it usually generates a C3P request to the conferencing servers in the conference and also responds with a SIP 202 Accepted message to the INFO request. When the C3P result is available, the Focus generates another INFO request and sends it to the client. The C3P request might succeed or fail or might succeed/fail after an interim response has been generated. Moreover, a successful C3P request is usually followed by the conferencing servers sending a C3P notification containing the updated conference state. On receipt of this notification, the Focus updates the conference state and generates a notification to all clients.
Figure 5-10 shows the call flow of the C3P modifyConferenceLock command. This command is issued when a presenter in the conference tries to lock or unlock a conference in the client. In this case, the command is forked by the Focus and sent to both the A/V Conferencing Server and the Web Conferencing Server.
In Office Communications Server 2007, the Web Conferencing Server stores in-conference data contents and its state information in files. For each Office Communications Server pool, there are two file shares configured:
Metadata file share, used for storing conference state information and metadata that describes data content.
Content file share, used for storing user uploaded data content, such as a PowerPoint file. The uploaded contents are encrypted when stored into the content file share.
All Web Conferencing Servers in the pool use these file shares. The file shares are identified using Universal Naming Convention (UNC) paths. They can reside on the same machine as the Web Conferencing Server (as is the case for Office Communications Server 2007 Standard Edition) or on different (dedicated) file servers (as is the case recommended for Office Communications Server 2007 Enterprise Edition).
The file shares are access controlled so that no conferencing client has direct access to them. The metadata share is for Web Conferencing Server internal use only. The Web Conferencing Server needs to have both read and write privileges to the share. The content file share, on the other hand, can be accessed by the conferencing client indirectly via IIS—an IIS virtual directory is created and linked to the content file share when the Office Communications Server Web component is installed so that the client can access the files in the content file share via HTTPs. The Web Conferencing Server requires write privileges to the content file share, whereas IIS requires only read rights to the share.
Figure 5-11 shows the Web Conferencing Server that manages the two file shares.
When the Web Conferencing Server starts a conference—that is, when it receives an addConference command from the Focus—a metadata folder is created for the particular conference under the folder specified by the metadata file share UNC. The metadata file share is structured in the following ways:
For each organizer, the Web Conferencing Server creates a separate folder under the metadata root folder. The organizer folder name is a computed hash value from the organizer SIP URI.
For each conference, the Web Conferencing Server creates a separate folder under the organizer sub-folder. The conference folder name is the same as the conference ID.
Metadata files for a conference are stored under the conference folder. All files except the conference.xml file under the conference folder are encrypted. The conference.xml file contains a randomly generated encryption key for the conference. The key is used to encrypt all other metadata files in the conference. Because sensitive information such as the encryption key is stored under this folder, the administrator should give read and write permissions to this folder just to the users group that runs the Web Conferencing Server.
Figure 5-12 illustrates the metadata folder structure.
Note
The contentmgr.xml file is used to coordinate content expiration processes running in multiple Web Conferencing Servers. The expiration process uses a lock/unlock mechanism to ensure that only one server can delete a specific conference folder at any given time.
The content file share is structured the same way as that for the metadata file share. Figure 5-13 illustrates the content folder structure.
This 'Slide Files' folder contains all the user uploaded slide content shared over HTTPS. All files are encrypted using Advanced Encryption Standard (AES) and a randomly generated key (one for each content file). The key is stored in a corresponding metadata file in the corresponding metadata folder. The names of the files are randomly generated to hide the original file name. The generated file name along with the original file name are both stored in the corresponding metadata file. The 'ft' folder stores all the handouts—the files that are natively transferred without any conversion—in encrypted form.
There are two types of data content in a Web conference: user uploaded and user generated. User uploaded content refers to content that has an origin (either a file or a picture) on the client side and that is uploaded to the Web Conferencing Server by using the PSOM protocol. User uploaded content includes PowerPoint presentation files, MODI documents, handouts, and snapshot slides. User-generated content refers to content that does not come from an original file but instead is created in the conference. These include annotations, Poll content, question-and-answer content, shared notes, text slides, Web slides, and so on.
The upload process is the same for both types of contents. The download process, however, differs. The uploaded content is hosted by the IIS; the Web Conferencing Server sends a URL to the content and an encryption key to clients so that clients can download and decrypt the content. The generated content is downloaded over PSOM.
Figure 5-14 illustrates the flow for uploading and downloading generated content.
The following happens in sequence in the flow shown in Figure 5-14:
The Web Conferencing Server checks the permission for the user (that is, whether the user is allowed to create that particular type of content).
The Web Conferencing Server creates the state for the new slide and saves the state on the file system (in the metadata folder for the conference), in encrypted format.
The Web Conferencing Server shares back to all clients in the conference the new slide state.
For all generated content except for Poll slides, the content is sent with the first PSOM message that creates the slide. For Poll slides, the content (questions and choices) is sent in a new PSOM message after the initial Create Slide message has been sent. The generated content is saved in the metadata folder as encrypted XML files only. It is not saved in the Content folder of the conference. Following is sample XML metadata for Poll slides (before encryption):
<?xml version="1.0" encoding="UTF-8"?>
<POLL>
<POLLENTITY ID="0AA61051-12BC-A1FF-A98F-A240BCB8ABDB"
TYPE="QUESTION" TIMESTAMP="5/21/2007 11:39 AM">
<POLLUSER VALUE="sip:[email protected]"/>
<POLLCHOICE VALUE="MON"/>
<POLLCHOICE VALUE="TUE"/>
<POLLCHOICE VALUE="WED"/>
<POLLCHOICE VALUE="THU"/>
<POLLCHOICE VALUE="FRI"/>
<POLLCHOICE VALUE="SAT"/>
<POLLCHOICE VALUE="SUN"/>
</POLLENTITY>
</POLL>Figure 5-15 illustrates the flow for uploading and downloading uploaded content.
The following happens in sequence in the flow just shown:
The user starts uploading existing content. A PSOM message is sent from the user's client to the Web Conferencing Server.
The Web Conferencing Server checks the permission for the user (that is, whether the user is allowed to create that particular type of content).
The user's client prepares the content for upload. The kind of preparation depends on the type of content being uploaded:
For PowerPoint presentation files, the client converts each slide into a picture .PNG file, and then packages and compresses both the original .PPT(x) file and all the .PNG files into one .LMP file.
For Microsoft Office files, the client converts the files into MODI files, and then converts each page of the MODI files into a picture .PNG file. The client then packages and compresses both the MODI .MDI file and all the .PNG files into one .LMP file.
For handouts, the client just compresses and packages the file into one .LMP file.
The client starts sending the .LMP file over a stream to the Web Conferencing Server.
The Web Conferencing Server unpacks the .LMP file. For each file that is unpacked, the Web Conferencing Server generates an encryption key and uses it to encrypt the file. The encrypted content file is saved in the content file folder for the conference. The encryption key and metadata information, such as the user SIP URI, are saved in an encrypted metadata XML file under the metadata folder for the conference.
The Web Conferencing Server computes the URLs from which the saved encrypted contents can be accessed via HTTPS. This is possible because the Web component sets up a virtual directory that points to the same content file share that the Web Conferencing Server writes to.
The Web Conferencing Server sends back to the clients via PSOM the URL and the encryption key for the content files.
Each client participating in the conference uses the URL to download the encrypted content from IIS.
Using the encryption key, each client decrypts the content and displays it.
Compliance with regulatory requirements was the motivation for adding IM archiving capabilities to Live Communications Server. Those same requirements apply to certain aspects of an Office Communications Server conference as well. There are two features in Office Communications Server that, when combined, provide compliance for on-premise conferencing.
First, the CDR feature records meeting participation information, including the following:
The actual start and end time of the Live Server meeting
The list of participants who attended the meeting
Second, the Meeting Compliance feature running on the Web Conferencing Server, if enabled, records content activities, including:
A log of any content upload activity, including who uploaded content into the conference and at what time
The original uploaded content, whether or not it was subsequently deleted and prior to annotation
Any annotation on any content, or any whiteboard content
A log of any polling activity
A log of any chat activity
A log of any native file transfer upload activity
The logs of activities are stored in XML files, and the uploaded contents are saved in the content's original format. Those compliance XML logs and content files are stored in a configurable file share identified by a UNC path. Unlike the metadata and content file shares, the compliance file share stores compliance logs and contents unencrypted. Administrators must be careful when granting permissions to this file share. The Web Conferencing Server needs write permissions, and only authorized users should have read or write permissions.
Figure 5-16 shows the folder structure for the meeting compliance file share. The folder structure is similar to that of the metadata and content file shares. Under each conference ID folder, the content folder stores all content upload activities for uploaded contents, with the original uploaded files going to the content-upload directory. The chat, poll, and QnA folders store XML logs for Chat, Poll, and Q&A activities, respectively.
The following is a sample XML log file for a poll that takes place in a meeting:
<?xml version="1.0" encoding="UTF-8"?>
<POLLLOG>
<POLLENTITY ID="0AA61051-12BC-A1FF-A98F-A240BCB8ABDB"
TYPE="QUESTION" TIMESTAMP="5/21/2007 11:39 AM">
<POLLUSER VALUE="sip:[email protected] [Ben]" />
<POLLQUESTION VALUE="What day is today?" />
<POLLCHOICE VALUE="MON" />
<POLLCHOICE VALUE="TUE" />
<POLLCHOICE VALUE="WED" />
<POLLCHOICE VALUE="THU" />
<POLLCHOICE VALUE="FRI" />
<POLLCHOICE VALUE="SAT" />
<POLLCHOICE VALUE="SUN" />
</POLLENTITY>
<POLLENTITY ID="0AA61051-12BC-A1FF-A98F-A240BCB8ABDB"
TYPE="CHOICE" TIMESTAMP="5/21/2007 11:39 AM">
<POLLUSER VALUE="sip:[email protected] [Ben]" />
<POLLSEQ VALUE="1" />
<POLLCHOICE VALUE="1" />
</POLLENTITY>
<POLLENTITY ID="0AA61051-12BC-A1FF-A98F-A240BCB8ABDB"
TYPE="CHOICE" TIMESTAMP="5/21/2007 11:39 AM">
<POLLUSER VALUE="sip:[email protected] [John]" />
<POLLSEQ VALUE="2" />
<POLLCHOICE VALUE="0" />
</POLLENTITY>
<POLLENTITY ID="0AA61051-12BC-A1FF-A98F-A240BCB8ABDB"
TYPE="CHOICE" TIMESTAMP="5/21/2007 11:39 AM">
<POLLUSER VALUE="sip:[email protected] [Ben]" />
<POLLSEQ VALUE="3" />
<POLLCHOICE VALUE="0" />
</POLLENTITY>
<POLLENTITY ID="0AA61051-12BC-A1FF-A98F-A240BCB8ABDB"
TYPE="CHOICE" TIMESTAMP="5/21/2007 11:39 AM">
<POLLUSER VALUE="sip:[email protected] [John]" />
<POLLSEQ VALUE="4" />
<POLLCHOICE VALUE="-1" />
</POLLENTITY>
<POLLENTITY ID="0AA61051-12BC-A1FF-A98F-A240BCB8ABDB"
TYPE="CHOICE" TIMESTAMP="5/21/2007 11:39 AM">
<POLLUSER VALUE="sip:[email protected] [John]" />
<POLLSEQ VALUE="5" />
<POLLCHOICE VALUE="0" />
</POLLENTITY>The administrator can enable and disable the meeting compliance feature on each Office Communications Server pool. The administrator can also set the compliance logging to operate in a critical mode. In this mode, new conferences are blocked from starting. Existing conferences are immediately terminated if at any point in time the Web Conferencing Server must access the compliance file share for any reason.
The Web Conferencing Server organizes the three content-related file shares in such a way that it is efficient for fast storage and retrieval of content. In addition, both metadata and the content file share contents are stored using strong encryption. These two factors make it difficult for administrators to examine or move the content of a particular conference.
In the Resource Kit tools for Office Communications Server 2007, three tools are provided that help administrators manage the contents in the file shares. Please refer to the Resource Kit tools documentation for instructions on installing and using these tools.
DMInsider.exe For security reasons, a Web Conferencing Server saves conference contents in encrypted format in the content file share. Therefore, even if the user has access to the content file share, the administrator cannot view the actual content. The DMInsider.exe tool helps Microsoft Office Communications Server 2007 administrators find and view conference content managed by the Web Conferencing Server. The tool provides the following main functionalities:
Ability to list and view content by organizers and by conferences. The content is rendered in the same way as it is rendered in the Microsoft Office Live Meeting Console.
Ability to list and view XML-based conference compliances logs. The tool can render the compliance content in the same way as it is rendered in the Microsoft Office Live Meeting Console.
Ability to view statistics about the content file share. The statistics information includes the number of organizers, the number of conferences hosted on a particular file share, and so on.
DMHash.exe The Web Conferencing Server stores the content of conferences by organizers. The content of all conferences organized by one user is stored in the same directory. The directory name is a hash string that is computed based on the organizer's SIP URI. This makes it difficult for administrators to locate the conference content folders for a particular organizer.
The Dmhash.exe tool helps a Microsoft Office Communications Server 2007 administrator generate the hash value for a user URI. The hash value is used to create content folders for each organizer. It is useful for administrators to move a user's conference content when the user's SIP URI is changed.
DMDel.exe The Dmdel.exe tool helps a Microsoft Office Communications Server 2007 administrator find conferences content that is older than a specified date and delete that content.
The Web Conferencing Server, by default, deletes the conference content that has not been activated for roughly 28 days. This tool allows administrators to manually delete inactive conference content on their own time.
Conference features, except for anonymous participation, are grouped and managed using meeting policies. You control which features a conference organizer can use during a conference by configuring and applying specific policies. The conference organizer's meeting policy controls the conference and applies to all meeting participants. The meeting policy of other participants does not affect what the participants can or cannot do in the conference. For example, Ben is configured with a meeting policy that has IP audio enabled and John is configured with a default meeting policy that has IP audio disabled. As an attendee of Ben's meeting, John can use IP audio because the meeting uses Ben's meeting policy. On the other hand, when John organizes a conference, none of the participants in the conference can use IP audio because John's meeting policy applies in that case.
By default, Office Communications Server 2007 has five meeting policy definitions. All meeting policies include the same features, but any or all of the features can be configured differently for each meeting policy. Administrators can assign meeting policy globally—that is, assign one meeting policy for all users hosted on all pools in the same Active Directory forest. Administrators can also assign meeting policy on a per-user basis. In such a case, administrators select a meeting policy for each user as part of the user options. Table 5-2 shows the policy settings that you configure for each policy to manage features.
Table 5-2. Conference Access Types
Whether a user can invite anonymous users into her conferences is configured outside of the meeting policy. This is because in an enterprise, only a small percentage of users (such as people in the sales department) need to invite external partners or customers into their conference. Enabling anonymous conferences separately from the meeting policy enables customers to specify a global meeting policy for all users in the enterprise, but it only gives selected users the privilege to invite anonymous users. The following configuration options are available for anonymous participation:
Give permission at the global level to invite anonymous participants to meetings, in which case all users in an Active Directory forest can invite anonymous participants to meetings.
Deny permission to all users at the global level, in which case no users in the forest can invite anonymous participants to meetings.
Enforce a meeting policy per user, in which case only individual user accounts configured to allow anonymous participation can invite anonymous participants.