Export (0) Print
Expand All

Glossary (UCMA 2.0 Core SDK)

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.

ApplicationEndpoint

A highly available endpoint type typically used by application servers that are designed to handle a large number of information workers or users at the same time. The ApplicationEndpoint class is designed to work well with Office Communications Server but can also be used in the absence of Office Communications Server for a limited set of features. A typical application is expected to register with Office Communications Server using this endpoint type, even though registration is optional. This endpoint type is designed to be resilient against failures in Office Communications Server front-ends or other services. An application that registers with Office Communications Server using this endpoint type should ensure that there is a Contact Object entry in Active Directory to represent an instance of this application. An application endpoint that registers with Office Communications Server can support presence publishing and presence subscriptions.

Unlike the UserEndpoint type, the ApplicationEndpoint type allows an application to perform trusted operations such as user impersonation or joining a conference as a trusted user.

Call

A communication session between the local endpoint a remote endpoint. The Call abstract class provides the base class implementation needed to handle a Session Description Protocol (SDP)-based communication session. The SDP is used to negotiate media characteristics between the two endpoints. The base Call class implements the common functionality that is independent of the media types involved, and this functionality can be leveraged by derived classes. InstantMessagingCall and AudioVideoCall are two subclasses that are provided with supported by the UCMA 2.0 Core SDK for instant messaging and audio-video sessions. A call always belongs a conversation.

The Call, MediaProvider, and MediaFlow abstract classes are the building blocks of the communication framework. A developer can create classes that are derived from these abstract classes to extend the UCMA 2.0 Core SDK platform, to establish a media channel between two endpoints for arbitrary media types.

CallFactory

A call factory is used to create a call to handle a collection of media types. By default, the UCMA 2.0 Core SDK platform incorporates two call factories into the platform to handle the creation of InstantMessagingCall and AudioVideoCall instances. An application can remove these factories or add new custom call factories, although call factories that are registered with the platform cannot overlap in the media types supported. An application that is primarily intended to use the InstantMessagingCall and AudioVideoCall types from the platform does not have to register or unregister any call factory with the platform. Incoming calls with media types not supported by any of the registered call factories are automatically rejected by the platform.

CollaborationPlatform

The CollaborationPlatform class is the foundational class for any application built using the UCMA 2.0 Core SDK. This class is used to initialize the platform with such settings as listening transport and port, the certificate to be used, and the list of trusted servers or domains. It is responsible for managing connections between servers (connection pooling, connection throttling), establishing trust with Microsoft Office Communications Servers, and providing modality-specific extensibility.

A CollaborationPlatform instance represents one SIP stack instance. An application cannot create an endpoint without first creating a collaboration platform. Although a single platform instance is sufficient for most applications, it is possible to create multiple instances of the platform. Creating more than a small number of platform instances is not recommended because memory consumption increases significantly with each instance.

There are two types of collaboration platform that are available. A client platform can be used for quick prototyping or to develop a tool to simulate a large number of client instances that target an application server. This is useful to measure the performance of an application server built using the UCMA 2.0 Core SDK. A server platform is typically used for a production application that runs on an application server. The server platform enables sharing of connections across multiple endpoints and enables the application to accept incoming connections from trusted sources. To build a collaboration and communication-enabled service, a server CollaborationPlatform generally requires a trusted GRUU that is obtained through WMI from an Active Directory TrustedService object.

Conference

An impromptu meeting or one scheduled for a future date by an organizer (an Information Worker of a communication-enabled service). Conference participants include presenters and attendees (the conference organizer is generally a presenter). A conference is not necessarily active. For example, the conference might be scheduled for a week from today.

ConferenceServices

The ConferenceServices class offers a variety of services related to conference management. Users can create a scheduled conference, modify an existing conference, or delete a previously scheduled conference.

ConferenceSession

The ConferenceSession class can be used for joining either an ad hoc conference or a scheduled conference. The conference is hosted by the Focus, which is responsible for enforcing conference policies as specified by the conference organizer. The conference session allows a user to perform a variety of operations within a conference to change the characteristics of an active conference. For example, the leader of the conference can eject a participant or can lock the conference to prevent new participants from joining it. Office Communications Server uses the Centralized Conferencing Control Protocol (C3P) for implementing the primitives needed for the conference.

Contact

A unified communications user who is identified by a SIP URI. A user can have many contacts that are maintained and managed by Office Communications Server. Contacts can belong to one or more groups. When a user adds someone as contact, this action affects only the contact store for that user and does not affect the subscription session managed in the endpoint. The application is responsible for adding or removing the URI of the contact for presence subscriptions.

Contact

An Active Directory domains services Contact object represents a communication and collaboration-enabled service. Similar to a user object, an Active Directory Contact is assigned a SIP URI, Display Name, and telephone number and belongs to an Office Communications Server pool.

Contact Group

A contact group is a logical group of contacts controlled by the user.

