Typical Application Scenarios of Unified Communications Client API
This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.
The following sections are a high-level description of some basic application scenarios. For more information, see Using Unified Communications Client API.
Conducting Media-Specific Real-Time Communications
This section covers the most basic real-time communications functionalities, including instant messaging (IM), voice and/or video (AV) conversation, and other data exchange. An example of data exchange is a file transfer in an application (APP) session. The communication involves two participants and might require a direct communication channel between the endpoints of the two participants. In an IM session, text messages are sent as the payload of a signaling message and no special media channel is used. Also, an IM participant can communicate with more than one remote participant simultaneously in one IM session. This scenario is known as group IM.
At the API level, conducting media-specific communications amounts to creating an outgoing session of a given type (IM, AV, or APP), inviting the remote participant by adding him or her to the session. For an AV session, it further involves establishing an AV media channel to the remote participant's endpoint. For the invited party, engaging in media specific communications involves listening to an incoming session invitation and accepting, rejecting, or forwarding the invitation. When an invitation is accepted, the participants can start the conversation using the selected communication modes. Listening to incoming sessions and watching for invitation acceptance or rejection requires registration for appropriate event notifications. This implies that Unified Communications Client API and its applications are intrinsically asynchronous.
For an AV session, the call can take place between two computers (computer-to-computer), a computer and a phone (computer-to-phone), or two phones (phone-to-phone). Calls involving telephones require that a CSTA gateway is properly configured with the underlying computer that is running Office Communications Server.
Conferencing with a Group of Participants
Conferencing involves a group of participants communicating with each other in real time. In a conference, communications among the participants are mediated by what are known as the multipoint control units (MCUs) of a conference. The participants do not establish direct communication channels or connected pathways amongst themselves. Instead, they all connect to one or more MCUs. Each MCU is specific to a given media type. In other words, the participants establish media sessions with the MCUs, but not with each other. Notice the subtle difference between conferencing IM and group IM. In group IM, participants relies on the server to dispatch messages to each other. In conferencing IM, participants uses the IM MCU of the conference to send messages to each other.
On the API level, conferencing involves scheduling a conference by a conference organizer or leader and creating a conference session for a conference participant, including the organizer, to join the already scheduled conference. Inside a conference session, a participant needs to establish one or more media-specific media sessions between each participant and the MCUs. The utility of the conference session is to expose the conference Focus and MCUs as well as other conference properties. A conference session cannot be used to exchange data. In this sense, a conference session is transmission-free. The conference organizer uses the conference manager to schedule a conference to send out the invitation to all the participants, usually by e-mail or other means, providing the URI identifying the conference and possibly an entry code that a participant must provide to enter the conference. A participant can connect to a conference MCU by actively dialing in to the conference or have the conference initiate the connection. The latter is known as dialing out.
Providing Presence Services
Real-time communications require that all the communicating parties be present at the same time. A user's knowledge of the presence of his or her contacts therefore becomes much more significant in real-time communications than in, for example, an e-mail correspondence. It is futile, if not counterproductive, for one user to start an IM or AV conversation with another user who is no longer online or does not want to be disturbed.
Unified Communications Client API provides a general and flexible publication and subscription framework to enable presence awareness. A client application can let a user publish his or her presence information including the availability to communicate and contact information. It can also let the user watch for the presence, and the updates, of others by subscribing to a list of contacts, their presence states, availability, and other information.
The publisher can enact a rather sophisticated access control to allow certain information to be accessed by specified users. This is done by publishing data to various containers. A subscriber can elect to subscribe to or query any published data but receives only those to which the subscriber is permitted to access. The subscriber receives the allowable subscription data or updates in a chain of subscription-related events. Using this publication/subscription framework, a user can discover the presence of any user within the same network or from a federated network.
All data subjected to publication and subscription is represented by the API entities known as category instances. Commonly used category instances include calendar data, contact cards, contacts, containers, devices, groups, notes, services, states, and subscribers. More specialized category instances include provisioning policy and routing rule. The list of published category instances is itself represented by a categories category instance.
Enabling Presence-Aware Contact Management
Because contacts are now publishable category instances that can be subscribed to using the general-purpose publication/subscription framework, contact management becomes a special case of publishing and subscribing to contacts category instances. Adding a contact to a user's contact list therefore involves adding a contacts category instance to a self-publication of the local user. Similarly, removing a contact from the contact list involves removing the corresponding contacts category instance by another publication.
Receiving the updates of the contacts involves subscribing to appropriate presence category instances published by the contacts. This way, contact management can be made presence-aware easily.