Core (Focus, Focus Factory, and Conferencing Server Factory)

Microsoft Office Communications Server 2007 and Microsoft Office Communications Server 2007 R2 will reach end of support on January 9, 2018. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.

Every Office Communications Server conference has a similar lifecycle, which is described at a high level in this section.

Conferencing Lifecycle

A meeting begins when the first participant of any type joins the conference. A participant can join a conference when the conference is not locked and when the participant can be authenticated, based on the participants Active Directory identity or supplied meeting key. A meeting ends when all participants leave, when a presenter terminates the conference, or when ten minutes have lapsed since the last authenticated participant left the conference. When a conference ends, the conference is deactivated, which means that any remaining participants are ejected and that real-time media stops streaming in the meeting. Then, the meeting state and meeting content are purged at the time the conference expires, as defined when the meeting was scheduled. If a meeting is a recurring meeting, the meeting can be reactivated after the previous instance has been deactivated, if it has not already expired. Any content that was uploaded previously is available when the recurrent meeting starts again.

Conferencing Data Flow

Figure 14 shows the data flow between participating components when an intranet client creates and joins a conference.

Figure 14.   Data flow between conferencing components

This is a description of the data flow between conferencing components when an intranet client creates and joins a conference:

• Step 1. The scheduling client communicates with the Focus Factory using DNS lookup or the manually configured server address. The scheduling client sends information required for creating a meeting, such as the conference ID, participant list, user role information, and expiration date in a SERVICE request.

• Step 2. The Focus Factory creates a conference record in the conferencing database on the Back-End Database Server. The Focus Factory also creates and returns a SIP URI that represents the conference to the client.

• Step 3. The conferencing client connects to the Focus and establishes two dialogs with it, an INVITE dialog to join a conference and carry additional command traffic from the client to the Focus and a SUBSCRIBE/NOTIFY dialog to get conference state change notifications.

• Step 4. The Focus connects to the Back-End Database Server to retrieve the conference record and to query the conferencing database to verify that the client joining the meeting is valid. Policy checks are also performed at this time.

• Step 5. The Focus requests information from the Conferencing Server Factory about how to contact a conferencing server.

• Step 6. The Conferencing Server Factory finds the conferencing server of the type requested by the Focus and then tries to provision a conference on that conferencing server, in order to allocate resources for the conference. If provisioning succeeds, the Conferencing Server Factory returns to the Focus an HTTP URL that allows the Focus to establish a control link with the conferencing server.

• Step 7. The Focus communicates with the conferencing server to issue commands that begin or end the conference, change the participant list, or otherwise change the conference state.

• Step 8. The conferencing client communicates with the conferencing server. If the server is an A/V Conferencing Server, the signaling protocol is SIP and the media is transported over RTP/RTCP. If the server is a Web Conferencing Server, both signaling and media are sent using the PSOM protocol.

Conference Creation and Activation

The scheduling client communicates with the Focus Factory to create a new conference. To create a conference, the Focus Factory on the server creates and configures a conference record. The Focus Factory then sends the URI for the Focus instance to the client. The conference URI includes the organizer of the conference and a unique conference identifier. The syntax is as follows:

sip:<organizer>@<domain.com>;gruu;opaque=app:conf:focus:id: <unique ID>.

For instance: sip:Ted@contoso.com;gruu;opaque=app:conf:focus:id:3ICYEOLHDKOE3ZP5K9QO56XN70D8XCDW.

When a client creates a conference using the SIP SERVICE mechanism, the client passes all the information that it needs regarding the conference, media types, privileges, and participants as part of a SERVICE request to the Focus Factory. The Focus Factory creates the conference record and then sends the connection information to the client in the 200 OK response to the SERVICE request.

Figure 15 shows the message flow between conferencing components when a client creates a conference using the SIP SERVICE mechanism.

Figure 15.   Conference creation through SIP SERVICE

The following is a description of the message flow between conferencing components when a client creates a conference using the SIP SERVICE mechanism:

Step 1. The client sends a SERVICE request to the Focus Factory with information to create the conference, as follows:

SERVICE sip:Ted@contoso.com;gruu;opaque=app:conf:focusfactory
To: sip:Ted@contoso.com;gruu;opaque=app:conf:focusfactory
From: sip:client1@contoso.com;tag=f7588dc66124429ab736
Call-ID: 3412asdsss
CSeq: 1 SERVICE
Content-Type: application/cccp+xml
SIP headers...
<XML body>

Step 2. The Focus Factory parses all the required information from the SERVICE and writes it to the conferencing database on the Back-End Database Server.

