Script

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:

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:

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:

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:

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 getMcucall to the MCU Factory.

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

Step 3.When the MCU Server URL has been obtained by the Focus, it then makes an addConferencecall 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 addConferenceresponse 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-Urissection 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-Urissection 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-notificationpurpose 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-proxyto indicate this.
  
  
• Conference attributes (for example, organizer, user count, admission policy, and expiration time)are communicated in the addConferencecall.
  
  
• Entity-Policyinformation applicable to the MCU is also conveyed in the addConferencecall (this is discussed in a previous section).
  
  

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

See Also