UCMA Application Endpoints: Choosing Containers to Publish Presence Data

There is at least one common in each unified communications infrastructure: presence subsystem represents its heart. Microsoft Lync has far the most sophisticated and extensible presence subsystem I have met during my professional carrier. It is called Enhanced Presence and includes the following main concepts:

  • Publisher: endpoint which publishes different kinds of presence information.
  • Presence category: the kinds of presence information which can be published. Lync has several predefined presence categories (e.g. state, contact card, note). All of them are in XML form and well-defined by their associated XML schema. The list of presence categories are extensible; application developers can introduce new presence categories.
  • Presence container: the logical boxes on the Lync Server where publishers can publish presence information to. Each user has its own set of presence containers. Lync comes with a set of predefined containers (e.g. Colleagues, Workgroup, Friends and Family) which have their own predefined semantics. Application developers can also create customer containers.
  • Subscriber: endpoint which receives presence information from specific containers of a publisher. Subscribers can receive presence information based on a subscription/notification or polling method. A given subscriber can subscribe to the presence information of multiple publishers.
  • Container membership: when a subscriber subscribes to the presence information from a particular publisher then the publisher can specify which of his presence container(s) the subscriber has access to (member of). Subscriber then receives only the presence information which are published by the publisher to those specific containers.

Predefined Lync containers

As I mentioned Lync comes with a set of predefined presence containers. Each user has these containers. Container names, identities and purposes are listed in the table below.

Container Name Container ID Purpose
Default 0 Each subscriber who is not a member of any other containers has access to this container.
Self 1 This container is used by the publisher to publish personal information. E.g. contact list entries for roaming purposes.
Aggregation 2,3 These containers are for aggregation purposes (e.g. if the same user is registered from multiple devices and publishes Online from one device and Busy from the other device then aggregated state will be Busy). Aggregation results are then re-published to other containers.
External Contacts 100 This container is used to publish presence information to federated contacts.
Colleagues 200 This container is used to publish presence information for subscribers from the same network.
Workgroup 300 This container is used to publish presence information for team members.
Friends and Family 400 This container is used to publish presence information for personal contacts.
Blocked Contacts 32000 This container is used to block presence information for the container members.

Each of these predefined Lync containers has its own predefined semantics. Among others, this specifies

  • Which kinds of presence information are published to a specific container (e.g. home phone numbers in contact card are never published to the External Contacts container);
  • Which container(s) a given subscriber is assigned to (e.g. subscribers from the same enterprise are added to the Colleagues container);

UCMA application endpoint: which container(s) to publish presence information to?

UCMA application endpoints (ApplicationEndpoint) can also publish presence (LocalOwnerPresence.BeginPublishPresence() method) information. Moreover, they can be notified when new subscribers are interested in their presence (LocalOwnerPresence.SubscriberNotificationReceived event) and they can add them to their presence container(s) as members (LocalOwnerPresence.BeginUpdateContainerMembership() method).

Application developers should decide which container(s) application endpoints will publish presence information to and which containers subscribers will be assigned to. Application endpoints can

  • use only the Default container,
  • or use all of the predefined containers
  • or create custom container(s).

The following picture compares these 3 options taking flexibility and the amount of work into account.


A. Using only the Default container

Application developer can decide to publish all kinds of presence information (e.g. state, note, contact card) only to the Default container. This solution has the advantage that application endpoint will be easily discoverable and anybody who searches for the endpoint SIP URI in Lync can immediately see its display name, status and contact information. This is not a bad idea for an application endpoint. Another advantage is that the application endpoint do not need to subscribe to the SubscriberNotificationReceived event and subsequently add subscribers to containers. Remember, I have mentioned above that each subscriber who is not assigned to other containers are automatically member of the Default container. Thus each subscriber will receive presence information published to the Default container. So using the Default container requires minimal implementation effort. Endpoint just need to publish presence information to container 0.

However, publishing presence information only to the Default container has the disadvantage that there is no way to specify who can see what. Everybody can get all the presence information published. This also means that the semantics predefined by Lync for Container 0 is slightly violated since no presence information other than contact card is published to Container 0 in a pure Lync environment.

The other disadvantage is the no aggregation occurs on Container 0. So if the UCMA application is a distributed application and the same endpoint is registered from multiple locations then the distributed application should solve aggregation inside its own boundary and should publish the aggregated result to the Default container. If the same endpoint is online in location 1 and busy on location 2 then both of the endpoints should publish Busy instead of Online and Busy.

B. Using all the predefined containers

By using the predefined Lync containers applications can benefit from Lync Server services. E.g. a distributed application which registers the same application endpoint from multiple locations can publish presence information to the Aggregation container and can benefit from the aggregation service already implemented on Lync Server. Moreover, using the predefined containers ensures that application endpoints will seamlessly coexist and cooperate with Lync clients.

Of course, using the predefined containers requires some caution since application endpoints must adhere to the semantics of these predefined containers. This requires thorough knowledge. Container semantics are well documented in the “Unified Communications Enhanced Presence Schemas for Lync Server 2013 documentation”. If you do not take care then predefined semantics can be easily violated  e.g. by publishing specific kinds of presence information to wrong containers or adding specific subscribers to wrong containers. If you make such mistakes then you can find yourself in a situation which requires you to deep into the backend SQL Server e.g. to figure out why specific Lync users always see specific application endpoints in Offline state.

Using predefined containers also have the consequence that your application is tied to the Lync container semantics which might change in subsequent Lync releases.

C. Using custom containers

An application endpoint can create its own container(s) to publish presences information to or assign subscribers to as members. Lync Server automatically creates a custom container when application endpoint specifies a container id less than 32768 and no container exists with this id.

Using custom containers offer the most flexibility for application developers. Developers can define their own container semantics and implement their own presence related business logic. They can also implement their own MSPL scripts to perform custom aggregation. They can e.g. publish presence information to Custom Container 1 and assign subscribers to Custom Container 2. Then let their aggregation scripts run over data published to Custom Container 1 and re-publish aggregated results to Custom Container 2. Moreover, using custom containers allows introducing/registering/publishing custom presence categories without interfering with Lync and other applications.

Of course, having this flexibility requires more implementation effort.