This section describes the technical details behind Office Communications Server 2007 R2 conferencing scenarios. The conferencing component architecture is discussed first. Then the life cycle of a conference is discussed. Finally, this section will explore more technical details about 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 6-6 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. This client can also handle scheduling the details 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.
Microsoft Live Meeting Console 2007 R2 is the primary conferencing client for scheduled Web conferences. It provides support for a full range of features that enable participants to have an effective collaborative meeting. These features include the following:
Data collaboration, such as with PowerPoint presentations, using the integrated whiteboard polling, shared notes, and other collaboration tools. Live Meeting Console is the only client that supports application sharing.
Audio and video. Live Meeting Console supports real-time multiparty audio and video, complete with active speaker detection and display.
Audio Conferencing Provider integration. Live Meeting Console is the only client that supports integration between an Office Communications Server conference and a phone-based audio conference hosted by an outside ACP. The console provides user interfaces for users to control the audio conference, such as mute self, mute all, and so on.
In-meeting chat. Live Meeting Console supports peer-to-peer text chat between two conference participants.
Office Live Meeting Console 2007 R2 is also a scheduling client. It provides a Meet Now functionality that enables users to create an instant conference and invite other participants from within the conference. Figure 6-7 shows a Poll question in Live Meeting.
Microsoft Office Communicator 2007 R2 is the primary client application for instant communications and spontaneous collaboration. It provides the following capabilities:
Multiparty IM conference, based on multiple contacts in a contact list or an Active Directory distribution group
Multiparty A/V conference
Seamless escalation from IM or A/V conferences to data collaboration conference in Office Live Meeting Console
Figure 6-8 shows a Group IM session in the Office Communicator 2007 R2 client.
The Microsoft Conferencing add-in for Outlook is the primary scheduling client. The add-in enables users to use the familiar 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 times and recurrence, the add-in enables 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 choose from two options to schedule their conferences:
Schedule a Live Meeting. This option schedules a conference that will happen in the Office Live Meeting Console 2007 R2 client. All modalities will be provisioned for the conference.
Schedule a Conference Call. This option schedules a conference that will happen in the Office Communicator 2007 R2 client. Only the computer-based audio modality is provisioned at the start of the conference. (Conference participants can add other modalities later.)
Figure 6-9 shows the Conferencing add-in for an Outlook client.
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 on the Microsoft SQL Server 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. The data will be persisted here until either the data is explicitly removed or the configured time (by default 90 days and set by the Conference Content Retention policy) is reached. Following is a list of conference properties that are included in the RTC database:
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, Invite Within Network.
Conference access key. The key that is sent to 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 other state information. 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 Server 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, gets 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 and runs in the same process as the Focus. When a client application creates a new conference, the client sends a SIP SERVICE message, which carries Centralized Conferencing Control Protocol (C3P) commands as the message payload, to the Focus Factory. For more information about C3P commands, see the section titled "The Conferencing Protocols" later in this chapter. 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, which is also known as a multipoint control unit (MCU). Each type of conferencing server is responsible for managing one or more media types. Office Communications Server 2007 R2 includes four conferencing servers:
Web Conferencing Server. Manages conference data collaboration, including native support for PowerPoint presentations, Microsoft Office document sharing, use of the integrated whiteboard, application sharing, polling, questions and answers, 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 Transport 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 ACP integration. Supports 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 MP is responsible for media management, such as mixing, relaying, and transcoding. Transcoding is direct digital-to-digital translation from one signal-encoding format to another. On a Web Conferencing Server, the MP is a software component that is responsible for managing data collaboration. On an A/V Conferencing Server, the MP 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 use the most central processing unit (CPU) and network resources. In the Office Communications Server conferencing architecture, an MC and an MP are co-located on the same server 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 R2. 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 tool in the Office Communications Server 2007 R2 Resource Kit, which is a Web-based scheduling solution.
Figure 6-10 shows the computer and process boundaries for all the conferencing components that we discussed in the 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 computers.
The Web Conferencing Server and the A/V Conferencing Server can be run on the same computer as the front-end server (in an Office Communications Server 2007 R2 Standard Edition or Enterprise Edition consolidated topology). However, they can also be a separate server role and installed on their own hardware as in an Office Communications Server 2007 R2 Enterprise Edition expanded topology. This configuration enables enterprises to scale out their Office Communications Server 2007 R2 deployments by deploying as many conferencing servers as necessary to meet their usage models. The host for Web Components (IIS) can be installed as part of every Office Communications Server 2007 R2 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 R2 enables enterprise users that are 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 incoming 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 incoming and outgoing media traffic can securely traverse Network Address Translation (NAT) and firewalls. The industry-standard solution for multimedia traversal of firewalls is Interactive Connectivity Establishment (ICE), which is based on the Simple Traversal of User Datagram Protocol (UDP) through 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 them 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 R2 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 6-11 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 classes of protocols involved in an on-premise conference: signaling and media.
Signaling protocol refers to protocols that facilitate session establishment, capability exchange, state exchange, and conference control.
SIP is the primary signaling protocol that Office Communications Server uses. SIP is the industry-standard protocol described in Internet Engineering Task Force (IETF) Request for Comment (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 that are associated with a conference. It is described by using the IETF RFC conference event (http://go.microsoft.com/fwlink/?LinkID=133681) package.
Various conference control and state modification tasks are achieved by using C3P protocol. C3P 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.
The term media protocols refers to protocols that facilitate the 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://go.microsoft.com/fwlink/?LinkID=133682).
RTP/RTCP is a 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 (Secure Real-Time Control Protocol) protocol, which provides encryption over RTP/RTCP.
Figure 6-12 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 6-13. A scheduling client creates a conference 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 R2 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 Outlook
By creating a multiparty IM or A/V conferencing session from the Office Communicator 2007 R2 client
By using the Share Information Using Live Meeting option in the Office Communicator 2007 R2 client
By creating an ad hoc meeting by using the Meet Now functionality of the 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 R2 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 alphanumeric 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 Invite Within Network, Invite Within Network (Restricted), or Invite Anyone.
Conference key, which is an alphanumeric 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 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 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 the 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.
When creating a conference on the server, it is up to the scheduling client to specify the expiration time. 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. If, after three months, the meeting is activated again 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:
Conferencing client joining the Focus
Conferencing client joining the Web Conferencing Server
Conferencing client uploading data content to the Web Conferencing Server
Conferencing client receiving data content from the Web Conferencing Server and displaying it
A user can join a conference primarily in two ways:
By clicking the Join link inside the conference invitation e-mail message or the Join link in the IM window in Office Communicator 2007 R2
By launching Office Live Meeting Console and entering the conference join information
Figure 6-14 illustrates the client conference join process.
Both Office Communicator 2007 R2 and Office Live Meeting Console 2007 R2 clients register an operating system protocol handler when they are installed. Office Communicator 2007 R2 registers a protocol handler for the conf: protocol. Office Live Meeting Console 2007 R2 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 Domain Name System (DNS) Service Record Locator (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 R2 server that hosts the conference. The user is authenticated by the Office Communications Server 2007 R2 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 R2 server is found, and the server is federated with the Office Communications Server 2007 R2 server that hosts the conference. In this case, the client sends the join SIP INVITE targeted at the Office Communications Server 2007 R2 server that hosts the conference. The Office Communications Server 2007 R2 server authenticates the user in her own domain. However, the SIP INVITE cannot be successfully routed because there is no federated link between the user’s 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 R2 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. The 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 uses just the entity URI that the client supplied.
Figure 6-15 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.litwareinc.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.
NOTIFY sip: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:5D3747C1DEEB684B8962F40787 23A65A>;tag=183C0080 Content-Type: application/conference-info+xml Event: conference subscription-state: active;expires=3600 <conference-info entity="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:5D3747C1DEEB684B8962F407872 3A65A> 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 6-16 illustrates the client focus join sequence.
Conferencing clients use the addUser C3P command 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 the client uses 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 6-17 shows 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 globally unique identifier (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. The following is a sample response to the addUser request to join a Web Conferencing Server:
From: < sip:[email protected];gruu; opaque=app:conf:focus:id:5D3747C1DEEB684B8962F40 78723A65A>; tag=052B0080 To: <ben:[email protected]>;tag=d1991b44ef;epid=10caaf88e2 ... <response from=" sip:[email protected];gruu; opaque=app:conf:focus:id:5D3747C1DEEB684 B8962F4078723A65A" 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:ben@litwareinc. com"><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"><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.litwareinc.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.litwareinc.com:8057</value></entry><entry> <key>pwrpc.pwsURI</key><value>https://conference.litwareinc.com:8057</value> </entry><entry><key>uType</key><value>pre</value></entry><entry> <key>alternativeName</key><value>conference.litwareinc.com</value></entry> </connection-info></addUser></response>
The information included in the C3P response includes the following:
The 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 validates and authorizes the C3P request.
The Focus operates on the C3P request and generates one or more SIP responses back to the client, containing a 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 6-18 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 R2, the Web Conferencing Server stores in-conference data contents and its state information in files. For each Office Communications Server pool, two file shares are 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 R2 Standard Edition) or on different (dedicated) file servers (as is recommended for Office Communications Server 2007 R2 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 6-19 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 subfolder. 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 in 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 6-20 shows 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 the metadata file share. Figure 6-21 shows 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 is 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 is content that does not come from an original file but instead is created in the conference. This content includes 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 differs, however. The IIS hosts the uploaded content; 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 6-22 illustrates the flow for uploading and downloading generated content.
The following happens in sequence in the flow shown in Figure 6-22.
Over PSOM, the user creates a slide and its content.
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 6-23 illustrates the flow for uploading and downloading uploaded content.
The following happens in sequence in Figure 6-23.
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. When combined, two features in Office Communications Server 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 questions and answers
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 6-24 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 for fast, efficient storage and retrieval of content. In addition, metadata and the contents of the content file share are stored using strong encryption. These two factors make it difficult for administrators to examine or move the content of a particular conference.
The Resource Kit for Office Communications Server 2007 R2 provides three tools that help administrators manage the content in the file shares. For more information about installing and using these tools, see the Resource Kit Tools documentation.
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 Office Communications Server 2007 R2 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 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 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.
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 an Office Communications Server 2007 R2 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.
The DMDel.exe tool helps an Office Communications Server 2007 R2 administrator find conference content that is older than a specified date and then delete that content.
The Web Conferencing Server, by default, deletes conference content that has not been activated for roughly 28 days. This tool enables 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. However, 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 R2 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 the case of assigning Meeting policy on a per-user basis, administrators select a Meeting policy for each user as part of the user options. The list below shows the policy settings that you configure for each policy to manage features.
Policy Name. A name that you specify. We recommend that the name describe the purpose of the policy. The name cannot exceed 256 Unicode characters
Maximum Meeting Size. The maximum number of participants that an organizer’s meeting can admit. An organization can invite more participants than the maximum meeting size, but once attendance reaches the maximum meeting size, no one else can join the meeting. The maximum number is 1,000.
Enable Web Conferencing. Enables Web conferencing for users of the policy. If you select this option, you also need to configure the following options:
Whether to use native format for PowerPoint presentation graphics program files
Support for program and desktop sharing
Support for recording meetings
These options are covered in detail later in this list.
Use Native Format For PowerPoint Files. When a user uploads PowerPoint content, it is converted to PNG files that the server renders. PNG files are similar to screen shots.
If this option is enabled in a policy (the default), when a presenter makes a slide deck active, each attendee’s Live Meeting 2007 client automatically downloads the PowerPoint presentation in its native format (PPT file) as well as the converted PNG files. The PowerPoint data is available only for the duration of the meeting.
Conversely, if the policy does not enable this option, when a presenter makes a slide deck active, each Live Meeting 2007 client automatically downloads only the converted PNG files. If you do not use native PowerPoint format, the original source is unavailable and cannot be changed. Attendees also cannot see any active content or animation. Preventing native format increases security because the original source is unavailable and cannot be modified.
This option is generally not selected if there are concerns about the bandwidth required to download slides in native mode or if original files should not be shared with participants. If this option is not selected, PowerPoint slides are downloaded as *.png images, which are equivalent to screen shots.
Enable Program And Desktop Sharing. This setting enables presenters in a meeting to share applications or an entire desktop with other participants.
If it is selected in a Meeting policy, the presenter can allow all participants with Active Directory accounts to take control of the organizer’s desktop or a program that is running on the desktop.
You can specify the range of colors (color depth) used to display slides and other meeting content, as follows:
Gray scale (16 shades)
Gray scale (256 shades)
256 colors
High color (16 bit)
True color (24 bit)
The default color depth for displaying slides and other meeting content in the Default Policy and Policy 5 (Low) Meeting policies is High Color (16 Bit). For Office Communications Server 2007 R2 and earlier versions, the default for these two meeting profiles is 256 Colors. If you install Office Communications Server 2007 R2 in an environment in which a pre-release version of Office Communications Server 2007 R2 was installed, the default will continue to be 256 Colors for all servers in the environment. You should change the setting for these two policies on all servers in your environment to either True Color (24 Bit), which is recommended for the best meeting experience, or High Color (16 Bit). Original documents are not affected by the color definition settings when viewed outside of a meeting.
Allow Presenter To Record Meetings. This setting enables internal presenters to record meetings and to make them available for consumption later by others using the LiveMeeting console.
Presenter Can Allow Attendees To Record Meetings. If you select the Allow Presenter To Record Meetings option, you can also allow the presenter to allow attendees to record meetings. The option gives the attendee the ability to have the presentation available immediately.
Enable IP Audio. This setting enables audio conferencing (Enterprise Voice) over TCP. This option controls whether a streaming of audio over the Internet connection is allowed in meetings organized by users who have been assigned this meeting policy. This option is generally not selected if there are concerns about the bandwidth required for IP audio.
Enabling IP audio for meetings requires deployment of the appropriate audio hardware, including headsets, microphones, or speakers.
Enabling IP audio can negatively impact performance and the Office Communications Server infrastructure because of the additional server resources that are required to process and send IP audio
Enable IP Video. If you select the Enable IP Audio option, you can also enable support for IP video.
This option controls whether a streaming of video over the Internet connection is allowed in meetings organized by users in this forest who have been assigned this Meeting policy. This option is generally not selected if there are concerns about the bandwidth required for video.
Enabling IP video for meetings requires deployment of the appropriate video hardware, including webcams or Microsoft Office RoundTable.
Enabling IP video can negatively impact performance and the Office Communications Server infrastructure because of the additional server resources that are needed to produce and output the video stream.
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 conferences. Enabling anonymous conferences separately from the Meeting policy enables customers to specify a global Meeting policy for all users in the enterprise, but it gives only 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.