The organizer of a conference can specify who will be allowed to participate in the conference. When the conference is scheduled, the organizer can choose from the following admission policies for the conference:

ClosedAuthenticated

Authenticated enterprise and federated users who are explicitly included in the participant list can join the conference; any other users are denied access.

OpenAuthenticated

Authenticated enterprise users can join the conference, including those who are not in the participant list. Federated users who are included in the participant list are allowed into the conference.

Anonymous

The conference is open to everyone.

A conference organizer can also specify that public switched telephone network (PSTN) users can be included as participants. To permit PSTN users to join the conference, the following must be true:

1. The conference admission policy must be Anonymous.
   
   
2. Phone access must be enabled.
   
   
3. A passcode must be set for the conference. Even if participants are not required to enter a passcode, a passcode must be set for the conference. For more information, see the following section, PSTN Participants.
   
   

The conference organizer can also perform other tasks using members of the ConferenceServicesclass, such as configuring the expiry time of the conference (the time when the conference will be deleted), creating the list of participants, designating which participants will be leaders, configuring a property that determines whether a passcode is required, and adding the MCUs that the conference will use (by default a conference has two MCUs, one for instant messages, and another for audio/video media).

After the conference has been scheduled, a conference organizer can retrieve a summarized list of all conferences he or she has scheduled, modify the conference information, or cancel the conference.

A PSTN user can join the conference provided that the conference organizer has scheduled the conference with the Anonymousadmission policy, and has granted phone access. To join the conference, the PSTN user dials the phone number supplied by the conference organizer, and when prompted, enters the telephone conference ID. The PSTN user may or may not be asked for a passcode for the conference, depending on whether a passcode is required. After successfully entering the required information, the PSTN user joins the conference.

An application can join an ad hocconference using the BeginJoinmethod. The Unified Communications Managed API 2.0 Core SDK schedules a conference that lasts for eight hours and adds an MCU for each ConferenceMcuSessionFactoryregistered in the platform.

Before joining the conference, it is recommended that the application register for the roster events on the ConferenceSessioninstance and the other McuSessioninstances the application is interested in.

Copy Code

// It is sufficient for most applications to monitor the roster on the conversation level. // Monitor new participants joining the conference. conversation.RemoteParticipantAttendanceChanged += Conversation_RemoteAttendanceChanged; // Monitor main changes to participant properties // (including local participant) such as active media types and conferencing role changes. conversation.ParticipantPropertiesChanged += Conversation_ParticipantPropertiesChanged; // Register for ConferenceSession state changes. conversation.ConferenceSession.StateChanged += ConferenceSession_StateChanged; // Register for InstantMessagingMcuSession state changes. conversation.ConferenceSession.InstantMessagingMcuSession.StateChanged += InstantMessagingMcuSession_StateChanged; // Applications that require detailed monitoring of the roster can subscribe to ConferenceSession and McuSession events. // Monitor Focus roster. conversation.ConferenceSession.ParticipantEndpointAttendanceChanged += ConferenceSession_ParticipantEndpointAttendanceChanged; // Monitor Instant Messaging MCU roster. conversation.ConferenceSession.InstantMessagingMcuSession.ParticipantEndpointAttendanceChanged += InstantMessagingMcuSession_ParticipantEndpointAttendanceChanged; conversation.ConferenceSession.InstantMessagingMcuSession.ParticipantEndpointPropertiesChanged += InstantMessagingMcuSession_ParticipantEndpointPropertiesChanged; conversation.ConferenceSession.BeginJoin(JoinCallback,state);

An application can also join a previously scheduled conference if the conference URI is known.

	Copy Code
ConferenceJoinInformation cji = new ConferenceJoinInformation(new RealTimeAddress(conferenceURI)); conversation.ConferenceSession.BeginJoin(cji, JoinCallback, state);

An application can also join as a trusted application by setting the IsTrustedJoinproperty to true. Trusted applications automatically join conferences as leaders and are allowed elevated privileges. Trusted applications are marked as hidden participants so that ordinary clients (such as Office Communicator and LiveMeeting) do not expose their details in the conference roster to the user.

An example of a trusted application is a bot that archives instant messages sent in a conference. When the bot joins a conference as a trusted application, other clients can detect that it should be hidden from the roster.

The endpoint for an application must support elevated privileges so that it can join as a trusted application. In other words, the endpoint must be an application endpoint and the underlying collaboration platform must be initialized with a trusted GRUU.

	Copy Code
