Conference Creation and Activation

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.

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.

There is however a unique conference identifier that is especially reserved for reservationless meetings. The unique id is 3814A82809A34ED0958CFDB60957BDF. This meeting never expires. When a client creates a conference using the SIP SERVICE mechanism, the client first makes a SERVICE request, which requests a summary of conferencing capabilities supported in the server, and then passes all the information that it needs regarding the conference, media types, privileges, and participants as part of a second 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.

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

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 requesting conferencing capabilities. These capabilities include a list of media capabilities, PSTN support and important policy information a client should know before scheduling a conference. For example:

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. After the getConferencingCapabilities SERVICE request has been sent and the response parsed by the client so that it can be aware of the capabilities available, the client sends a SERVICE request to the Focus Factory to have the conference created.

Step 3. The Focus Factory parses the create conference information in the SERVICE request and writes it to the conferencing database in the Database.

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

The following figure shows the message flow between conferencing components when a 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 Conference 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>

The following figure shows the message flow between conferencing components when the Focus bootstraps the Web 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 (for example, 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.