Share via


Trusted Conferencing User Conversation Model

Using the Trusted Conferencing User model, an application can create multiple AudioVideoCall instances in the context of a single Conversation instance. This call structure allows for a closer alignment with the problem domain. An application not using this model must manage one conversation for each user, all of whom communicate with the same conference. The TCU model reduces management overhead for the application by having it manage only one conversation for each conference, resulting in fewer objects to manage.

The following illustration shows the architecture of the TCU model.

Hh364889.bba5d984-e35b-4e27-bc8f-dc63628096ac(en-us,office.14).png

Shared Command Channel

A Trusted Conferencing User conversation serves multiple users. Some of these users might not have a Focus channel in which to issue conference control commands such as muting self, muting or unmuting others, dialing out to another user, and similar operations. A TCU conversation enables an application to provide a Focus channel for users who would not ordinarily have a Focus channel. The commands are issued within the context of a specific user, so the server enforces the appropriate security policies for that user. For example, an attendee cannot mute others.

Note

An application that uses the TCU conversation model can still issue commands under its own identity. However, because the application is trusted, it is automatically treated as a presenter. For this reason, an application also must have the ability to execute commands in the context of another user to avoid an elevation of privilege.

Shared Notification Channel

Only one notification channel is established to receive conference notifications. Applications using the TCU model monitor the roster through the shared notification channel in order to display announcements or take actions in context of its users using the shared command channel. Having one subscription channel is a major performance gain. Having several subscriptions can cause a flood of notifications, all which are identical.

To further illustrate this concept, consider a TCU conversation that is acting as a private virtual assistant (PVA) for a user connected by telephone. If the user is muted, the TCU conversation detects that this user has been muted from the notification received on the shared notification channel. The TCU conversation then prompts the user by playing a beep as a notification that he or she has been muted.