ConferenceJoinInformation cji = new ConferenceJoinInformation(new RealTimeAddress(conferenceURI)); cji.IsTrustedJoin = true; // Indicates that the application is joining as a trusted application. conversation.ConferenceSession.BeginJoin(cji, JoinCallback, state);

When trusted applications join a conference, the ConversationParticipantobject representing the application has its RosterVisibilityproperty set to ConferencingRosterVisibility. Hidden. The UCMA 2.0 Core SDK guarantees that upon successful completion of a join operation, the ConferenceSessionstate is set to Connected. However, the state of the child MCU session (typically, an InstantMessagingMcuSessionor AudioVideoMcuSessioninstance) might be set to Activeafter the join operation completes. The first participant joining the conference signals the Focus to activate the MCUs scheduled for this conference. Office Communications Server does not guarantee that all MCUs are activated before the participant completes the join process. In fact, some MCUs might not be activated at all if they are disabled by the administrator or if an error is encountered.

After a successful join operation, the application is connected only to the Focus and there are no active media flows with the MCUs. For more information, see “Adding a Call to an MCU” later in this topic.

After the ConferenceSessionis connected, the application can add an IM call with the IM MCU to exchange instant messages with other participants. The same applies to adding an audio/video call with the AV MCU.

	Copy Code
InstantMessagingCall imcall = new InstantMessagingCall(conversation); imcall.BeginEstablish(EstablishCallback, state);

	Copy Code
AudioVideoCall avcall = new AudioVideoCall(conversation); avcall.BeginEstablish(EstablishCallback, state);

As previously mentioned in this topic, in the Conference Commands and Events section, an MCU can become active after the ConferenceSessionjoin operation has completed. If a call was established to an MCU that has not yet become active, the UCMA 2.0 Core SDK queues the call request and executes it within 30 seconds if the MCU becomes active. If the MCU does not become active within 30 seconds, so that the call operation fails, it is the application’s responsibility to try again, or monitor the state of the McuSessionsubclass and retry after it becomes active.

During a conference it is possible to request an MCU to dial out to another participant. The MCU initiates a call to the required destination and reports the results to the application.

An application might execute the following sample code for a situation in which two participants are in an audio conference discussing a problem and find that they need the help of a third person, Alice. One participant requests the AV MCU to dial out to the Alice’s cell phone so that she can become a conference participant.

	Copy Code
McuDialOutOptions mcuTransferOptions = new McuDialOutOptions(); mcuDialOutOptions.ParticipantUri = "sip:alice@contoso.com"; mcuDialOutOptions.ParticipantDisplayName = "Alice"; mcuDialOutOptions.PreferredLanguage = CultureInfo.GetCultureInfo("en-us"); conversation.ConferenceSession.AudioVideoMcuSession.BeginDialOut("tel:+14255551234", mcuDialOutOptions, dialOutCallback, state);

The preceding example demonstrates how an application can add a remote participant to the AV MCU. If no participant information is provided ( ParticipantUriand ParticipantDisplayName), UCMA 2.0 Core SDK uses the identity of the added remote participant.

The UCMA 2.0 Core SDK provides three levels of support for high availability to applications.

1. Focus Front-End Failover
   
   When the UCMA 2.0 Core SDK detects that the Focus has failed over to another Front End server, the ConferenceSessionstate changes to Reconnecting. The state of any active McuSessionsubclass instance changes to the Retryingstate. Note that any calls connected to the MCUs are not disconnected.
   
   After failover is detected, pending conference operations fail immediately with an OperationFailureExceptionwith FailureReasonset to SessionRetrying. Any Begin Xxxmethod invoked on the ConferenceSessionor an McuSessionsubclass fails with a RealTimeInvalidOperationExceptionwith FailureReasonset to RetryableOperation.
   
   The ConferenceSessionattempts to reconnect to the conference only once. If that attempt fails, the ConferenceSessionis terminated, otherwise the state of the ConferenceSession is again changed to the Connectedstate. A fresh roster notification is sent and events are raised for any changes that occur during the reconnection process. The state of the McuSessionsubclass changes again to active when the MCUs are reported to be activated on the server.
   
   
2. MCU Failover
   
   During conference activation, an MCU can failover to another Front End server. The corresponding McuSessionstate is changed to Retryingand the call with the MCU is terminated. The application can reestablish the call after the MCU becomes active again.
   
   
3. Intermediate Hop Failover
   
   ConferenceSessionand McuSessionsubclasses support SIP dialog resiliency. If an intermediate hop fails when a conference command is sent, UCMA 2.0 Core SDK attempts to repair the route automatically. If the repair process fails, the ConferenceSessionis terminated and pending commands fail.