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:
Copy Code | |
---|---|
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:
Copy Code | |
---|---|
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:
Copy Code | |
---|---|
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:
Copy Code | |
---|---|
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 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.