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

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

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

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

Examining the Technical Details Behind Web Conferencing

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

Understanding the Client Conference Joining Sequence

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
  • By launching Microsoft Office Live Meeting Console and entering the conference join information

Figure 5-6 illustrates the client conference join process:


Figure 5-6:
Client conference join sequence

Both Microsoft Office Communicator 2007 and Microsoft Office Live Meeting Console 2007 clients register an operating system protocol handler when they are installed. The Microsoft Office Communicator 2007 registers a protocol handler for the conf: protocol, the Microsoft Office Live Meeting Console 2007 registers a protocol handler for the meet: protocol. When users click on 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:

  1. 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.
  2. 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.
  3. 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 clients 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.
  4. 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 clients 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.


Figure 5-7: Client join sequence, server view

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.

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:5D3747C1DEEB684B8962F4078723A65A>;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: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.


Figure 5-8:
Focus join sequence

Understanding the Client Join Sequence to the Web Conferencing Server

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.


Figure 5-9:
Web Conferencing Server join sequence

Some of the notifications that conferencing clients receive from the Focus after they join a conference is 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 to. 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″>
<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>&lt;sAuthId&gt;</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.

Understanding Conference Control

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, modifyEndpointMedia)
  • Commands that are processed by the Focus as well as by MCUs (for example, deleteConference and modifyConferenceLock)

A typical conference control command operates as follows:

  1. The client sends a SIP INFO request to the Focus, with the body containing a C3P command.

  2. The Focus validates and authorizes the C3P request.
  3. 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.
  4. The Focus might proxy or fork the request to one 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.
  5. 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.


Figure 5-10:
Web Conferencing Server join sequence

Understanding Web Conferencing Server Content Management

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 Server2007 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, while IIS requires only read rights to the share.

Figure 5-11 shows the Web Conferencing Server that manages the two file shares.


Figure 5-11:
Web Conferencing Server content management

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.


Figure 5-12:
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.


Figure 5-13:
Metadata 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.

Understanding Web Conferencing Server Content Upload and Download

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 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 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.


Figure 5-14:
Upload and download of generated content

The following happens in sequence in the flow shown in Figure 5-14:

  1. The user creates over PSOM a slide and its content.
  2. The Web Conferencing Server checks the permission for the user (that is, whether the user is allowed to create such type of content).
  3. 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.
  4. 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.


Figure 5-15:
Upload and download of uploaded content

The following happens in sequence in the flow just shown:

  1. The user starts uploading existing content. A PSOM message is sent from the user’s client to the Web Conferencing Server.
  2. The Web Conferencing Server checks the permission for the user (that is, whether the user is allowed to create such type of content).
  3. 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.
  4. The client starts sending the .LMP file over a stream to the Web Conferencing Server.
  5. The Web Conferencing Server unpacks the .LMP file. For each file 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.
  6. 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.
  7. The Web Conferencing Server sends back to the clients via PSOM the URL and the encryption key for the content files.
  8. Each client participating in the conference uses the URL to download the encrypted content from IIS.
  9. Using the encryption key, each client decrypts the content and displays it.


Understanding Meeting Compliance

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 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 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 Q&A folder stores XML logs for Chat, Poll, and Q&A activities, respectively.


Figure 5-16: Compliance file share folder structure

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.

Understanding Web Conferencing Content Tools

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 the 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 content of conferences that has not been activated for roughly 28 days. This tool allows administrators to manually delete inactive conference content on their own schedule.

Understanding Meeting Policy and Policy Enforcement

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, all participants in the conference cannot 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.

Policy setting

Description

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 1000.

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 Microsoft Office PowerPoint presentation graphics program files

  • Support for program and desktop sharing

  • Support for recording meetings

These options are covered later in this table.

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 Microsoft Office Live Meeting 2007 client automatically downloads the Microsoft Office 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.

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 and earlier versions, the default for these two meeting profiles was 256 Colors. If you install Office Communications Server 2007 in an environment in which a pre-release version of Office Communications Server 2007 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.

You can also change the sharing settings that apply to federated and anonymous users (non–Active Directory users). The following options are available:

Never allow control of shared programs or desktop.

  • Use this option to specify that users without an Active Directory domain account in your organization cannot take control of a shared program or desktop during meetings organized by users who have been assigned this meeting policy.

Allow control of shared programs.

  • Use this option to specify that users without an Active Directory domain account in your organization can take control of a shared program, but not a shared desktop, during meetings organized by users who have been assigned this meeting policy.

Allow control of shared programs and desktop.

  • Use this option to specify that users without an Active Directory domain account in your organization can take control of a shared program or shared desktop during meetings organized by users who have been assigned this meeting policy.

Restricting control of shared programs and desktops is generally done to address concerns about who might have access to the shared programs or desktops.

Allow Presenter To Record Meetings

This setting enables internal presenters to record meetings.

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.

Enable IP Audio

This setting enables audio conferencing (Enterprise Voice) over TCP. This option controls whether 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 head sets, microphones, or speakers.

Enabling IP audio can affect performance and the Office Communications Server infrastructure.

Enable IP Video

If you select the Enable IP Audio option, you can also enable support for IP video.

This option controls whether 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 affect performance and the Office Communications Server infrastructure.

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 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.

Summary

This chapter introduced basic concepts and scenarios for Microsoft Office Communications Server on-premise conferences. It also described the architecture that supports those conferencing scenarios. The technical details behind Web conferencing walks through the life cycle of a typical conference and also explains the client joining process and content management by the Web Conferencing Server. Such technical understanding is essential for administrators who need to implement, configure, and troubleshoot on-premise conferencing in Office Communications Server.

Additional Resources

  • Product Documentation: Microsoft Office Communications Server 2007 Technical Overview

  • Product Documentation: Microsoft Office Communications Server 2007 Administration Guide

On the Companion CD

The following three Web conferencing content tools mentioned in this chapter are included as part of the Office Communications Server 2007 Resource Kit Tools:

  • DMInsider.exe

  • DMHash.exe

  • DMDel.exe

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

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top