Step 1.2. After the Focus Factory writes to the conferencing database on the Back-End Database Server, the Focus Factory sends a 200 OK response to the client with the conference information.

Figure 16 shows the message flow between conferencing components when a client joins a conference.

Figure 16. Client joins a conference

The following is a description of the message flow between conferencing components when a client joins a conference:

Step 1. The client sends an INVITE request to the Focus URI to join the conference. The purpose of the INVITE dialog is two-fold. The INVITE dialog indicates that the client wishes to join the conference. The INVITE dialog is also used by the client to send an INFO request in the context of the dialog, in order to set up control of the conference, as follows:

INVITE sip:Ted@contoso.com;gruu;opaque=app:conf:focus:id:1234
To: sip:Ted@contoso.com;gruu;opaque=app:conf:focus:id:1234
From: sip:joe@contoso.com;tag=f7588dc66124429ab736
Call-ID: adfsfasdfasdfds
CSeq: 1 INVITE
Content-Type: application/cccp+xml
SIP headers...
<addUser C3P request>

The C3P addUser request in the body of the INVITE can be used to specify specific client attributes, such as its Display Name.

Step 2. The client will use the SUBSCRIBE/NOTIFY dialog for watching the conference state, as follows:

SUBSCRIBE sip:Ted@contoso.com;gruu;opaque=app:conf:focus:id:1234
To: sip:Ted@contoso.com;gruu;opaque=app:conf:focus:id:1234 
From: sip:joe@contoso.com;tag=f7588dc66124429ab736
Call-ID: adfsfasdfasdfds
CSeq: 1 SUBSCRIBE
Event: conference
Accept: application/conference-info+xml
Content-Length: 0SIP headers...

The Focus processes and accepts the subscription and notifies subscribers of any conference state changes. The conference state includes the state maintained by the Focus itself, the conference policy, and the media policy/information.

Step 2.1. The initial conference state document can be included in the 200 OK of the SUBSCRIBE, if the client expresses support for this extension, as follows:

SIP/2.0 200 OK 
To: sip:Ted@contoso.com;gruu;opaque=app:conf:focus:id:1234
From: sip:joe@contoso.com;tag=f7588dc66124429ab736
Call-ID: adfsfasdfasdfds
CSeq: 1 SUBSCRIBE
Event: conference
Accept: application/conference-info+xml
Content-Type: application/conference-info+xml
...SIP headers...
<conference-state version="0" state="full"
entity="sip:confuri">
  <conference-info>
    <conf-uris>
      <entry>
        <uri>sip:Ted@contoso.com;gruu;opaque=app:conf:audio-video:id:1234</uri>
        <display-text>audio-video</display-text>
        <purpose>audio-video</purpose>
      </entry>
      <entry>
        <uri>sip:Ted@contoso.com;gruu;opaque=app:conf:meeting:id:1234</uri>
        <display-text>meeting</display-text>
        <purpose>meeting</purpose>
      </entry>
      <entry>
        <uri>sip:Ted@contoso.com;gruu;opaque=app:conf:chat:id:1234</uri>
        <display-text>chat</display-text>
        <purpose>chat</purpose>
      </entry>
      <entry>
        <uri>sip:Ted@contoso.com;gruu;opaque=app:conf:phone-conf:id:1234</uri>
        <display-text>phone-conf</display-text>
        <purpose> phone-conf</purpose>
      </entry>
    </conf-uris>
  </conference-info>
<....Other conf Info...>
</conference-state>

Figure 17 shows the message flow between conferencing components when the Focus bootstraps the Web Conferencing Server.

Figure 17. Focus bootstrapping Conferencing Server

The following is a description of the message flow between conferencing components when the Focus bootstraps the conferencing server:

Step 1. The client joins the conference, as described previously.

Step 2. The MCU Factory is selected based on the MCU Type and Vendor configured at scheduling time. The Focus then makes a getMcu call to the MCU Factory.

Step 2.1. If the MCU Factory finds a suitable MCU, then it responds to the Focus with a success getMcu response.

Step 3. When the MCU Server URL has been obtained by the Focus, it then makes an addConference call to the MCU. The MCU can choose to accept or reject the request. However, when failing the call the MCU must place a reason element inside the addConference response element that contains an indicator of why the request was failed. This reason is an enumeration defined in the C3P schema. If the conference exists already, the MCU must respond with conferenceExistsAlready.

• The Conf-Uris section lists the MCU Conference URI for this conference. The MCU needs to use this information to correlate incoming media-INVITE requests to the conference.

