Share via

3.5 Common Conference Control Details

  • Article

After a participant joins a conference, it can perform various conference control operations. In general, conference control requests can be classified into three categories:

  • Focus Commands. These are commands that terminate on the focus and do not involve MCU interaction. These commands change some conference state and result in notification to watchers. No commands are currently defined for this category.

  • MCU Commands. These are commands that are authorized by the focus but are simply forwarded to the MCU. Thus, no focus state is modified unless the MCU generates a notification indicating the change of state. In this case, the client MUST indicate the MCU to process the command. Such commands can be specified by extension specifications.

  • General Conference Commands. These are commands that are processed by the focus, as well as by all MCUs in the conference. For such commands, the focus and all of the MCUs can generate conference-state change notifications, which are then sent to all participants. The modifyConferenceLock command is an example of this category.

Regardless of the command-type, all conference control commands share a common protocol sequence that is described later in this section. The protocol sequence is divided into client, focus, and MCU roles. The following figure shows a basic conference control call flow.

Basic conference control call flow

Figure 9: Basic conference control call flow

In step 1a, the client sends a conference control request to the focus. This is done by sending a SIP INFO request with a C3P-request body. The focus accepts the SIP INFO and responds to it with a SIP INFO 202 Accepted response indicating that the command is being processed.

If the command semantics involved processing by MCUs, the focus sends the request to the MCUs and waits for their response. This is shown as steps 2a and 2b.

When command execution completes, the focus generates a C3P final response and sends it to the client over a SIP INFO response. The client responds with a SIP 200 OK response indicating that it has received the response. This is shown as steps 3a and 3b.

If the command execution results in a change of conference state, the MCUs and focus generate state change notifications to all watchers. This is shown as steps 4a and 4b.

Processing details are described in the following subsections. Note that some commands require intermediate processing that is specified in the subsection. Extensions to this specification can also specify extra processing behavior.

The protocol used between the focus and the MCUs for exchanging conference control requests, responses, and notifications is outside the scope of this specification. This protocol deals only with the client-to-focus interface.

Detailed command call flow examples are given in section 4.