ContactGroupServices

The ContactGroupServices class contains methods that can be used to add, delete, or update contacts and groups. The class is available only to UserEndpoint instances. It is not available to ApplicationEndpoint instances.

Conversation

A conversation represents a multi-party, multi-modal communication context between a local participant and one or more remote participants. A conversation involving only one remote participant is called a two-party conversation. The Conversation class manages and coordinates between components such as calls, the conference session, MCU sessions, and media providers that are needed for the communication experience. A conversation that involves more than two participants involves a conference session. A two-party conversation is normally escalated into a conference when it is desired to add a new participant or a new modality that requires the services of an MCU.

ConversationParticipant

A conversation participant represents an information worker or a communication-enabled service (local or remote) engaged in a conversation. It exposes properties of a participant such as the URI, network source, tel URI, and endpoints of the participant in the conversation.

Enhanced Presence

The presence information as represented by category instances supported by Office Communications Server. The enhanced presence data model provides the presence publisher with a more flexible and more granular control of how presence can be tracked by other users.

Enhanced Presence Schema

An XML schema that defines the structure of enhanced presence data represented by the value of a category instance as XML elements and attributes. The schema helps an application create, parse, and validate the enhanced presence data before publication, or after receiving a fresh set of information as the result of a subscription.

Focus

In Office Communications Server, the Focus represents an active conference. The Focus is created when the first user joins the conference. The Focus is responsible for authenticating users, supplying the roster, and enabling indirect communication with Multipoint Controller Units (MCUs) that support different media types, such as an AudioVideo MCU, an InstantMessaging MCU, or a Data MCU.

Focus Factory

In Office Communications Server, the Focus Factory is a component that offers conference creation, conference deletion, and conference update services for users. The ConferenceServices class communicates with the Focus Factory to offer its services.

GRUU

A Globally Routable Unique URI that is typically used to uniquely identify a specific endpoint. An endpoint represents the device used by a user or application to communicate with others. When an endpoint registers with Office Communications Server, it is dynamically assigned a GRUU. When an application is provisioned for use with Office Communications Server, it can be assigned a static GRUU based on information in a trusted service entry created for that application in Office Communications Server storage such as Active Directory. An application with a static GRUU (assigned to the collaboration platform instance) as well as a dynamic GRUU (assigned to the application endpoint) uses the static GRUU for any trusted operations as the contact header URI associated with those messages.

The GRUU concept as used in UCMA 2.0 Core SDK is based on, but not fully compliant with the description in RFC-ietf-sip-gruu-15.txt, "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", J. Rosenberg.

LocalEndpoint

An endpoint represents the basic communication unit needed by a user or application to perform any meaningful operations in the UCMA 2.0 Core SDK. An endpoint is created in the context of a collaboration platform. The LocalEndpoint class is the base class for an endpoint in the UCMA 2.0 Core SDK. The UserEndpoint and ApplicationEndpoint classes are two subclasses of LocalEndpoint.

LocalOwnerPresence

The LocalOwnerPresence class can be used to manage the presence of the local (self) presentity. A presentity can use this class to publish presence categories, subscribe to self presence notifications, and assign and manage access control lists.

McuSession

A multipoint controller unit (MCU) is a server component that offers media specific services in a conference. For example, an AudioVideo MCU is useful for mixing audio of the participants in a conference. In the UCMA 2.0 Core SDK, the McuSession class is the base class that provides services to control an MCU by means of the Focus. The InstantMessagingMcuSession and AudioVideoMcuSession classes are concrete platform implementations that extend the McuSession class. MCU-specific commands such as ejecting a user from a specific MCU or requesting the MCU to send an invitation to a specific user (dial-out) can be issued using this class. An McuSession subclass instance cannot exist without a supporting ConferenceSession instance because communication with the MCU happens through the Focus.

MediaFlow

The MediaFlow abstract class represents a media channel that is created as a result of offer/answer exchange in a call. A media flow is created and managed by a media provider that is bound to a conversation. When a media flow is created, an application can configure the flow settings that are used when it generates the SDP needed for the invitation. The InstantMessagingFlow and AudioVideoFlow classes are platform-supplied concrete implementations of a media flow.

The Call, MediaProvider, and MediaFlow abstract classes are the building blocks of the communication framework. A developer can create classes that are derived from these abstract classes to extend the UCMA 2.0 Core SDK platform, to establish a media channel between two endpoints for arbitrary media types.

MediaProvider

A media provider represents the media platform that offers support for a specific media type. The MediaProvider abstract class is the base class that must be derived from by media providers to extend media support for typical applications. The UCMA 2.0 Core SDK includes AudioVideoProvider and InstantMessagingProvider class implementations to enable the consumption of the audio and message media types. An application does not need to create or deal with provider instances directly. The media provider implementations built into the UCMA 2.0 Core SDK for audio and instant messaging are internal and cannot be accessed by the application.