• The Service-Uris section contains two URIs – one is an HTTPS URL that gives the Focus Pool URL for use in sending C3P notifications. This URL is indicated by the ms-notification purpose parameter. The second URL is a SIP URL that specifies the outbound-proxy for use by the MCU when it sends a SIP request. This outbound-proxy is usually the Focus itself but it may be different. We use the purpose value of ms-sip-outbound-proxy to indicate this.

• Conference attributes such as organizer, user count, admission policy, and expiration time are communicated in the addConference call.

• Entity-Policy information applicable to the MCU is also conveyed in the addConference call (this is discussed in a previous section).

Step 3.1. If the MCU accepts the addConference request, it then responds to the addConference call with a success parameter. It can optionally request Focus to send conference notifications by setting the notification parameter appropriately.

Joining a Conference

After a client joins the conference and the conference is created, the client must establish a media session with a conferencing server responsible for that media type. For each conferencing server that is involved in a conference, the Focus assigns a virtual SIP URI that is routable to the Focus itself. The initial notification from the Focus to the client contains the URIs for all conferencing servers in the conference.

A client can join itself to the conference in one of the following two ways:

• For joining itself to an IM Conferencing Server or an A/V Conferencing Server (Conferencing Servers that communicate using SIP), a client issues a direct media INVITE to the conferencing server URI.

• For joining itself to a Web Conferencing Server (which does not use SIP), a client issues an addUser C3P dial-in command targeted at the conferencing server URI. (All C3P commands are carried inside a SIP INFO.)

A presenter client will typically invite another participant into a conference by first sending an appINVITE directly to the other participant. (An appINVITE is an INVITE between client endpoints in which the body of the request contains the Focus URI for the conference.)

If that participant client supports C3P, it will join itself to the conference using one of the above methods.

If the participant is a legacy client, the presenter client will receive a 415 error that will cause the presenters client to issue an addUser C3P dial-out command to the conferencing server URI, to have the conferencing server directly connect to the legacy client.

Direct Media INVITE Conference Join Method

Clients can join a conference by sending a direct media INVITE. This method can only be used with conferencing servers that use SIP to establish sessions, such as the A/V Conferencing Server and the IM Conferencing Server. A media INVITE is an INVITE where the To: line contains the conferencing server URI.

A client can send the media session INVITE to the conferencing server URI directly, without any prior addUser call. The INVITE is routed to the Focus. The Focus checks if the connection information is a routable SIP address and forwards the INVITE directly to the conferencing server. The Focus also sends the addUser command to the conferencing server on the client's behalf. The conferencing server authorizes the request and responds with the connection information.

Figure 18 shows the message flow between conferencing components when a client joins a conference by sending a direct media INVITE.

Figure 18.   Client sending the media session INVITE to the conferencing server directly

* The BENOTIFY is sent to all clients subscribed to the conference state.

The following is a description of the message flow between conferencing components when a client joins a conference by sending the media session INVITE to the conferencing server URI directly:

Step 1. The client sends an INVITE to the focus/conference URI it received in the notification document. This INVITE is routed to the focus. The client might have included a session description for media negotiation. Since the focus recognizes that the INVITE was addressed to a particular conferencing server, it safely ignores any session description in the body of the INVITE.

Step 2. The Focus then sends an HTTP request to the conferencing server assigned by the Conferencing Server Factory to this conference asking it to expect a new participant (addUser). Any bootstrapping requests that the Focus sends to initialize the conference on the conferencing server are not included in the call flow diagram.

Step 2.1. The conferencing server sends a successful response for the addUser call. The response includes the actual URL that it wants the participant to use to communicate with the conferencing server. If the server sending the response is an A/V Conferencing Server, the URL will indicate that the participant can communicate with the conferencing server using SIP.

Step 1.1. After the Focus receives the successful response for the addUser request, the Focus forwards the INVITE to the A/V Conferencing Server.

Step 1.2. The conferencing server sends a successful response to the client.

Step 1.3. The client sends an ACK to the conferencing server to complete the INVITE dialog. The same INVITE dialog is also used for media negotiation with the conferencing server.

Note

Although the client establishes the INVITE dialog directly with the conferencing server, the SIP requests traverse the Focus.

Step 3. After the client successfully joins the conferencing server, it sends a participant joined event to the Focus.

Step 4. The Focus sends a participant joined conferencing server state change notification to all clients subscribed to the conference state.

Step 5. Direct media negotiation occurs between the client and the conferencing server. With an A/V Conferencing Server, the media are RTP/RTCP streams.

C3P addUser dial-in Conference Join Method

