A presenter can lock a conference at any point to prevent new users from joining or being added to the conference. When a presenter locks a conference, the client sends a SIP INFO request with a C3P modifyConferenceLockcommand to the Focus that includes the conference URI. The Focus performs authorization to verify that the user has privileges to lock the conference. The Focus then relays the modifyConferenceLockcommand to all conferencing servers. The focus then sends a C3P response to the client indicating success.

The following figure shows the message flow between conferencing components when a client locks or unlocks a conference.

The call flow when a presenter unlocks the conference is similar, except the locked value in the command body is set to false.

Office Communications Server 2007 R2 enables PSTN (that is, telephone) conferences to provide the audio portion of a Web conference. Any user with a valid PIN can join a PSTN conference by dialing the audio conferencing provider. (An audio conferencing provider is a conferencing bridge offered by a telephone carrier with whom your organization has contracted.) The audio conferencing provider authorizes the PIN and sends a SIP NOTIFY to the Telephony Conferencing Server indicating that a new user is joining the conference. This NOTIFY is sent to the Focus, which then proxies the NOTIFY to all other users in the conference.

Note that this scenario is distinct from the new Dial-In Conferencing functionality introduced in Office Communications Server 2007 R2, where the conference resides on an Office Communications Server, as opposed to a conferencing bridge offered by a telephone carrier. When using the Office Communications Server 2007 R2 PSTN capabilities (where the conference resides on an Office Communications Server), the client simply needs to dial the PSTN access number. The Communicator 2007 R2 Attendant handles authentication and joins the PSTN user into the audio conferencing server. In order for clients to join using PSTN, the organizer client must have requested PSTN capabilities when creating a conference.

The following figure shows the message flow between conferencing components when a client dials in to a PSTN conference hosted on a conferencing bridge offered by a telephone carrier.

For a presenter to invite his own phone or another participant's phone into the conference, the presenter's client sends a SIP INFO request to the Focus with a SIP C3P addUsercommand. The Focus verifies that the client sending the request is a presenter, and then relays the addUsercommand to the conferencing server with information about the endpoint to call. (Participants cannot dial out to other users.) The conferencing server forwards the INFO message to the audio conferencing provider. The ACP responds to the conferencing server. The conferencing server forwards the response from the ACP to the Focus. The ACP calls out to the user's phone and sends a SIP NOTIFY to the conferencing server. The conferencing server sends a NOTIFY to the Focus indicating that the user has connected. The Focus then sends an updated participant list to all clients in the conference.

Participants can choose to leave a conference or presenters can choose to remove or eject other participants. When a participant leaves a conference, the participant's client sends a SIP INFO request to the Focus with a C3P deleteUsercommand indicating which participant to remove. The Focus validates the request and then sends a SIP BYE in the join dialog. The join dialog is terminated. The subscription dialog is also terminated after the join dialog is terminated. The Focus relays the deleteUsercommand to all conferencing servers in the conference. Each conferencing server sends a media BYE to the participant to terminate media streams to the participant. The Focus sends a SIP NOTIFY with an updated participant list to all participants with an active INVITE dialog in the conference. The conferencing server sends a SIP BYE to the participant who is leaving the conference. If a presenter has removed multiple participants from the conference, the conferencing server sends a SIP BYE to all ejected participants. If a participant is joined to a conference using multiple endpoints, the conferencing server deletes each endpoint.

The following figure shows the message flow between conferencing components when a participant is removed from a conference.

At any time during a conference, a participant can mute or un-mute his media stream and presenters can do the same for other participants. When a participant wants to mute or unmute his audio, the participant's client sends a SIP INFO request with a C3P modifyEndpointMediacommand to the Focus. The INFO request indicates the client to mute or unmute. The Focus validates the command and sends it to the conferencing server responsible for the media type that the client wants to mute or unmute. The Focus performs authorization to verify the type of participant. (Only conference presenters have the authority to submit a request to mute or un-mute another participant.) If the participant is authorized to perform the mute or un-mute operation she requested, the Focus sends a 202 Accepted response. The Focus then sends a SIP INFO request with the C3P response to the client. The conferencing server sends a C3P NOTIFY to the Focus. When the Focus receives the C3P NOTIFY from the conferencing server, the Focus updates the conference participant list and sends the updated list to all participants with an active INVITE dialog in a SIP NOTIFY message.

If a participant connected to an Audio/Video conferencing server is muted, the Audio/Video Conferencing Server renegotiates audio media with the client so as to stop receiving audio from that client. This is done as an optimization to prevent the client from unnecessarily sending audio media that would have been dropped by the conferencing server in any case when the participant is muted. Similarly when a user is unmuted, the Audio/Video conferencing server renegotiates the audio media to now start receiving audio from that client.

The following figure shows the message flow between conferencing components when a participant mutes or unmutes his media stream.

A presenter can choose to promote any attendee to the presenter role. This is a privilege available to presenters only and is implemented using the modifyUserRolesC3P command. When a presenter promotes an attendee, the presenter's client sends a SIP INFO request to the Focus with a C3P modifyUserRolescommand. The Focus validates that the participant making the request is a presenter, and then sends a 202 Accepted. The Focus relays the modifyUserRolescommand to all conferencing servers to inform the conferencing servers of the change in participant role. The Focus sends a SIP INFO with the C3P response to the client that made the request. The Focus sends a SIP NOTIFY request with an updated participant list to all participants with an active INVITE dialog.

The following figure shows the message flow between conferencing components when a presenter promotes another participant to the presenter role.