The Call, MediaProvider, and MediaFlow abstract classes are the building blocks of the communication framework. A developer can create classes that are derived from these abstract classes to extend the UCMA 2.0 Core SDK platform, to establish a media channel between two endpoints for arbitrary media types.

MediaProviderFactory

A media provider factory is used to create media providers. By default, the collaboration platform supports the creation of platform-supported media providers to handle calls. An application that is intended to support a custom media type should register a factory instance that is responsible for creating an appropriate call type to handle the custom media type.

PIC User

A user on a public internet cloud service provider, such as MSN, AOL, or Yahoo!.

PIDF

Presence Information Document Format. This commonly used data format represents presence based on the rules specified in RFC 3863, and is used by Office Communications Server when presence notifications are delivered to a PIC user.

Presence Category

Provides the basic identification of the kind of data that is published. A category name is an identifier of the contract between publisher and subscriber. It identifies the nature of the published data, and implies an agreed-upon schema for how the data should be interpreted. Some of the predefined categories in Microsoft Office Communicator are note, contactCard, calendarData, state, and device.

Presence Category Expiry Policy

Indicates the lifetime of this category publication. The publication can last as long as the endpoint is active, the user is active, for a specified period of time, or for longer than the lifetime of the endpoint.

Presence Category Instance

Permits the publication of the same category of data multiple times by the same publisher. An example is a publisher who uses two different endpoints to publish data. These endpoints might publish the same category, but for the publications to be considered by the server as distinct publications, each category must have a different instance number.

Instance numbers are provided by the publishing client. The client can provide a fixed instance number (such as 0) when the data logically has only one instance, such as an offline presence note set by a publisher.

Presence Category Version

Allows multiple clients that publish the same category instance to synchronize themselves. Each published item has a server-maintained version number. The publication is updated only if the publisher presents the current version number. The version number is then incremented atomically with the data update by the server.

Presence Container

A data structure that holds a set of published items and a membership list describing who can see those items. A presence container allows a publisher to publish different data values of the same category and instance for the purpose of allowing different subscribers to see different values. Containers are identified by container IDs.

Presence Document

The XML blob, defined by a schema and represented by the document object model (DOM) that is used in the publication and subscription of enhanced presence.

Presence Publication

A user publishes his or her presence data to inform other users that he or she is willing, available, or even able to communicate or collaborate with them. With Office Communications Server 2007, presence publication amounts to putting specified category instances in the appropriate category containers with specified membership scope.

Presentity

An entity whose presence information can be tracked. This can be a user, a device, or an application. In a unified communications application, a presentity registers its status, location, and other attributes with Office Communications Server.

Publisher

A user who publishes his or her presence for the use of other users who subscribe to it. The enhanced presence model allows a publisher to publish presence in a more flexible way to control how the specified presence data can be received by different subscribers.

RemotePresence

The RemotePresence class can be used to monitor the presence of one or more remote presentities, and to consume presence data associated with them. A filter can be specified to indicate the list of category types of interest. The class optimizes network traffic by the use of batch subscription using the batch protocols supported by Office Communications Server.

Session Description Protocol (SDP)

An RFC-based protocol that describes the offer/answer payload format for an INVITE-based session to indicate various information such as the media types for the session, the codec formats supported, the bandwidth information, and security properties. For more information, see RFC 4566.

Session Initiation Protocol (SIP)

An RFC-based protocol for real time communications, supported by Office Communicator and Office Communications Server. UCMA V1.0 and UCMA 2.0 Core SDK support SIP-based message abstractions . For more information, see RFC 3261.

State

A combination of availability and activity that describes the condition of a user or a device such as a computer or phone.

Subscriber

A presentity who subscribes to presence data published by another presentity.

Subscription

A long-lived session in which a presentity receives published presence data that the presentity has subscribed to. A presentity can elect to subscribe to its own presence data or to the presence data of remote presentities.

URI

A URI represents an identity across multiple devices, either of an application or a user. URIs are used for routing in the Office Communications Server network. A sip URI uses the sip scheme and a telephony URI uses the tel scheme. The UCMA 2.0 Core SDK supports both SIP and tel URIs. A URI may also be used to refer to a specific device instance in advanced scenarios.

UserEndpoint

A user endpoint represents an endpoint for a user with a SIP identity. A user endpoint allows an Information Worker to manage her contacts and groups, share her presence status, subscribe to the presence of others, schedule conferences, and communicate with others. The UserEndpoint class is typically used either to simulate a client (such as Office Communicator) or to represent a client hosted remotely using the services of a backend server. A UserEndpoint instance requires Office Communications Server, because it attempts to register with Office Communications Server during endpoint establishment.

A UserEndpoint is not trusted by Office Communications Server components and is not as highly available as the ApplicationEndpoint type.

Watcher

A presentity who subscribes to presence data published by another presentity. This documentation uses subscriber and watcher interchangeably.

Show:
© 2014 Microsoft