A client can connect to a non-SIP based conferencing server, such as a Web Conferencing Server, by issuing an addUser C3P dial-in command. When a client issues an addUser dial-in C3P command, the Focus forwards the command to the Web Conferencing Server. The Web Conferencing Server authorizes the command and returns the appropriate connection information. The client then establishes a direct media session with the conferencing server.

Figure 19 shows the message flow between conferencing components when a client joins a conference by issuing an addUser C3P dial-in command.

Figure 19.   Client joining media with a Web Conferencing Server using addUser dial-in

The following is a description of the message flow between conferencing components when a client joins a conference by sending an addUser C3P command to the Web Conferencing Server:

Step 1. The client sends an INFO request with an addUser dial-in command to the Focus. The client uses the focus/conference URI it received in the notification document.

Step 2. The Focus determines if a conferencing server has been assigned to support this particular media type for this conference. If a conferencing server has not been assigned, the Focus sends an HTTP request to the Conferencing Server Factory asking it to allocate a conferencing server for this conference. In the diagram, it is assumed that the conferencing server has been assigned to the conference. The Focus then sends an HTTP request to the designated conferencing server asking it to expect a new participant (addUser). Any bootstrapping requests that the Focus sends to initialize the conference on the conferencing server are not included in the call flow diagram.

Step 2.1. The conferencing server sends a successful response for the addUser request. The response contains the actual URL it wants the conference participant to use to talk to the conferencing server. If the client is joining a Web Conferencing Server, the URL is a PSOM URL. Authorization information, if any, is also included in the response.

Step 3. The Focus sends the PSOM connection information to the client.

Step 4. The client directly establishes a PSOM channel with the Web Conferencing Server.

Step 5. After the client successfully joins the Web Conferencing Server, it sends a participant joined event to the Focus.

Step 6. The Focus sends a participant joined conferencing server state change notification to all clients subscribed to the conference state.

BENOTIFY sip:client1@contoso.com SIP/2.0
   SIP headers...
<conference-state version="1" state="partial"
        entity="sip:Ted@contoso.com;gruu;opaque=app:conf:focus:id:1234">
    <user entity="bob@contoso.com" state="full">
    <display-text>Bob Kelly</display-text>
      <endpoint entity="addf">
        <state>connnected</state>
          <!--
          MEDIA
          -->
          <media entity="2" state="full">
            <display-text>data collab</display-text>
            <proto>dataCollab</proto>
          </media>
      </endpoint>
    </user>
<....Other conf Info...>
</conference-state>

Adding Participants to the Conference

This section describes the different ways that participants can be added to a conference.

Adding Participants Using an AppINVITE

This method of adding participants to a conference is used by clients that support C3P and can therefore join both the Media and the media conferencing server.

After a client has joined a conference successfully, the client can send an app INVITE to another participant. The app INVITE displays as a message prompt in the user's client and contains a conferencing URL and meeting key. After the participant accepts (clicks) the message prompt, it will launch the conferencing client, which then dials the participant in to the conference.

Figure 20 shows the message flow between conferencing components when a client adds a participant to a conference using an appINVITE.

Figure 20.   Ad hoc invitation to another participant

The following is a description of the message flow between conferencing components when a client adds a participant to the conference using an appINVITE:

Step 1. The client sends an app INVITE to another participant. The invitation contains information the participant needs in order to dial in to the conference, including authorization information, if any exists. After the participant accepts the invitation, the conferencing client is launched, which enables the client to dial in to the conference.

Step 2. After the client successfully dials in to the conference, the Focus sends a participant list update notification to all clients subscribed to the conference state.

C3P addUser dial-out Conference Join Method

The primary way that legacy clients, such as Office Communicator (2005 release), are invited to join conferences is through a C3P addUser dial-out command. When the presenter client issues an addUser dial-out C3P command, the Focus forwards the command to the conferencing server. The conferencing server authorizes the command and then dials out to the legacy client specified in the addUser command. The conferencing server then establishes a direct media session with the legacy client.

This appINVITE mechanism can be used with new clients that support the app INVITE and the new C3P protocol. However, legacy clients can also be invited to conferences. To invite a legacy client to a conference, the client sends an addUser dial-out to another client.

Figure 21 shows the message flow between conferencing components when a client adds a participant to a conference using a C3P addUser dial-out command.

Figure 21.   Client joining media with A/V Conferencing Server using addUser dial-out

The following is a description of the message flow between conferencing components when a client adds a participant to the conference using an addUser dial-out command:

Step 1. The client sends an INFO request addUser dial-out command to the Focus. The client uses the focus/conference URI it received in the notification document.

