Share via

UserEndpoint or ApplicationEndpoint: Which One to Use

  • Article

The UserEndpoint and ApplicationEndpoint classes derive from LocalEndpoint and have some subtle but important differences. Read on to find out more about these endpoints and how to use them.

Author: Michael Greenlee

Publication date: February 2010

Product version: Microsoft Office Communications Server 2007 R2

A Microsoft Unified Communications Managed API (UCMA) 2.0 Core SDK application has one or more local endpoints at its core. The LocalEndpoint object represents a single SIP endpoint that your UCMA 2.0 Core SDK application uses to sign in to Microsoft Office Communications Server 2007 R2. This object is required to access various capabilities of a SIP endpoint, such as instant messaging, audio calls, presence, and contacts. All endpoints can be either a UserEndpoint or an ApplicationEndpoint class. These two classes derive from LocalEndpoint, and have some subtle but important differences.

How does one decide which type of endpoint to use? This article briefly describes each type of endpoint and then outlines the differences to help you determine the endpoint to use in your application.

UserEndpoint

UserEndpoint is meant for applications that perform communication operations on behalf of a single Active Directory user who uses a unified communications solution. UserEndpoint is associated with a specific user’s SIP URI when it is instantiated. When established, it automatically registers as that user with Office Communications Server.

UCMA 2.0 Core SDK is meant for server-based applications, so developers sometimes wonder why there is a user-centric endpoint type. Generally, UserEndpoint is used by server applications that represent multiple clients simultaneously. Three common scenarios for which UserEndpoint is ideal are Web-based clients (such as Communicator Web Access), automated phone attendants, and load or stress testing applications.

ApplicationEndpoint

ApplicationEndpoint is ideal for highly available applications that need to interact with many users at once. It corresponds to a Contact object in Active Directory directory service, and is trusted by Office Communications Server, which allows it to perform communication operations, such as sending instant messages, on behalf of individual users. It can also join conferences as a trusted application, making it a hidden participant in the conference roster as well as a conference leader. This allows it to provide services such as audio announcements or recording to the conference without appearing as a named participant.

ApplicationEndpoint is ideal for any application that provides a service to many different clients. Some common examples are interactive voice response systems (IVRs), and call routing systems.

Registration and Recovery from Connection Failures

When established, UserEndpoint always registers with Office Communications Server and periodically refreshes its registration to keep it current. If it loses connectivity briefly with Office Communications Server, it attempts to recover by refreshing the registration. If this refresh attempt fails, UserEndpoint does not continue trying to establish a new connection. This makes it a less suitable choice for endpoints that must be highly available and must recover robustly from connection failures.

Unlike UserEndpoint, an ApplicationEndpoint endpoint that loses connectivity with Office Communications Server switches into the Reestablishing state and continues trying to recover connectivity until it succeeds, even if it is unable to connect for a long time period. ApplicationEndpoint is a better choice for applications that must recover gracefully and stay as available as possible in the face of connection failures.

The ApplicationEndpoint endpoint, unlike the UserEndpoint endpoint, can operate without being registered with Office Communications Server. If it does not register with Office Communications Server, ApplicationEndpoint is unable to perform presence operations like publishing or subscribing to presence, and clients cannot route messages to the endpoint through Office Communications Server. In order for it to automatically register with the server, the UseRegistration property on the ApplicationEndpointSettings object used to instantiate the endpoint must be set to true. By default, this property is set to false.

Contacts and Presence

Applications that need to work with a contact list or publish presence on behalf of users should employ the UserEndpoint class. Because UserEndpoint represents a single user, it can manipulate specific user contact and group data through the ContactGroupServices object. ContactGroupServices is not available to the ApplicationEndpoint endpoint, which has no contacts or contact groups of its own.

UserEndpoint can also publish presence using a publication grammar, which means it can publish presence similar to Microsoft Office Communicator, without specifying details such as presence containers, an instance ID, or an expiry policy. ApplicationEndpoint cannot publish presence in this way, and must use the PresenceCategoryWithMetaData class to specify at least an instance ID and presence container ID whenever it publishes presence. For this reason, applications that publish presence on behalf of users should generally employ UserEndpoint.

Trusted Operations

ApplicationEndpoint is trusted by Office Communications Server, giving it the ability to perform two trusted operations unavailable to UserEndpoint: impersonation and trusted conference join.

Ordinarily, the endpoint uses its own SIP URI as the local participant URI in any communication. ApplicationEndpoint can impersonate another SIP URI and use that URI for the local participant rather than its own. This can be helpful if the endpoint is initiating a conversation on behalf of another user. An automated call distributor might do this, for instance, when routing an incoming call to an agent, so that the call appears with the original caller’s identity.

ApplicationEndpoint can also join conferences as a trusted application, which puts it in the leader role automatically and also makes it a hidden participant, so that other conference participants do not see it in the conference roster.

Additional Information

To learn more, see:

Communications Server Developer Resources

Portals

Documentation

Twitter

Developer Sandbox

  • GotUC.Net developer resource for Office Communications Server http://gotuc.net

Forums

Articles

We Want to Hear from You