The Microsoft Unified Communications Managed API 2.0 Core SDK serializes work items for raising events and invoking method callbacks into queues. This topic presents information on how the UCMA 2.0 Core SDK uses these queues, and provides guidelines for how applications should use them.

  1. A worker thread is used to invoke the work items in the queue. Since the work items are processed one by one, subsequent items are not processed until the first item is done. For this reason the application should not block the thread that raised an event or invoked a callback by making synchronous calls to operations that require excessive time.

  2. Due to performance reasons, each conversation in UCMA 2.0 Core SDK uses a separate queue. Each endpoint, together with the endpoint’s ConferenceServicesinstance, has its own queue, as does the CollaborationPlatform.

  3. Incoming calls and conference invitations for a conversation will be raised to the application using the conversation’s queue. This is done so that the platform does not serialize these calls and invitations across conversations, thereby impairing performance.

  4. All components used in a conversation will share the conversation’s queue for their events and callbacks. This includes calls, conference invitations, conference session, MCU sessions, and media flows. However, there is no requirement for other media provider components, such as player or recorder, to use the conversation queue. This is true especially because such components might be shared across conversations.

  5. After the conversation terminated event is raised, there should be no other event that is raised from the conversation queue. However, work items for callbacks will be placed in the queue if these correspond to operations invoked by the application after the conversation was terminated.

  6. Events and callbacks are ordered in a way that makes sense for the application. All events raised as a side effect of an operation are placed in the queue before the work item to invoke the callback method for the operation. For example, the state changed event for “Established” is raised before the Establish operation completes. The terminated events for all objects associated with a conversation instance are placed in the queue before the terminated event for the conversation itself. There is no guaranteed order implied between two different components, such as for two calls in the same conversation.

  7. Since each conversation and endpoint uses a single queue, when an application terminates the endpoint without terminating the conversations of that endpoint, there is no order guaranteed between the terminated events of the conversation and the endpoint. If the application is not prepared to handle this, we recommend that the application terminate all conversations before terminating the endpoint.