Step 2. The Focus determines if a conferencing server has been assigned to support this particular media type for this conference. If a conferencing server has not been assigned, the Focus sends an HTTP request to the Conferencing Server Factory asking it to allocate a conferencing server for this conference. In the diagram, it is assumed that the conferencing server has been assigned to the conference. The Focus then sends an HTTP request to the designated conferencing server asking it to dial out to the user. Any bootstrapping requests that the Focus sends to initialize the conference on the conferencing server are not included in the call flow diagram.

Step 3. The conferencing server dials out an INVITE to the client using an outbound SIP proxy, which is usually running on the same server as the Focus.

Step 4. The client directly establishes a RTP media channel with the conferencing server.

Step 5. After the client successfully joins the conferencing server, it sends a participant joined event to the Focus.

Step 6. The Focus sends a participant joined conferencing server state change notification to all clients subscribed to the conference state.

Notification Document

For each media type used in the conference, the Focus assigns a virtual SIP URI that routes to the Focus itself. The initial notification from the Focus to the client contains the list of SIP URIs for all the conferencing servers in the conference. The client uses the conference URI to identify the conferencing server it into which it wants to dial or to which it wants to issue a control command.

The conference state package data model has the following elements:

• Conference description. Conference title and description.

• Conference View. Conference-specific information for each entity involved in the conference (for example, the Focus, A/V Conferencing Server, and IM Conferencing Server). This information includes capabilities, current state, settings, and policy information.

• Users. Roster of the conferences, the users, corresponding endpoints, and the media sessions they to which they are connected.

The following is an example of a conference state notification document with two conferencing servers:

<conference-info >
<conference-description>
   <msci:conference-view ci:state="full">
      <msci:entity-view entity="avMcuConfUri" ci:state="full">
         <!—MCU specific data, media-specific states go here -->
      </msci:entity-view>
      <msci:entity-view entity="dataMcuConfUri" ci:state="full">
            <!—MCU specific data, media-specific states go here -->
      </msci:entity-view>
      <msci:entity-view entity="acpMcuConfUri" ci:state="full">
         <!—MCU specific data, media-specific states go here -->
      </msci:entity-view>
   </msci:conference-view>
<users>
<user entity="sip:user1@contoso.com" state="full" >
<endpoint entity="sip:user1@contoso.com" >
<status>on-hold</status>
</endpoint>
</user>
<user entity="sip:user2@contoso.com" state="full" >
<endpoint entity="sip:user2@contoso.com" >
<status>on-hold</status>
</endpoint>
</user>
<user entity="sip:user3@conf.fabrikam.com" state="full" >
<roles><entry>presenter</entry>
</roles>
<endpoint entity="sip:user1@conf.fabrikam.com" >
<status>connected</status>
</endpoint>
<endpoint entity="{guid}" session-type="audio-video" >
<status >connected</status>
</endpoint>
</user>
<user entity="sip:user4@conf.fabrikam.com" state="full" >
<roles><entry>participant</entry>
</roles>
<endpoint entity="sip:user2@conf.fabrikam.com" >
<status>connected</status>
</endpoint>
</user>
</users>
<display-text>brownbag </display-text>
<conf-uris>
<entry>
<uri>sip:organizer@contoso.com;ms-app=conf/meeting;ms-conf-id=cd</uri>
<display-text>Data MCU</display-text>
<purpose>meeting</purpose>
</entry>
<entry>
<uri>sip:organizer@contoso.com;ms-app=conf/audio-video;ms-conf-id=cd/uri>
<display-text>AV MCU</display-text>
<purpose>audio-video</purpose>
</entry>
</conf-uris>
</conference-description>
<conference-info>

Conference Deactivation

A presenter can terminate a conference that is in progress at any point. When a presenter terminates a conference, the client sends a SIP INFO request with a C3P deleteConference command to the Focus, which includes the conference URI. The Focus performs authorization to verify that the user is a presenter with privileges to end the conference. The Focus then generates an update to the participant list by sending a SIP NOTIFY message to all users with an active INVITE dialog associated with the conference. The conferencing server sends a SIP BYE to each client that has an active media dialog. At this point, the conference has effectively ended.

A conference is deactivated in the following scenarios:

• When no new participant has joined a conference (meaning the conference is idle) in 24 hours

• 10 minutes after all authenticated participants have left the conference

Conference Expiration

When a conference is created, an expiration date is typically passed to the server for the conference. When the expiration date arrives, the Focus is responsible for deleting all information about the conference from the conferencing database and the Web Conferencing Server is responsible for deleting the conference content.