chapter_06_enhanced_presence.doc

This document is provided “as-is”. Information and views expressed in this document, including URL and other Internet Web site references, may change without notice.

Some examples depicted herein are provided for illustration only and are fictitious. No real association or connection is intended or should be inferred.

This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes.

Copyright © 2011 Microsoft Corporation. All rights reserved.

Microsoft, Active Directory, Lync, MSN, SQL Server, Windows Live, and Windows PowerShell are trademarks of the Microsoft group of companies. All other trademarks are property of their respective owners.

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

ContributorsProject Manager: Susan S. Bradley

Content Architect: Rui Maximo

Chapter Lead: Kurt De Ding

Contributing Writers: Jared Gradle

Technical Reviewers: Brian R. Ricks, Conal Walsh, Joe Schaeffer, Moustafa Noureddine, Rick Kingslan

Lead Editor: Kate Gleeson

Contributing Editor: Katrina Purcell

Art Manager: Jim Bradley

Production Editor: Kelly Fuller Blue


Table of ContentsContributors................................................................................................................................................3

Introduction.................................................................................................................................................5

Enhanced Presence Data Model..................................................................................................................6

Enhanced Presence Category Instances..................................................................................................6

Enhanced Category Instance Data...........................................................................................................9

Aggregated Category Instance Values and Multiple Points of Presence................................................13

Public and Private Category Instances...................................................................................................14

Categories for Application Data and Custom Presence.........................................................................15

Enhanced Presence Operations.................................................................................................................15

Publication.............................................................................................................................................15

Publishing Presences Using SIP SERVICE Requests............................................................................16

Understanding Lync Server Presence Aggregation............................................................................21

Controlling Access to Presence Publications with Containers...........................................................25

Enforcing Interoperability with Lync by Using Publication Grammars...............................................30

Enabling Enhanced Privacy Mode in Presence Publications..............................................................30

Roaming Application Data.................................................................................................................35

Subscription...........................................................................................................................................36

Receiving Presence Publications by Using SIP SUBSCRIBE Requests..................................................37

Optimizing Lync Server Load with Presence Policy in Persistent Subscription or by Using Polling Subscription.......................................................................................................................................39

Receiving Contacts Lists before Subscribing to Their Presence.........................................................40

Receiving Remote Presence by Using a Persistent Subscription........................................................42

Receiving Roaming Data by Using Self-Subscription..........................................................................46

Receiving Lync Server Configuration Settings and Other System Data by Using In-band Provisioning...........................................................................................................................................................48

Summary...................................................................................................................................................49

Additional Resources.................................................................................................................................49


IntroductionPresence is an important element in facilitating efficient real-time communications. Presence refers to information used to describe an entity’s availability, willingness, or capability to communicate with other entities. The presence information can help a communicating party determine if, when, and how to contact other parties.

In a Microsoft® Lync™ Server 2010 communications software deployment, a communication entity can be a user or a trusted application such as a Web service, an interactive bot, or the Lync Server Response Group application. The user corresponds to a security principle represented by an Active Directory® Domain Services User object and the trusted application is represented by an Active Directory Contact object. A communication entity that makes its presence available is referred to as a presence entity, also known as presentities.

Microsoft Lync™ 2010 communications software maintains a Contacts list for the user. The Contacts list is maintained on the server running Lync Server and updated when a presence entity is added to or removed from the list. When a user signs in to Lync Server 2010 using Lync 2010, Lync 2010 receives the Contacts list from the server before Lync requests that the Lync Server subscribe to these contacts’ presence. As the results are returned, Lync displays the Contacts list together with status indicating whether contacts are available, busy, inactive, away, or offline. On a signed-in Lync 2010, the presence status is color-coded and appears before each contact's name. The following figure shows a Contacts list for Bob Kelly. Anahita is Away with a yellow status bar, whereas Cynthia is Offline with a gray status bar. The presently available contact is Help desk, which has a green status bar.

Figure 1. Example of contacts’ presence shown with color coding


When a contact's status shows Available, you know that the contact is likely to answer your instant message or voice call. A busy or inactive contact, however, is less likely to respond to you. The Away or Offline status suggests that perhaps you should send the contact an email message instead of an instant message. Other information that describes the contacts’ presence includes a user-supplied presence note, a capability string that describes whether or not the contact can take instant messaging (IM) or audio/video calls, contact card information that contains the office location, telephone numbers, the organization chart, and a photograph of the contact. In any Lync Server deployment it is possible to use any other information to describe the presence of a contact or a presence entity. For details, see the “Categories for Application Data and Custom Presence” section later in this chapter. This flexible presence data model supported by Lync Server is known as enhanced presence.

Enhanced Presence Data ModelThe enhanced presence data model for Lync 2010 and Lync Server 2010 is underpinned by the concept of enhanced presence category, also simply referred to as category. An enhanced presence category represents a named set of related presence information types. The name of an enhanced presence category defines a type of presence information that can be transported between endpoints across one or more networks as an independent unit of presence data.

For example, availability, activity, and location are three basic types of related information describing a user’s presence state. Together, they form an enhanced presence category called a state. Although the data of the basic presence information types can be parsed or manipulated separately in any local processes, they can only be transported over the wire, namely, published or subscribed to, as part of the state category instances.

The enhanced presence data model is flexible because an enhanced presence category can be extended to include other basic types of presence information to satisfy different application needs. If a person wants to observe the movement of a user remotely, he or she can include Global Positioning System (GPS) coordinates and velocities in the enhanced presence state category definition by extending an existing category or by creating a custom category. Furthermore, an instance of an enhanced presence category may contain a partial or whole set of the constituent types of presence information. This means that the same type of category instances can describe different aspects of the same type of presence information in various level of detail. For example, one application may include only availability to describe a presence state and another application may include both availability and activity as a presence state. In some scenarios, perhaps, only the location information is relevant to describe a presence state, whereas in other scenarios all the presence information subtypes are required to represent a presence state.

Enhanced Presence Category InstancesA specific presence data of a given category name is referred to as an instance of the category. In addition to the presence data, a category instance contains metadata, as represented by the following attributes:

Category name. Identifies what type of presence data the category instance holds. It specifies a contract between a presence provider and a presence consumer. The contract stipulates the data structure of the contained category instance value. This contract corresponds to an XML schema. The category name corresponds to the name of the XML element of the category instance value. Lync Server requires that a category name be registered with Lync Server. The XML schema of the category instance must be well formed; however, Lync Server does not require that the XML schema be validated.


Instance number. Provided by a client, the instance number is used to identify a specific instance of a given category. It can be used to identify the source where the presence data is published (that is, where presence data originates) or the kind of category instance that contains different variations of the same type of presence information. For example, a state category instance can be classified as a machine state, a user state, a phone state, or a calendar state. These state category instances present different information about the presence state published from a device, a user action, a phone call connection, or a calendar event, respectively. Each state category instance is assigned a different instance number.

Container ID. A unique integer ranging between 0 and 32767, inclusively, that identifies a container of published category instances. Each presence publisher owns a set of containers, each of which has a unique container ID value. Containers are category data stores managed by Lync Server that allow the publisher to control which users are allowed access to the data in the store. Each container is assigned a list of members or a membership scope. Membership determines which users can access the contained data. Lync uses five containers to support five levels of access by remote contacts. These correspond to the five privacy levels that can be assigned to a contact when the contact is added to the local user’s Contacts list. The privacy relationships defined in Lync Server are Friends and Family (container ID=400), Workgroup (container ID=300), Colleagues (container ID=200), External Contacts (container ID=100), and Blocked Contacts (container ID=32000). Lync Server uses a set of containers to hold the self-published category instances by the local user and other application data that are intended for private use by the local user or client. They include the Self container (container ID=1) and Aggregation containers (container IDs 2 and 3). An application can elect to use other custom containers too. You can assign a custom container an ID that is any number between 0 and 32767 that is not currently used by any application. Notice that if such a container is assigned a value greater than 32000, the semantics for the Blocked Contacts container, which is defined by Lync Server, may be altered if the custom container happens to share common membership with the Blocked Contacts container, but contains a different set of category instance values. In any case, care must be taken to avoid potential conflicts, especially when the application intends to interoperate with Lync 2010. Containers are created by Lync Server when a new container ID is specified by a Lync Server client.

Version number. Used by Lync Server to synchronize publications of the category instance. Every time the client updates the user’s status (for example, presence) a category instance is published to the server. The server increments the client-provided version number by one if the client-provided version number corresponds to the most current version number maintained by the server. In the case where a client publishes the category instance from multiple endpoints, the server uses the version numbers to maintain the most current publication across multiple endpoints. The client must present the current version number for the publication update to succeed. When the server receives multiple requests to update a certain publication, the server accepts the request from the client with the latest version number and ignores all the other update requests.

Publication time. Specifies the time when the category instance is last published or updated.


Expire type. Specifies how, and, if applicable, when a category instance ceases to be in publication. A category instance publication can have one of the following types of life cycles:

o Endpoint bounded. Publication expires when the publishing endpoint is no longer registered (for example, when the client is not currently signed in to Lync Server).

o User bounded. Publication continues to persist as long as one of the endpoints of the publishing user is registered.

o Time bounded. Publication persists until the affiliated expiration time is reached, at which time the publication is removed. The publisher can reset the expiration time to refresh the publication. For this setting, you also need to specify the Expiration time. The Expiration time specifies the time when the category instance publication expires.

o Unbounded. A static publication that does not expire.

You can think of these category instance attributes as the metadata of a particular piece of presence information. While a category instance data value describes the presence information, the category instance metadata prescribes how the category instance is maintained and how it should be processed.

Lync Server uses an XML element to represent an enhanced category instance. The category instance metadata are expressed as the attributes of the XML element and the category instance data value is expressed as a child element of the XML element. Depending on whether the category instance is published or received, the category instance XML element has one of the following forms:

In publications where category instances are published using a SERVICE method with the Content-Type header value of “application/msrtc-category-publish+xml”, a category instance corresponds to a <publication> element as shown in the following example.

<publication categoryName="state" instance="929600355" container="3" version="13" expireType="endpoint"> <state … > … </state> </publication>

In a remote subscription or query notifications where the results are received in SIP 200 OK responses or using the NOTIFY or BENOTIFY requests, with the Content-Type header value of “application/msrtc-event-categories+xml”, a category instance corresponds to a <category> element as shown in the following example.

"<category xmlns="http://schemas.microsoft.com/2006/09/sip/categories" name="state" instance="1" publishTime="2011-04-13T04:53:03.137"> <state …> … </state></category>

Note. In a remote subscription or query, the returned category instance does not contain any specifications of the container information. For details, see the “Subscription” section later in this chapter.


In the self-subscription notifications where the private roaming data is sent in SIP 200 OK responses or using the NOTIFY or BENOTIFY requests, with the Content-Type header value of “application/msrtc-event-categories+xml”, a category instance corresponds to a <category> element as shown in the following example.

<category name="state" instance="1" publishTime="2011-04-13T04:52:19.530" container="400" version="87" expireType="user"> <state …>…</state></category>

Enhanced Category Instance DataWhile the formats of a category instance stipulate the data exchange protocol between Lync Server and a Lync Server client, the format of the actual presence information, as represented by the category instance data value, is defined by a presence application. For presence applications to interoperate with each other (that is, to publish and receive presence data), the publishing and subscribing applications must recognize the same presence data format.

In a Lync Server 2010 deployment, the data format of the enhanced presence category instance data value is prescribed by an XML schema. These XML schemas are defined by Lync 2010. The following table lists the XML schemas for the enhanced categories used by Lync 2010.

Table 1. XML schemas of enhanced categories defined by Lync 2010

Category name Category instance data XML schemas

Alerts XSD namespace: “http://schemas.microsoft.com/2006/09/sip/options/alerts”XSD file name: options-Alerts.XSD

calendarData XSD namespace: “http://schemas.microsoft.com/2006/09/sip/calendarData”XSD file name: calendarData.XSD, calendardatatypes.xsd

contactCard XSD namespace: “http://schemas.microsoft.com/2006/09/sip/contactcard”XSD file name: contactCard.xsd, contactCardTypes.xsd

Device XSD namespace: “http://schemas.microsoft.com/2006/09/sip/device”XSD file name: device.xsd, devicetypes.xsd

Note XSD namespace: “http://schemas.microsoft.com/2006/09/sip/note”XSD file name: note.xsd

Mwi XSD namespace: “http://schemas.microsoft.com/2006/09/sip/mwi”XSD file name: msidata.xsd

otherOptions XSD namespace: “http://schemas.microsoft.com/2006/09/sip/options/otherOptions”XSD file name: options-otherOptions.xsd

Routing XSD namespace: “http://schemas.microsoft.com/2006/09/sip/routing”XSD file name: routing.xsd

rccOptions XSD namespace: “http://schemas.microsoft.com/2006/09/sip/options/rccOptions”XSD file name: options-rccOptions.xsd

Services XSD namespace: “http://schemas.microsoft.com/2006/09/sip/service”XSD file name: service.xsd

State XSD namespace: “http://schemas.microsoft.com/2006/09/sip/state”XSD file name: state.xsd, statetypes.xsd

userInformation XSD namespace: “http://schemas.microsoft.com/2006/09/sip/options/userInformation”


Category name Category instance data XML schemas

XSD file name: options-UserInformation.xsd, options.-UserInformationTYpes.xsd

userProperties XSD namespace: “http://schemas.microsoft.com/2006/09/sip/categories”XSD file name: userProperties.xsd

For details about presence data schemas defined in Lync Server, see “Unified Communications Enhanced Presence Schemas for Microsoft Lync Server 2010 Documentation” on the MSDN Library website at http://go.microsoft.com/fwlink/?LinkId=223572.

As an example, let us look at the user state category instance XML schema. The XSD definition for this particular presence state is shown in the following example.

 <xs:complexType name="userState"> <xs:complexContent> <xs:extension base="tns:stateType"> <xs:sequence> <xs:sequence minOccurs="0" maxOccurs="1"> <xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:element ref="ct:delimiter"/> <xs:any namespace="##targetNamespace" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:element ref="ct:end"/> </xs:sequence> <xs:element ref="ct:extension" minOccurs="0" maxOccurs="1"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType>

This example shows that the category instance data type is hierarchical. The userState category instance data type is derived from the abstract stateType category instance data type. In addition to the elements and attributes defined in the base type, the XSD definition in the previous example extends the schema definition of stateType with the <delimiter>, <end>, and <xs:any> extensions, and the application extension (that is, <extension>) to the userState category instance data.

To get the complete definition of the userState category instance data type, we must also look at the base type definition, which is stateType as shown in the following example.

 <xs:complexType name="stateType" abstract="true"> <xs:sequence> <xs:element name="availability" type="xs:unsignedInt" minOccurs="0"/> <xs:element name="activity" type="tns:activityType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="endpointLocation" type="tns:endpointLocationEnumEx" minOccurs="0"/>

<xs:element name="extension" type="tns:extensionType" minOccurs="0" maxOccurs="1"/> </xs:sequence> <xs:attribute name="manual" type="xs:boolean" use="optional" default="false"/> <xs:attribute name="startTime" type="xs:dateTime" use="optional"/> <xs:attribute name="majorVersion" type="xs:unsignedInt" use="optional" /> <xs:attribute name="minorVersion" type="xs:unsignedInt" use="optional" /> <xs:anyAttribute processContents="lax"/> </xs:complexType>

The abstract stateType data type defines the information types of the presence state <availability>, <activity>, and <endpointLocation> elements. These information types can be extended by using an <extension> element. Other information types specify the version numbers, the time that the current presence state is set, and whether or not the presence is set manually.

The complete syntax of the userState category instance data value can be derived from these two XSD definitions as shown in the following example.

<st:state xmlns:st="http://schemas.microsoft.com/2006/09/sip/state" type="userState" manual="xs:boolean" startTime="xs:dateTime" majorVersion="xs:unsignedInt" minorVersion="xs:unsignedInt" [anyAttri]="anyAttribute"> <st:availability>xs:unsignedInt</st:availability> <st:activity>st:activityType</st:activity> <st:endpointLocation>st:endpointLocationEnumEx</st:endpointLocation> <st:extension>st:extensionType</st:extension> <ct:delimiter xmlns:ct="http://schemas.microsoft.com/2006/09/sip/commontypes" /> <[any] xmlns="http://schemas.microsoft.com/2006/09/sip/state">any element</[any]> <ct:end xmlns:ct="http://schemas.microsoft.com/2006/09/sip/commontypes" /> <ct:extension xmlns:ct="http://schemas.microsoft.com/2006/09/sip/commontypes" > <[any] xmlns="any.namespace">...</[any]> <ct:extension></st:state>

Although the category instance data value is schematized, Lync Server does not validate any enhanced presence category instance data against its schema. It does require that the category name be registered with the server and that the category instance data value be a well-formed XML document or fragment.

According to the XML schema in the previous example, a presence state can have zero or one instance of the <availability> element containing an integer value (that is, referred to as the availability number). The semantics of the availability value is specific to the application. In Lync 2010 the availability number has the semantics listed in the following table.

Table 2. The availability number semantics defined by Lync 2010

Availability number range Availability mode


0-2999 Undefined

3000-4999 Available

4500-5999 Available – Idle

6000-7499 Busy

7500-8999 Busy-Idle

9000-11999 Do Not Disturb

12000-17999 Be Right Back

15000-17999 Away

18000 and higher Offline

In addition to the availability number, a state category instance can have an <activity> element to provide a description of what kind of activities the user is currently engaged in. The activity description can be expressed as a token attribute on the <activity> element or an application-defined child element of any name in any namespace. This can be as simple as a locale-specific string. A general description of the syntax of the <activity> element is shown in the following example.

<st:activity xmlns:st="http://schemas.microsoft.com/2006/09/sip/state" token="st:activityTokenEnumEx" maxAvailability="st:unsignedInt" minAvailability="st:unsignedInt" [anyAttri]="anyAttribute"> <ct:delimiter xmlns:ct="http://schemas.microsoft.com/2006/09/sip/commontypes" /> <[any]>any element</[any]> <ct:end xmlns:ct="http://schemas.microsoft.com/2006/09/sip/commontypes" /> <ct:extension xmlns:ct="http://schemas.microsoft.com/2006/09/sip/commontypes" >...<ct:extension></st:state>

When the <activity> element is not specified in a state category instance, Lync uses the default activity string for the given availability number range. The following table shows all the default activity strings and their corresponding availability number range.

Table 3. Default activity strings and their availability number range

Availability number range Default activity string

0-2999 Presence unknown

3000-4999 Available

4500-5999 Inactive

6000-7499 Busy

7500-8999 Busy

9000-11999 Do Not Disturb

12000-17999 Be Right Back

15000-17999 Away

18000 and higher Offline

Unspecified Offline

The activity token attribute can be assigned a standard or custom token value. Standard tokens are those defined and used by Lync and each has a well-defined activity string associated with it. The following table shows the standard activity tokens that are defined by Lync and their associated activity string.


Table 4. Standard activity tokens and associated activity strings, as defined by Lync

Standard activity token Standard activity string

in-a-meeting In a meeting

in-a-conference In a conference

on-the-phone In a call

out-of-office Out of office

urgent-interruptions-only Urgent interruptions only

When a standard token is specified, Lync displays the associated activity string and ignores any custom activity strings. When a custom token is set without also specifying a custom activity string, Lync ignores the non-standard token values and displays the default activity string of the current availability number. When a custom activity string is used, Lync displays this activity string when no token is specified or when a custom token is used. In any case, activity tokens are case-sensitive.

The following example of the <activity> element shows a custom activity string, used in the US-English locale, without the token attribute.

<activity> <custom LCID=”1033”>Out to lunch</custom></activity>

The following example of the <activity> element shows a custom activity string, used in the US-English locale, without a custom token value.

<activity token=”out-to-lunch”> <custom LCID=”1033”>Out to lunch</custom></activity>

Aggregated Category Instance Values and Multiple Points of PresenceLync Server 2010 allows a user to simultaneously sign in from multiple endpoints, such as a mobile phone, a desk phone, a laptop, and a desktop computer. Each endpoint can have a different manifestation of the user’s presence information. The user may be talking on the mobile phone while typing on the laptop computer, leaving the desktop computer idle and the desk phone available to receive incoming calls. For some types of presence information, such as presence states and capabilities, the separate endpoint-specific views of the presence are not necessary and even confusing for a remote presence watcher. Most the presence watchers are not preoccupied with finding out whether or not the presence publisher is active on a laptop or desktop computer, and whether or not the presence entity can answer phone calls by using a mobile phone or desk phone. The watcher is interested in whether the presence entity is available or can take calls regardless of the devices at his or her disposal. Furthermore, the publisher may not want remote watchers to have detailed knowledge of the endpoint-specific presence publications.

This situation is known as multiple points of presence (MPOP). One requirement to support MPOP is to enable aggregation of disparate endpoint-specific presence information into a single view of the effective presence data value that is user specific and not endpoint dependent. In a Lync Server 2010 deployment, the aggregation is supported via a server-hosted aggregation script that implements predefined aggregation logic. For a detailed design of the aggregation logic, see the “[MS-PRES]: Presence Protocol Specification” in the MSDN Library at http://go.microsoft.com/fwlink/?LinkId=223573. Briefly, the aggregation script aggregates the presence state, location, and the device capabilities of the presence


entity. The aggregation results are represented by aggregated category instances, which include aggregateState, aggregateMachineState, and services. The aggregation takes the input from containers 2 and 3, and then outputs the aggregated states (that is, aggregateState and aggregateMachineState) and the aggregated presence capabilities (that is, services) to containers 100, 200, 300, or 400. The aggregation script is invoked whenever a publication of the userState, machineState, phoneState, calendarState, or device category instance is added to, updated in, or deleted from containers 2 or 3.

The two aggregation containers imply that different aggregation logic is at play. Container 2 contains the input for aggregation to produce aggregated presence information to be output into containers 100, 200, 300 and 400. The input includes the userState, machineState, phoneState, calendarState, device and dndState category instances. The output includes aggregateMachineState and services category instances to be placed into containers 100, 200, 300, and 400. The aggregateState category instance to be placed into containers 100, 200, and 400. Container 3 contains the input for aggregation to produce the aggregated result to be output into container 300. The input includes the userState, machineState, phoneState, calendarState, and dndState category instances. The output includes only an aggregateState category instance to be placed into container 300. In other words, container 3 is used to produce the aggregateState category instance specifically for the Workgroup (container 300) contacts (as specified as members of container 3) and container 2 is used to perform all other applicable aggregation. The reason behind such different behaviors is to support the case when a user manually sets the availability number in the range between 9000 and 11999 (Do Not Disturb), the Workgroup contacts will see the availability number of 6900 (Busy - Urgent interruptions only) instead and calls made by a Workgroup contact to the publisher will not be blocked as is the case for other contacts who are shown the “Do Not Disturb” activity string and whose calls will be blocked.

Public and Private Category InstancesPublic category instances contain presence information that can be made available for access by anyone, provided that the consumer has been granted permission. In Lync, public category instances include calendardData, contactCard, note, noteHistory, services, and state and are published to containers 100, 200, 300, and 400. Also, a special category named legacyInterop is published in these containers. It is intended for legacy clients that cannot handle enhanced presence categories. For example, a federated Yahoo! Messenger or Windows Live® Messenger. The Lync is responsible for publishing this data and for ensuring any supported legacy clients receive it. Container 0 is also public container.

Private category instances contain data that is made available to a local client or a local user only. Lync uses private containers to hold private categories. They are intended for local use by the application and the data cannot be accessed by any remote presence entities. The private containers include the Self container (container ID 1) and the Aggregation containers (container IDs 2 and 3). The private categories include alerts, otherOptions, rccOptions, mwi, userInformation, and userProperties categories. Lync also publishes some private categories to the public containers. These include dndState and routing categories. These publications enact routing rules to forward incoming calls made by a member of the container. Remote presence entities can subscribe to private categories, but will not receive any of the category data.

Categories for Application Data and Custom PresenceBased on XML, the enhanced presence category data model is flexible and can be extended to express custom presence information or can be generalized to represent any application data. In fact, such a generalization can be seen in Lync in its representation of the containers as an enhanced presence category. Whenever containers are created or modified, Lync publishes the access control lists (ACLs) as a set of private category


instances of the containers name that are identified by the container IDs and contain specified membership descriptions. To synchronize the access controls among different endpoints, Lync receives the published container categories in the self-subscription.

Custom clients can define application-specific categories to represent any application data it deems necessary, including custom presence data. However, the custom categories must be registered with Lync Server before they can be published or subscribed to. Custom categories are ignored when they are not recognized by other applications.

Enhanced Presence OperationsThe Lync Server 2010 enhanced presence system provides two basic services to support presence applications that use the enhanced presence data model. The first service coordinates publications of category instances and the second one facilitates subscriptions to category instances published by specified presence entities. Subscription also includes querying published category instances.

Before a category can be used in publication or subscription, the name of the category must be registered with Lync Server 2010. To register a category name, you can call the following Microsoft SQL Server® commands against the SQL Server database used by Lync Server 2010:

use rtc

exec RtcRegisterCategoryDef N'aCategoryName'

You can use SQL Server Management Studio to run this command, where rtc refers to the SQL Server database name, RtcRegisterCategoryDef is the name of a stored procedure, and aCategoryName is the name of the category to be registered. To run the commands, you must be a Lync Server 2010 administrator.

PublicationIn Lync, a presence publisher makes his or her presence available to other users by publishing the presence category instances. The publication amounts to specifying one or more containers, adding container members, and placing category instances holding presence data through a SIP request.

Presence publication does not involve direct exchanges between the presence publisher and the presence subscriber. Instead, Lync Server mediates the exchange between the two by delivering presence category instances published in a container on the server to the registered subscribers matching the membership scope of the same container. In the case of a query where the requesting user is not a registered subscriber, the server responds to the client request to return the requested publication, provided that the requesting user is a member of the container.

Publishing Presences Using SIP SERVICE RequestsPublishing presence information as one or more category instances involves sending a SIP request of the SERVICE method from the publisher to the Lync Server. The category instances are included as the payload of the SIP message. When the request is accepted by the server, a SIP response of the 200 OK class is returned to the requesting client with updated category instances included as the roaming data. Notice that this roaming data is also returned to the publisher in a subsequent NOTIFY request issued by the server as part of the self-subscription.

For each category instance, the publisher specifies the category name, container ID, instance ID, version number, expiry type, the applicable expiration time, the time of the


publication, and the actual presence data. For a new category instance, the publisher sets the version number to 0.

Upon receiving the publication request, the server determines whether the specified category instance is a new or existing. For a new category instance (that is, it doesn’t exist), the server instantiates the category, assigns a version number of 0, and places the instance in the specified container. For an existing category instance, the server verifies whether the client-supplied version number is greater than the number on the server or whether the last publication time is earlier than the client-specified publish time. If it does exist, the server updates the publication on the Lync Server and increment the server-maintained version number by one.

After accepting a publication request, the server notifies the registered subscribers, who are members of a container, of the new or updated category instances. When an update results in a deletion of a category instance from the publication, the deleted category instances are excluded from the notification. The Lync Server expects the subscribing client to compare the category instances in a notification with those currently maintained by the client, mark the missing category instances as deleted ones, and remove them from the local cache.

The following is an example of the SIP SERVICE request used to publish a userState category instance to container 2 by an application named PresPub. The user state is described by an availability number (3500), a standard activity token and a custom activity string.

SERVICE sip:[email protected] SIP/2.0FROM: <sip:[email protected]>;epid=1E5C4E59CA;tag=0153ea48TO: <sip:[email protected]>;epid=1E5C4E59CACSEQ: 5 SERVICECALL-ID: 138afca10c4446f5a063925138cd4f26MAX-FORWARDS: 70VIA: SIP/2.0/TLS 192.168.0.155:53594;branch=z9hG4bK96be304fAUTHORIZATION: NTLM realm="SIP Communications Service",targetname="tuk-ocdr1-01.contoso.com",response="0100000000000000dec685fc58268760",crand="70bd108c",cnum="6",opaque="17FC1F24",qop="auth"CONTACT: <sip:[email protected];opaque=user:epid:sCPKlagTB1apRfve3oHuPQAA;gruu>;text;audio;video;imageCONTENT-LENGTH: 609SUPPORTED: gruu-10USER-AGENT: RTCC/4.0.0.0 PresPubCONTENT-TYPE: application/msrtc-category-publish+xml

<publish xmlns="http://schemas.microsoft.com/2006/09/sip/rich-presence"><publications uri="sip:[email protected]"> <publication categoryName="state" instance="536870912" container="2" version="3" expireType="user"> <state xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xsi:type="userState" xmlns="http://schemas.microsoft.com/2006/09/sip/state"> <availability>3500</availability> <activity token="in-a-meeting"> <custom LCID="1033">Some activity</custom> </activity> </state>


</publication> </publications></publish>

The following is the server response of SIP 200 OK to the SERVICE request in the previous example, which can be identified by the corresponding CSEQ and CALL-ID headers. The response includes the affected the category instances as a result of the publication request.

SIP/2.0 200 OKFROM: "Bob"<sip:[email protected]>;epid=1E5C4E59CA;tag=0153ea48TO: <sip:[email protected]>;epid=1E5C4E59CA;tag=A159FEC7C342936628C5CEDC7D11E057CSEQ: 5 SERVICECALL-ID: 138afca10c4446f5a063925138cd4f26VIA: SIP/2.0/TLS 192.168.0.155:53594;branch=z9hG4bK96be304f;received=76.121.173.74;ms-received-port=53594;ms-received-cid=22E61D00CONTENT-LENGTH: 5816CONTENT-TYPE: application/vnd-microsoft-roaming-self+xmlAUTHENTICATION-INFO: NTLM rspauth="01000000000000002C72615B58268760", srand="CFCC1A9B", snum="6", opaque="17FC1F24", qop="auth", targetname="tuk-ocdr1-01.contoso.com", realm="SIP Communications Service"ms-user-logon-data: RemoteUser

<roamingData xmlns="http://schemas.microsoft.com/2006/09/sip/roaming-self" xmlns:cat="http://schemas.microsoft.com/2006/09/sip/categories"> <categories xmlns="http://schemas.microsoft.com/2006/09/sip/categories" uri="sip:[email protected]"> <category name="state" instance="1" publishTime="2011-04-26T17:37:15.397" container="2" version="23" expireType="user"> <state xsi:type="aggregateState" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/2006/09/sip/state"> <availability>3500</availability> <activity token="in-a-meeting"> <custom LCID="1033" xmlns="http://schemas.microsoft.com/2006/09/sip/state">Some activity</custom> </activity> <delimiter xmlns="http://schemas.microsoft.com/2006/09/sip/commontypes" /> <timeZoneBias>420</timeZoneBias><timeZoneName>Pacific Daylight Time</timeZoneName> <timeZoneAbbreviation>Pacific Daylight Time</timeZoneAbbreviation> <device>computer</device> <end xmlns="http://schemas.microsoft.com/2006/09/sip/commontypes" /> </state> </category> <category name="state" instance="268435456" publishTime="2011-04-26T16:19:31.397" container="2" version="35" expireType="user"> <state xsi:type="aggregateMachineState" endpointId="fb00e3d8-689a-53c5-8f6f-b678a337e1a4" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/2006/09/sip/state"> <availability>3500</availability> </state> </category> <category name="state" instance="876227841" publishTime="2011-04-26T16:19:31.397" container="2"


version="1" expireType="endpoint" endpointId="FB00E3D8-689A-53C5-8F6F-B678A337E1A4"> <state xmlns="http://schemas.microsoft.com/2006/09/sip/state" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" manual="false" xsi:type="machineState"> <availability>3500</availability> <delimiter xmlns="http://schemas.microsoft.com/2006/09/sip/commontypes"></delimiter> <timeZoneBias>420</timeZoneBias> <timeZoneName>Pacific Daylight Time</timeZoneName> <timeZoneAbbreviation>Pacific Daylight Time</timeZoneAbbreviation> <device>computer</device> <end xmlns="http://schemas.microsoft.com/2006/09/sip/commontypes"></end> </state> </category> <category name="state" instance="1002993682" publishTime="2011-04-25T16:34:31.607" container="2" version="1" expireType="endpoint" endpointId="458D2A22-9EC7-5D55-B011-F8E31CFE459E"> <state xmlns="http://schemas.microsoft.com/2006/09/sip/state" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" manual="false" xsi:type="machineState"> <availability>15500</availability> <delimiter xmlns="http://schemas.microsoft.com/2006/09/sip/commontypes"></delimiter> <timeZoneBias>420</timeZoneBias> <timeZoneName>Pacific Daylight Time</timeZoneName> <timeZoneAbbreviation>Pacific Daylight Time</timeZoneAbbreviation> <device>deskphone</device> <end xmlns="http://schemas.microsoft.com/2006/09/sip/commontypes"></end> </state> </category> <category name="state" instance="536870912" publishTime="2011-04-26T17:37:15.397" container="2" version="4" expireType="static"> <state xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.microsoft.com/2006/09/sip/state" xsi:type="userState"> <activity token="in-a-meeting"> <custom LCID="1033">Some activity</custom> </activity> </state> </category> <category name="state" instance="1" publishTime="2011-04-26T17:37:15.397" container="100" version="23" expireType="user"> <state xsi:type="aggregateState" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/2006/09/sip/state"> <availability>3500</availability> </state> </category> <category name="legacyInterop" instance="1" publishTime="2011-04-26T17:37:15.397" container="100" version="23" expireType="user"> <legacyInterop availability="3500" /> </category> <category name="state" instance="1" publishTime="2011-04-26T17:37:15.397" container="200"


version="23" expireType="user"> <state xsi:type="aggregateState" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/2006/09/sip/state"> <availability>3500</availability> <activity token="in-a-meeting"> <custom LCID="1033" xmlns="http://schemas.microsoft.com/2006/09/sip/state">Some activity</custom> </activity> <delimiter xmlns="http://schemas.microsoft.com/2006/09/sip/commontypes" /> <timeZoneBias>420</timeZoneBias> <timeZoneName>Pacific Daylight Time</timeZoneName> <timeZoneAbbreviation>Pacific Daylight Time</timeZoneAbbreviation> <device>computer</device> <end xmlns="http://schemas.microsoft.com/2006/09/sip/commontypes" /> </state> </category> <category name="legacyInterop" instance="1" publishTime="2011-04-26T17:37:15.397" container="200" version="23" expireType="user"> <legacyInterop availability="3500" token="in-a-meeting" /> </category> <category name="state" instance="1" publishTime="2011-04-26T17:37:15.397" container="400" version="23" expireType="user"> <state xsi:type="aggregateState" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/2006/09/sip/state"> <availability>3500</availability> <activity token="in-a-meeting"> <custom LCID="1033" xmlns="http://schemas.microsoft.com/2006/09/sip/state">Some activity</custom> </activity><delimiter xmlns="http://schemas.microsoft.com/2006/09/sip/commontypes" /> <timeZoneBias>420</timeZoneBias> <timeZoneName>Pacific Daylight Time</timeZoneName> <timeZoneAbbreviation>Pacific Daylight Time</timeZoneAbbreviation> <device>computer</device> <end xmlns="http://schemas.microsoft.com/2006/09/sip/commontypes" /> </state> </category> <category name="legacyInterop" instance="1" publishTime="2011-04-26T17:37:15.397" container="400" version="23" expireType="user"> <legacyInterop availability="3500" token="in-a-meeting" /> </category> </categories></roamingData>

The results include all the state category instances affected by the publication request due to the aggregation. Publishing a user state into container 2 causes the aggregation script to run. In this example, there were no phone calls or meetings taking place at the time of the publication. Thus, only the userState and machineState instances were used by the aggregation script. It can be inferred from the results that the local user had two devices online. One is a computer and the other is a desk phone. The aggregation script generates


the updated aggregateState, aggregateMachineState, and legacyInterop category instances in container 2 and output aggregateState and legacyInterop to containers 100, 200 and 400. As the result the local user gets notified of the roaming data of the userState, machineState, aggregateMachineState, aggregateState, and legacyInterop category instances in containers 2, 100, 200 and 400.

Note. This publication is an example of the grammar-free publication where the Lync Server honors the client specifications of the category name, instance ID and container Id. For details about grammar-based and grammar-free publications, see the “Enforcing Interoperability with Lync by Using Publication Grammars” section later in this chapter.

Lync publishes a userState category instance using a SIP SERVICE request when the user selects a new availability mode (also known as presence status) in Lync, as illustrated in the following figure.

Figure 2. Availability options in Lync 2010

Other than aggregated categories, all the enhanced presence categories are published by using the SIP SERVICE request. For the state categories, they include userState, machineState, phoneState, and calendarState. Lync designates userState as a manual category, meaning that its value can be set manually by the user, whereas the machineState, calendarState, and phoneState categories are not manual. They are automatically published when, respectively, a device status changes between active and inactive, a phone call is connected, and a scheduled meeting begins.

Understanding Lync Server Presence AggregationLync Server supports aggregation for presence state and presence capabilities. It applies to the state and device categories only. The aggregation script takes the endpoint-dependent device and presence state category instances as input and produces a services and aggregateState categories as output to describe the overall, and endpoint-independent, presence capabilities and availability of the user.


The following table summarizes the four endpoint-dependent state categories that are used as input to the aggregation script.

Table 5. The four main categories of contributors to state in aggregation

Presence source Description

Machine state An endpoint state that describes activity information from a device (for example, a computer or a mobile phone with Microsoft Office Communicator Mobile) expressed as a value indicating ”idle,” ”away,” ”locked.”

User state Describes a user status that is set manually by the user (for example, Do Not Disturb), or that is automatically set by expiration timers that are triggered by user actions (for example, being inactive can cause an Inactivity or Away status).

Phone state Describes events based on the current activity of the phone device that a user is registered on (for example, In a Call or In a Conference)

Calendar state Based on information about items in a presence-aware calendar (for example, Outlook)

A machineState category instance describes the availability status of a device on which Lync runs. Lync publishes a machineState category instance whenever the device status changes as the result of user activity or inactivity. In other words, a machineState category instance is derived from a state of the corresponding device. It is not a manual category and cannot be set by the Lync user manually.

There are fewer availability modes for a machineState instance. Lync uses the following availability modes to describe a machine state.

Table 6. Machine state types and integers assigned to the state

Machine State Type

Availability Activity Description

Active (Busy) 3500 NULL Machine is in use. Detected by keyboard or mouse input when user is logged on.

Inactive 3750 Inactive Device has not been used in the last user-defined number of minutes, but user is still logged on.

Away 15500 NULL Device has not been used in a period of time based on user configurable time value for minutes expired since state has changed to ”Inactive.”

Offline 18500 NULL User is not active and is not logged on.

The userState category describes the availability modes of a user. A user state is endpoint-dependent. For example, a user is active on one device (for example, typing on desktop) while leaving another device logged on, but unattended. In Lync, a userState category instance can have one of the following availability modes.

Table 7. User state types and integers assigned to the state

Availability mode

Availability number

Activity token Description

Available 3500 User is in the available state.

Busy 6500 urgent-interruptions-only (in container 3)

User is in the busy state.

Do Not Disturb 9500 User should not be interrupted.

Be Right Back 12500 User is not currently available.

Appear Away 15500 Manually set by the user to look to other users


as if they are in an Away state.

Off Work 15500 off-work Manually set by the user and is a custom state.

Lync defines userState as a manual category that can be set by the user. When a Lync user selects an entry from the availability menu in the Lync main window, Lync publishes a userState instance containing the chosen availability number and the appropriate activity token, if applicable. When the user selects Available, Be Right Back, Appear Away, or Off Work from the Lync main window, Lync publishes a static userState category instance containing the selected availability mode to containers 2 and 3. The corresponding instance ID is 0x20000000. When the user chooses Busy or Do Not Disturb, Lync publishes a userState category instance as a time-bounded instance that will expire in 24hrs (or 86,400 seconds) if the userState’s availability is not reset by the user before then. The instance ID of the time-bounded userState category instance is 0x24000000. If Busy is chosen, Lync publishes the userState instance in both containers 2 and 3. If Do Not Disturb is selected, Lync places a userState instance containing the availability number of 9500 in container 2, and, in container 3, places another userState instance containing the activity number of 6500 and the activity token of urgent-interruptions-only.

When aggregated, a user’s overall presence, as described by aggregateState, can be Away, Appear Away, and Off Work. These are three distinct presence states that are assigned the same availability number of 15500. It reflects the three different ways of showing that the user is away.

When the Lync user has stopped interacting with all the devices that are running Lync for some time, which is configurable using the Lync Options button, Lync publishes a machineState category instance containing the availability number of 15500 to containers 2 and 3. This causes the aggregation script to create an aggregateState category instance containing the same availability number. The resulting aggregateState category instance is user-bounded and has an instance ID of 1, as shown in the following example.

<state xsi:type="aggregateState" lastActive="2011-04-28T22:38:26" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/2006/09/sip/state"> <availability>15500</availability> <delimiter xmlns="http://schemas.microsoft.com/2006/09/sip/commontypes" /> <timeZoneBias>420</timeZoneBias> <timeZoneName>Pacific Daylight Time</timeZoneName> <timeZoneAbbreviation>Pacific Daylight Time</timeZoneAbbreviation> <device>computer</device> <end xmlns="http://schemas.microsoft.com/2006/09/sip/commontypes" /></state>

As a result, the user’s presence state is described by the default activity string of “Away”. In this state, incoming calls ring first before being forwarded to voice mail when the call is not answered. The “Away” status changes automatically when user activity is detected.

When the Lync user manually sets their availability as “Appear Away”, Lync publishes a static userState category instance to containers 2 and 3, as shown in the following example.

<state xmlns="http://schemas.microsoft.com/2006/09/sip/state" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"


manual="true" xsi:type="userState"> <availability>15500</availability></state>

In response to this publication, the aggregation script updates the aggregateState instance to reflect the new user setting. As a result, the user’s presence icon changes to yellow and the displayed activity string shows the default activity string as “Away”, which is derived from the availability number 15500. The user gets the notifications of incoming calls from any contacts with the necessary permission. As a static category instance, the userState publication remains unchanged until the user resets it manually. This means that the Away status persists in the aggregateState category instance, making the user presence appear as “Away”, no matter what other activities are undertaken by the user, until the user manually changes the status.

When the Lync user selects the Off Work entry from the Availability menu, Lync publishes a static userState category instance as shown in the following example.

<state xmlns="http://schemas.microsoft.com/2006/09/sip/state" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" manual="true" xsi:type="userState"> <availability>15500</availability> <activity token="off-work" minAvailability="15000" axAvailability="17999"> <custom LCID="1033">Off work</custom> </activity></state>

In response to this publication, the aggregation script updates the aggregateState instance with the availability number of 15500 and activity token of off-work. As a result, the user’s presence icon changes to yellow in the Lync main window and the associated activity string reads “Off work”. In this Away state, the user will not be notified of any incoming phone calls because they are automatically routed to voice mail. This userState publication remains unchanged until the user resets it explicitly. This implies that this Away state persists in the aggregateState category instance, making the user presence appear “Off work”, no matter what other activities are undertaken by the user, until the user manually changes the status.

The Appear Away and Off Work modes are sometimes referred to as “lurker modes” because the user can set these states and continue to be aware of everyone else’s status around him or her. All other users think that the user is not active and unavailable.

Lync publishes a phoneState category instance when the user is in a call, which can be a one-on-one conversation or a multiparty conference call. The availability numbers and the corresponding activity tokens are shown in the following table.

Table 8. Phone state presence values based on current user activity on the phone device

Phone state type Availability Activity token Description

In a one-on-one conversation

6500 on-the-phone User is speaking with one person.

In a multiparty conversation 7000 in-a-conference User is speaking with more than one


person.

The following example shows a phoneState category instance when a two-party audio call is in place.

<state xmlns="http://schemas.microsoft.com/2006/09/sip/state" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" manual="false" xsi:type="phoneState"> <availability>6500</availability> <activity token="on-the-phone" minAvailability="6500" maxAvailability="8999" /></state>

Publication of this category instance causes the aggregation script to run and, in turn, to publish an aggregateState category instance containing the availability number (that is, 6500) and activity token (that is, on-the-phone) derived from the input phoneState instance. While the call is in progress, these availability numbers and activity token are reflected in aggregateState and the standard activity string of “In a call” is displayed to show the user’s activity status.

For a multiparty conference call, Lync publishes a phoneState category instance as shown in the following example.

<state xmlns="http://schemas.microsoft.com/2006/09/sip/state" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" manual="false" xsi:type="phoneState"> <availability>7000</availability> <activity token="in-a-conference" minAvailability="7000" maxAvailability="8999"> </activity></state>


The aggregation script takes this as input and produces an aggregateState instance containing the same availability numbers and the activity token. Again, the standard activity string of “In a conference call” is displayed to show the user’s activity status.

Lync publishes a calendarState category instance using the user’s calendar data that is obtained from Microsoft Exchange Server. There are two kinds of calendar information, one describes the working hours and the other describes a consecutive period of free/busy timeslots. Lync maintains 4 days of free/busy timeslots and polls Microsoft Exchange to update the free/busy information every 15 minutes. This default update frequency can be adjusted via a policy implemented by the Lync Server administrator.

The free/busy information is used to determine a calendarState instance. There are four options for a user’s calendar state, as shown in the following table.

Table 9. Calendar states are derived from a presence-aware calendar

Calendar state type Availability Activity token Description

Free 3500 NULL User has no scheduled meetings

Tentative 3500 NULL User has a not-yet accepted meeting

In a meeting 6500 in-a-meeting User has an accepted meeting

Out of Office 3500 out-of-office User is not in the office

The following example shows a calendarState published by Lync when the calendar of a user (that is, [email protected]) indicates a meeting in progress.

<state xmlns="http://schemas.microsoft.com/2006/09/sip/state" manual="false" uri="[email protected]" startTime="2010-07-01T23:30:00Z" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="calendarState"><availability>6500</availability><activity token="in-a-meeting" minAvailability="6500" maxAvailability="8999" /><endpointLocation></endpointLocation><meetingSubject>Project Update and status meeting</meetingSubject><meetingLocation>Online – I’ll forward invite</meetingLocation></state>

The calendarState item in the previous example shows that Bob has a meeting in his calendar for a Project meeting and status update. When this meeting time occurs, Bob’s presence state will be changed to “In a meeting”, indicated by the value 6500. Note that there is a maximum value for this state, as there is for most states. Any value between the minAvailability and the maxAvailability are within the defined range for “in a meeting”. It also indicates that Bob’s possible user states can be Busy to IdleBusy, which both fall into the range of minAvailability to maxAvailability.

Controlling Access to Presence Publications with ContainersA presence publisher uses a set of containers to control who can receive which presence data. The membership of a container defines who will be notified of any new or updated publications and the category instances contained in that container specify what presence data the container members receive.

You can define container membership by specifying one or more SIP URIs (for example, sip:[email protected]) for individual users or presentities, one or more fully qualified


SIP domain names (for example, contoso.com) for anyone in the specified networks, or one of the following special membership scopes:

publicCloud. Includes all External contacts acquired through public internet connectivity, including MSN® network of internet services, AOL, and Yahoo! The contact is recognized as a publicCloud member by network of origin and a non-enterprise SIP domain

sameEnterprise. If a contact is a member of a Lync Server 2010 deployment, they are automatically a member of this group. Note that there is no requirement for same pool, but must be from a recognized SIP domain of the organization.

federated. If a contact is a member of any network with an established federation with a Lync Server 2010 deployment, the contact will be a member of this group. Contact is recognized as federated by the network of origin and is not a SIP domain of the organization, but a member of a federated association.

With a distinct membership specification, a container describes an access level reflecting a specific relationship between the container owner and the container members. The membership specification is also known as the container semantics. A Lync Server 2010 deployment comes with a suite of standard containers with the default membership specifications, as described in the following table.

Table 10. Default containers used in Lync Server 2010 (including system use containers)

Container name Container ID Description of container

Default 0 The container has everyone as its default membership. If a contact is not assigned to any other container, or does not belong to the federated, publicCloud, or sameEnterprise membership groups, the contact is considered a member of the Default container. The contact can receive public category instances published to this container.

Self 1 This container does not have any explicit membership definition. It is maintained for the use by the logged on user only. A local instance of a presence application uses this container to store data needed by the application. The data includes the user’s Contacts list; the user’s own contact information such as the professional title, business address, or telephone numbers; and application settings (for example, the server configurations or group policies).

Aggregation 1 2 This container does not have any explicit membership definition. It is accessible by the server and a local client. It is used to contain the input to the aggregation script to produce the following:

1. The endpoint-independent presence capabilities and location for all of the contacts.

2. The aggregated presence state for members of containers 100, 200, and 400.

Aggregation 2 3 This container does not have any explicit membership definition. It is accessible by the server and a local client. It is used to contain the input to the aggregation script to produce the aggregated presence state for members of container 300, where an availability value between 9000-11999 (Do Not Disturb), will be rendered as 6500 (Busy).

External Contacts 100 This container has a federated membership scope. It allows a federated user to access the public category instances contained in this container.

Colleagues 200 This container has an explicit membership specification of sameEnterprise. It is used to contain category instances intended for the users within the organization.


Container name Container ID Description of container

Workgroup 300 This container does not have any default membership specification. It is used to contain the presence information intended for the contacts that are designated by the local user as his or her team members. The local user assigns another user to his or her Workgroup by adding their SIP URIs to the container.

Friends and Family 400 This container does not have any default membership specification. It is used to contain the presence information intended for the contacts that are designated by the local user as his or her personal contacts. The local user assigns other users as his or her Friends and Family contacts by adding their SIP URIs to this container.

Blocked Contacts 32000 The default membership specification for this container is publicCloud. The local user can add specific SIP URIs (sip:[email protected]), domain names (for example, contoso.com) or membership scopes (that is, publicCloud, federated, or sameEnterprise) to this container. Lync uses this container to specify empty category instances for calendarData, contactCard (other than the user identity), state, services, and note to ensure that the information cannot be discerned by the specified members. Lync also specifies the local user’s identity as the only contact information (that is, contactCard of instance ID 0) available to the blocked container members so that the local user can be queried by anyone in the network, including the blocked contacts. Lync publishes the availability number of 15500 (that is, aggregateState and legacyInterop) to this container to make sure that the local user appears Offline to the blocked contacts. It also places a Block routing category instance to explicit block incoming calls from any of the specified blocked contacts.

With the containers (or the container semantics) defined, a publishing client can publish different category instances of the same category name to different containers. This allows the local user to let different contacts see different parts of his or her presence information. For example, the local user can include the home phone number in a contactCard instance for the Family and Friends contacts, but only show the work phone number in the contactCard instance for the other contacts. Another example would involve publishing a personal note containing the emergency contact information for the Workgroup and Family and Friends contacts while leaving out that information for all the other contacts.

It is possible that a member in one container may be also a member of another container. For example, any Workgroup contact is also a Colleagues contact or a SIP URI is assigned multiple times to different containers. The situation presents a potential conflict as to which container (and the category instances contained therein) should be made available to the contact. In Lync Server 2010, such potential conflicts are resolved by the rule that data contained in the higher numbered container will be made available to a contact who is members of multiple containers. This rule ensures that the Workgroup contacts always see the presence data in the Workgroup container, not the data in the Colleagues container. Also, if a user is a member of both the Colleagues and Blocked Contacts containers, the user will be blocked from seeing any of the owner’s presence information, except for the owner’s identity.

The following diagram shows more examples of how containers are used to publish different presence data for different contacts and how containers are resolved when a contact is a member of multiple containers.


Figure 3. Containers with published category data (resolved from highest container number to lowest)


To summarize, containers function like an access control list (ACL) and the container ID number serves to resolve which ACL is used when multiple ACLs are present. The resolution logic works as follows:

1. Member search begins at the highest numbered container and continues through to the lowest, until a match is made.

2. If a group or contact SIP URI is found in container 32000 (that is, Blocked Contacts), the search stops and the contained category data is used.

3. If a contact is found in container 400 (that is, Friends and Family), the search stops and the published category data is used.

4. If a contact is found in container 300 (that is, Workgroup), the search stops and the published category data is used.

5. If a contact is found in container 200 (that is, Colleagues) OR if the subscriber is a member of the sameEnterprise group, the search stops and the contained category data is used.

6. If there is no match, container 0 (that is, Default) is used. The contained category data is used.

In Lync, a local user can view the access levels of his or her contacts by choosing the Relationship view in the Lync main window, as shown in the following figure.

Figure 4. Group, Status, and Relationship are three possible contact views


Enforcing Interoperability with Lync by Using Publication GrammarsIn general, presence is specific to the application. For different presence applications, the same presence data might serve different purposes or have different representations. When multiple types of presence applications operate independently, the publication rules of different presence applications may collide. To avoid such conflicts, an application can use a publication grammar to inform other applications of its publication logic and the other applications should follow the publication grammar to ensure that the same publication rules are adhered to. A publication grammar prescribes a set of publication rules that declare what containers are used, how the memberships are assigned to the containers, and how a particular presence category is published to certain containers.

As a presence application, Lync defines the default enhanced presence categories supported by Lync Server 2010. Other presence applications can use such categories by following the syntax and semantics stipulated by Lync. They can also extend the default categories in their own ways or create custom presence categories to satisfy their own needs. In any case, a presence application running in a Lync Server 2010 deployment must be aware of the presence data structure defined by Lync and how they are published if it is to interoperate smoothly with Lync, which describes the presence data structure in a set of XML schemas for enhanced presence categories and provides the publication grammars via in-band provisioning from the Lync Server.

In a presence publication following the publication grammar defined by Lync, the publisher is required to specify the category name and the category data. The specification of a container ID is ignored. For example, when a note category instance is published or updated according to the publication grammar defined by Lync, the Lync Server follows the grammar rules to place the new note data into containers 200, 300, and 400. Lync Server also places an empty note category instance in containers 100 and 32000. To make the new note data available to the members of container 100, you must use a grammar-free publication. Obviously, this presents a conflict with Lync and such interference could cause Lync or other presence applications to behave unexpectedly. Lync Server 2010 also supports grammar-free publications by a presence application.

Enabling Enhanced Privacy Mode in Presence PublicationsLync 2010 defines two publication grammars for presence publications. One set of publication grammars is used in the standard privacy mode and the other is used in the enhanced privacy mode. In the enhanced privacy mode, the publication grammar specifies the container semantics only and the user must explicitly specify what presence data should be published. By default, no presence data should be made available in the enhanced privacy mode. In contrast, a set of default category instances are published, without any user intervention, in the standard privacy mode of the presence publications. In this mode, all non-blocked users can view the local user’s presence and availability. The standard privacy mode is enabled as the default or as-deployed mode.

In the standard privacy mode, Lync provides the user with the following options to determine how the user’s presence data is displayed:

I want everyone to be able to see my presence regardless of system settings (override default settings)

I want the system administrator to decide–currently everyone can see my presence but this could change in the future


The user can set this option on the Status page in Lync, as shown in the following figure.

Figure 5. Status options with the standard privacy mode selected

The enhanced privacy mode is enabled by the Lync Server administrator using the following Windows PowerShell® command line interface cmdlet:

Get-CsPrivacyConfiguration | Set-CsPrivacyConfiguration –EnablePrivacyMode $True

The following figure shows the output of this Windows PowerShell cmdlet.

Figure 6. Set-CsPrivacyConfiguration enables Enhanced privacy, but warns you of the potential side effects with client versions

Note. The Windows PowerShell command in the previous figure performs a global configuration of privacy. Piping the result of Get-CsPrivacyConfiguration into Set-CsPrivacyConfiguration with the EnablePrivacyMode parameter enables Enhanced Privacy for all client policies configured.

Client version control, which dictates what client versions can log on to Lync Server 2010, can help to limit the impact of clients that cannot consume presence in an organization where enhanced privacy mode has been set. Client version control works by reading the SIP messages from a client. Each client posts a user agent string in the SIP message. Client version control reads the user agent string, and then grants or blocks the ability of a client to log on based on the information in the policy. For details about client version control, see “Client Administration” available for download from the Microsoft Download Center at http://go.microsoft.com/fwlink/?LinkId=211003.

After enhanced privacy mode is enabled, Lync provides the user with two new options to decide how to display his or her presence data. The user can set the option by using the Status page in the Lync Options window, as shown in the following figure.


Figure 7. Enhanced privacy mode set by administrative policy

You may need to sign out and then sign in again to see the new options after the enhanced privacy mode is turned on. The first option lets the user opt out of the enhanced privacy mode and revert to the standard privacy mode. The second option enables the user to opt in to the enhanced privacy mode.

When a user switches from the standard privacy mode to the enhanced presence mode, the user’s contacts, containers, and subscriptions are migrated to enhanced privacy settings. The transition does not happen immediately because background work to move the current settings into the new XML schema requires some time.

To illustrate the workflow of the transition, let’s look at an example that follows a user (for example, [email protected]) switching from the standard privacy mode to enhanced presence mode.

When the standard privacy mode is enabled, Lync receives the following presence policy when the user signs in.

<provisionGroup name="presencePolicyV2" ><propertyEntryList ><property name="EnablePrivacyMode" >false</property><property name="AutoInitiateContacts" >true</property><property name="PublishLocationDataDefault" >true</property><property name="DisplayPublishedPhotoDefault" >true</property><property name="PersonalNoteHistoryDepth" >3</property><property name="SubscribeToCollapsedDG" >true</property></propertyEntryList></provisionGroup>

When the enhanced privacy mode is enabled, Lync receives the following presence policy when the user signs in.

<provisionGroup name="presencePolicyV2" ><propertyEntryList ><property name="EnablePrivacyMode" >true</property><property name="AutoInitiateContacts" >true</property><property name="PublishLocationDataDefault" >true</property><property name="DisplayPublishedPhotoDefault" >true</property><property name="PersonalNoteHistoryDepth" >3</property><property name="SubscribeToCollapsedDG" >true</property></propertyEntryList></provisionGroup>

When the user first selects the enhanced privacy mode while still in the standard privacy mode, Lync publishes an otherOptions category instance containing the new privacy mode selection and the existing privacy mode settings. The instance ID of this category instance is 2 and the publication is targeted to container 1. These are included as a SERVICE request payload that is shown in the following example.

<publish xmlns="http://schemas.microsoft.com/2006/09/sip/rich-presence"> <publications uri="sip:[email protected]"> <publication categoryName="otherOptions" instance="2" container="1" version="6" expireType="static"> <otherOptions xmlns="http://schemas.microsoft.com/2006/09/sip/options/otherOptions">


<privacyModeUserSelection>private</privacyModeUserSelection> <currentPrivacyMode>standard</currentPrivacyMode> <lastQueryPrivacyEnabled>true</lastQueryPrivacyEnabled> <publishActivityHistory>true</publishActivityHistory> </otherOptions>

</publication> </publications></publish>

While in the process of migrating from the standard privacy mode to the enhanced privacy mode, Lync publishes the otherOptions category instance containing migrattingToPrivacy as the value of the <currentPrivacyMode> element. This communicates that migration is underway to the new enhanced privacy mode.

<publish xmlns="http://schemas.microsoft.com/2006/09/sip/rich-presence"> <publications uri="sip:[email protected]"> <publication categoryName="otherOptions" instance="2" container="1" version="7" expireType="static"> <otherOptions xmlns="http://schemas.microsoft.com/2006/09/sip/options/otherOptions"> <privacyModeUserSelection>private</privacyModeUserSelection> <currentPrivacyMode>migratingToPrivacy</currentPrivacyMode> <lastQueryPrivacyEnabled>true</lastQueryPrivacyEnabled> <publishActivityHistory>true</publishActivityHistory> </otherOptions> </publication></publications></publish>

Behind the scenes, the migration involves a number of specific steps, including the following: containers and their membership specifications must be readjusted; any existing membership groups (that is, federated, publicCloud, and sameEnterprise) need to be removed; and the access control entries on the containers need to be changed. Lync does this by submitting a SERVICE request containing a setContainerMemers command in the payload and specifying as the Content-Type header value “application/msrtc-setcontainermembers+xml”. Following is an example of this SIP message.

SERVICE sip:[email protected] SIP/2.0Via: SIP/2.0/TLS 192.168.0.40:65000Max-Forwards: 70From: <sip:[email protected]>;tag=070d2df50e;epid=5fb4cad0caTo: <sip:[email protected]>Call-ID: f065c07412b84c9bab011f1d1a9aeb0eCSeq: 1 SERVICEContact: <sip:[email protected];opaque=user:epid:-NkxRZvAY1GqwgtgoyCyOwAA;gruu>User-Agent: UCCAPI/4.0.7577.0 OC/4.0.7577.0 (Microsoft Lync 2010)Proxy-Authorization: TLS-DSK qop="auth", realm="SIP Communications Service", opaque="FF54A518", targetname="LYNC-SE.contoso.com", crand="1e9b779b", cnum="34", response="d5676513165378f83f38665eff97555fce66a313"Content-Type: application/msrtc-setcontainermembers+xmlContent-Length: 487

<setContainerMembers xmlns="http://schemas.microsoft.com/2006/09/sip/container-management">


<container id="100" version="3"><member action="remove" type="federated"/>

</container> <container id="200" version="4">

<member action="add" type="user" value="[email protected]"/><member action="add" type="user" value="[email protected]"/><member action="add" type="user" value="[email protected]"/><member action="remove" type="sameEnterprise"/>

</container></setContainerMembers>

In the previous example, the sameEnterprise membership group is removed from containers 100 and 200 and Anahita, Cynthia, and HelpDesk are added explicitly as members of container 200. These updates ensure that no contact is implicitly granted access permissions.

In Lync 2010, any of the remote contacts running a client of Office Communicator 2007, Office Communicator 2007 R2, Live Communications Server 2005, or Live Communications Server 2003 are blocked from seeing the presence of a user who has the enhanced privacy mode enabled.

Privacy modes affect how Lync collects and publishes presence information. The following table summarizes the effect of the privacy modes.

Table 11. Presence information available to contacts in the public containers defined in Lync

Presence information Blocked External Colleagues Workgroup Friends and Family

Presence State ○ • • •Display Name • • • • •Email Address • • • • •Title * • • • •Work Phone * • • • •Mobile Phone * • • • •Home Phone * •Other Phone •Company * • • • •Office * • • • •Work Address * • • • •SharePoint Site * • • • •Meeting Location # ○ •Meeting Subject # ○ •Free Busy • • • •Working Hours • • • •No Location • • •Location # ○ ○ • •Notes (Out-of-Office Note) • • • •Notes (Personal) • • • •Last Active ○ ○ ○ •Personal/Active Directory Photo# ○ • • •

Note. The following symbols in the table indicate specific behavior:

* Indicates that if the attribute is defined in Active Directory, the information will be available to all contacts in your company, regardless of access level. They are also visible to federated contacts.


# Indicates that sharing is disabled by default for these attributes. The end user must opt-in to share these attributes, confirm that the attributes will be shared before the information is shared.

• Indicates that data is shared when running under the enhanced privacy mode.

○ Indicates that data is not shared when running under the enhanced privacy mode .

Roaming Application DataIn addition to making a local user’s presence available to remote users, a presence application can use the presence publication mechanism to roam application-specific data across multiple endpoints that are logged on. Roaming data is private and for local consumption only. It is published to the Self container (that is, container 1). For example, after a user selects the “Notify me when someone adds me to his or her contact list” option on the Alerts page in the Lync Options window, as shown in the following figure.

Figure 8. Alerts options

Lync publishes the following SIP SERVICE request containing an alerts category instance to the user’s Self container (that is, container 1) as shown in the following example.

SERVICE sip:[email protected] SIP/2.0Via: SIP/2.0/TLS 192.168.0.155:62154Max-Forwards: 70From: <sip:[email protected]>;tag=62aec7b75a;epid=16ce6a1da0To: <sip:[email protected]>Call-ID: 89e08728a9b842b9a4a469c044d7e733CSeq: 1 SERVICEContact: <sip:[email protected];opaque=user:epid:2OMA-5poxVOPb7Z4ozfhpAAA;gruu>User-Agent: UCCAPI/4.0.7577.0 OC/4.0.7577.0 (Microsoft Lync 2010)Proxy-Authorization: TLS-DSK qop="auth", realm="SIP Communications Service", opaque="D5ED691E", targetname="Pool01.contoso.com", crand="e37c5e78", cnum="60", response="569395c91b5e3c001ec8065b94a56634ce3dd204"Content-Type: application/msrtc-category-publish+xmlContent-Length: 326

<publish xmlns="http://schemas.microsoft.com/2006/09/sip/rich-presence"> <publications uri="sip:[email protected]"> <publication categoryName="alerts" instance="0" container="1" version="8" expireType="static"> <alerts xmlns="http://schemas.microsoft.com/2006/09/sip/options/alerts"/> </publication>


</publications></publish>

When the request is accepted, Lync Server responds with the following SIP 200 OK message as shown in the following example.

SIP/2.0 200 OKms-user-logon-data: RemoteUserAuthentication-Info: TLS-DSK qop="auth", opaque="D5ED691E", srand="A85DA2CE", snum="60", rspauth="b25dc9096a20a93ecb712606cc42d980bea07665", targetname="Pool01.contoso.com", realm="SIP Communications Service", version=4Content-Length: 497From: "Anahita"<sip:[email protected]>;tag=62aec7b75a;epid=16ce6a1da0To: <sip:[email protected]>;tag=9B07C1614112F9B18B8C6D8A525986E4Call-ID: 89e08728a9b842b9a4a469c044d7e733CSeq: 1 SERVICEVia: SIP/2.0/TLS 192.168.0.155:62154;received=157.54.125.148;ms-received-port=62154;ms-received-cid=23705D00Content-Type: application/vnd-microsoft-roaming-self+xml

<roamingData xmlns="http://schemas.microsoft.com/2006/09/sip/roaming-self" xmlns:cat="http://schemas.microsoft.com/2006/09/sip/categories"> <categories xmlns="http://schemas.microsoft.com/2006/09/sip/categories" uri="sip: [email protected]"> <category name="alerts" instance="0" publishTime="2011-05-06T03:36:33.340" container="1" version="9" expireType="static"> <alerts xmlns="http://schemas.microsoft.com/2006/09/sip/options/alerts"></alerts> </category> </categories></roamingData>

The roaming data is also returned in the self-subscription, which is discussed in details in the next section.

SubscriptionPresence subscription provides a mechanism for a presence watcher to receive specified presence information published by a given publisher, provided that the watcher is granted permission by the publisher to access the presence data. The process involves interactions, in the form of SIP messages, between the presence watcher and the server.

In a Lync Server 2010 deployment, a watcher can receive the published presence data through persistent subscription, polling subscription or query. The persistent subscription is characterized by the Lync Server pushing the data whenever a publication is created or modified. In a polling subscription, the Lync Server client periodically queries the server to obtain the data. The difference between a subscription and a query lies in the fact that the subscription is tied to a period of time whereas the query is one-time only. The difference between a persistent subscription and a polling subscription lies in the fact that a SIP dialog is involved in a persistent subscription whereas it is not in a polling subscription.

Receiving Presence Publications by Using SIP SUBSCRIBE RequestsOperationally, the persistent subscription, polling subscription, and query all start with a client submitting a SIP SUBSCRIBE request that contains the specified category names and


publishers SIP URIs. All of the SUBSCRIBE requests are submitted to the Lync Server, not directly to the individual publishers. In a query or a polling subscription, the SUBSCRIBE request has an expiration time of zero (0), whereas it is not specified in the SUBSCRIBE request in a persistent subscription.

The following example describes a SUBSCRIBE request made by Lync for the local user ([email protected]) in a query or as part of polling subscription to receive to the noteHistory of a remote user ([email protected]).

SUBSCRIBE sip:[email protected] SIP/2.0Via: SIP/2.0/TLS 192.168.0.40:54364Max-Forwards: 70From: <sip:[email protected]>;tag=8654485aef;epid=5fb4cad0caTo: <sip:[email protected]>Call-ID: 6ce5f131bf60434c9cf15b14bf82f48eCSeq: 1 SUBSCRIBEContact: <sip:[email protected];opaque=user:epid:-NkxRZvAY1GqwgtgoyCyOwAA;gruu>User-Agent: UCCAPI/4.0.7577.0 OC/4.0.7577.0 (Microsoft Lync 2010)Event: presenceAccept: application/msrtc-event-categories+xml, application/xpidf+xml, text/xml+msrtc.pidf, application/pidf+xml, application/rlmi+xml, multipart/relatedSupported: com.microsoft.autoextendSupported: ms-benotifyProxy-Require: ms-benotifySupported: ms-piggyback-first-notifyExpires: 0Require: adhoclist, categoryListSupported: eventlistProxy-Authorization: TLS-DSK qop="auth", realm="SIP Communications Service", opaque="279520A0", targetname="LYNC-SE.contoso.com", crand="fa6dbab7", cnum="14", response="c51d1c2ae8c63ed10d6a87d68646ea1e62c10a92"Content-Type: application/msrtc-adrl-categorylist+xmlContent-Length: 355

<batchSub xmlns="http://schemas.microsoft.com/2006/01/sip/batch-subscribe" uri="sip:[email protected]" name=""> <action name="subscribe" id="103843728"> <adhocList> <resource uri="sip:[email protected]"/> </adhocList> <categoryList xmlns="http://schemas.microsoft.com/2006/09/sip/categorylist"> <category name="noteHistory"/> </categoryList>

</action></batchSub>

The previous request is either from a query or part of a polling subscription because the Expires header value is set to zero (0). In a persistent subscription, the Expires header will be absent from the SUBSCRIBE request.


When accepted, the server responds with an SIP 200 OK response containing the requested data. An example of the SIP response to this SIP SUBSCRIBE request is shown in the following example.

SIP/2.0 200 OKContact: <sip:LYNC-SE.contoso.com:5061;transport=tls>Authentication-Info: TLS-DSK qop="auth", opaque="279520A0", srand="5B6EFD4F", snum="15", rspauth="1891e3d14c9822c7dc1589cf3479fc9febd67bed", targetname="LYNC-SE.contoso.com", realm="SIP Communications Service", version=4Content-Length: 769From: "Bob"<sip:[email protected]>;tag=8654485aef;epid=5fb4cad0caTo: <sip:[email protected]>;tag=BE180080Call-ID: 6ce5f131bf60434c9cf15b14bf82f48eCSeq: 1 SUBSCRIBEVia: SIP/2.0/TLS 192.168.0.40:54364;ms-received-port=54364;ms-received-cid=380900Expires: 0Require: eventlistContent-Type: multipart/related; type="application/rlmi+xml";start=resourceList; boundary=bfd74156b52c441c98b8e3d27b840bbeEvent: presencesubscription-state: terminated;expires=0ms-piggyback-cseq: 1Supported: ms-benotify, ms-piggyback-first-notify

--bfd74156b52c441c98b8e3d27b840bbeContent-Transfer-Encoding: binaryContent-ID: resourceListContent-Type: application/rlmi+xml

<list xmlns="urn:ietf:params:xml:ns:rlmi" uri="sip:[email protected]" version="0" fullState="false"/>

--bfd74156b52c441c98b8e3d27b840bbeContent-Transfer-Encoding: binaryContent-Type: application/msrtc-event-categories+xml

<categories xmlns="http://schemas.microsoft.com/2006/09/sip/categories" uri="sip:[email protected]"> <category name="noteHistory" instance="1864567" publishTime="2010-12-29T20:19:02.937"> <noteHistory xmlns="http://schemas.microsoft.com/2006/09/sip/note"> <body type="personal" uri="">LYNC 2010 is COOL!!!</body> </noteHistory> </category></categories>


The payload of this SIP response has two related parts. The first part lists the SIP URI of the subscribing user (that is, sip:[email protected] in this example). The second part contains the subscribed category data published by the specified remote user (that is, sip:[email protected] in this example). You can verify that this is indeed the response to the preceding SIP SUBSCRIBE request by checking that the Call-ID and CSeq headers values match in the both messages.

For a query, this is all that happens and the operation completes. For a polling subscription, the Lync Server client repeats the process at a given time interval. For a persistent subscription, the Lync Server pushes the publication down to the subscribers by sending them a NOTIFY or BENOTIFY request containing the requested presence category data whenever the data is created, modified, or removed. For the NOTIFY request, the server expects the client to respond with SIP response. For the BENOTIFY request, a client response is not needed. The process continues until the subscription is terminated, at the request of the subscribing client or when the subscribing user logs off.

Optimizing Lync Server Load with Presence Policy in Persistent Subscription or by Using Polling SubscriptionFor persistent subscription, Lync Server must maintain a list of presence subscribers for each presence publisher. Due to the resource constraints on the server, this number is limited. The maximum number is specified in the presence policy settings that can be configured by a Lync Server 2010 administrator.

A presence policy has the following properties:

CategorySubscriptions. This is the maximum number of categories that can be subscribed to on a presence publisher. The value of this property ranges between 0 and 3000, inclusively. When this is set to zero, no one can persistently subscribe to any presence of a presentity. If it is greater than zero, the maximum number of persistent subscribers permitted on a presentity is determined by the CategorySubscriptions value divided by the number of subscribed categories. If CategorySubscriptions is set to 3000 and a client chooses to subscribe to a single category (for example, the state category), the maximum number of persistent subscribers is 3000. If a client subscribes to two categories (for example, the state and note categories), the maximum number of persistent subscribers is 1500.

PromptedSubscribers. This is the maximum number of queued presence subscription alerts. It determines the maximum number of prompts that a user can get when someone else subscribes to his or her presence. The value ranges between 0 and 500. The zero value means that the user is not notified when he or she is added to a persistent subscription by someone else. When the number of persistent subscriptions in the queue reaches the limit set by this property, the user will not be notified of any additional subscription attempts.

By default, Lync Server 2010 is configured with the following presence policies:

Default Policy. This is the default presence policy for typical users in which the CategorySubscriptions property is set to 1000 and the PromptedSubscribers property is set to 200.

Service: Medium. This is the presence policy for applications or services in which a large number of users must subscribe to the presence published by the applications or services. The CategorySubscriptions property is set to 3000 and the PromptedSubscribers property is set to 0.


Setting too high a value on the CategorySubscriptions property can have a significant adverse impact on the server’s performance when the average user has a large number of persistent presence watchers. Setting a value too low on this property may prevent some contacts from receiving the presentity's presence at all. For a popular contact whose presence is subscribed to by many other users, it is possible that the contact's presence may appear unknown to some subscribers. For information about how to configure the presence policy, see “Managing Presence Policies” in the TechNet Library at http://go.microsoft.com/fwlink/?LinkId=188704.

When the required number of persistent subscriptions reaches beyond the maximum limit or when the maximum value is too high to ensure reliable performance, a presence application can resort to polling subscriptions in which the presence policy setting of the CategorySubscriptions property does not apply and there is no limit on how many presence watchers the server can handle.

Receiving Contacts Lists before Subscribing to Their PresenceA Contacts list consists of a list of the SIP URIs of the remote users (or presentities) whose presence is monitored in a remote subscription. A remote user is added to the Contacts list when the local user copies the remote user to a contact group. Lync stores the Contacts list on the Lync Server. When the local user adds a contact to a contact group, Lync submits a SERVICE request to the Lync Server. The message payload contains the specified contact’s SIP URI and group ID within a SOAP envelope. Following is an example of the SERVICE request.

SERVICE sip:LYNC-SE.contoso.com:5061;transport=tls;ms-fe=LYNC-SE.contoso.com SIP/2.0Via: SIP/2.0/TLS 10.80.24.214:62084Max-Forwards: 70From: <sip:[email protected]>;tag=0c40725f3c;epid=16ce6a1da0To: <sip:[email protected]>;tag=1DA1AD6CCall-ID: 47b40f5af3d143279a714400c5e34808CSeq: 4 SERVICEContact: <sip:[email protected];opaque=user:epid:2OMA-5poxVOPb7Z4ozfhpAAA;gruu>User-Agent: UCCAPI/4.0.7577.0 OC/4.0.7577.0 (Microsoft Lync 2010)Supported: msrtc-ucsProxy-Authorization: TLS-DSK qop="auth", realm="SIP Communications Service", opaque="3B6A34E9", targetname="LYNC-SE.contoso.com", crand="86d0dd90", cnum="147", response="80e1ae82866dbbfd7aed0a8308dfa9c2c2945a6c"Content-Type: application/SOAP+xmlContent-Length: 533

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"><SOAP-ENV:Body><m:setContact xmlns:m="http://schemas.microsoft.com/winrtc/2002/11/sip"><m:displayName/><m:groups>1 6 </m:groups><m:subscribed>true</m:subscribed><m:URI>sip:[email protected]</m:URI><contactExtension><contactSettings source="outlook" contactId="7bc6ef25-b06b-4305-9fc6-ebb1a780787b"></contactSettings>

</contactExtension><m:externalURI></m:externalURI><m:deltaNum>137</m:deltaNum></m:setContact>


http://go.microsoft.com/fwlink/?LinkId=188704

</SOAP-ENV:Body></SOAP-ENV:Envelope>

In this example, the SERVICE request is made to the server (that is, sip:LYNC-SE.contoso.com) by the local user (that is, Bob Kelly) to add Anahita to contact groups 1 and 6. New contact groups are added to the server in the same fashion with a different SOAP envelope containing the specified contact group. The following example illustrates this SOAP message body for creating a contact group named “New Group.”

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body><m:addGroup xmlns:m="http://schemas.microsoft.com/winrtc/2002/11/sip"> <m:name>New Group</m:name> <m:externalURI/> <m:deltaNum>135</m:deltaNum> </m:addGroup> </SOAP-ENV:Body></SOAP-ENV:Envelope>

To receive the presence publication or update of the contacts, Lync first retrieves the Contacts list, including contact groups, from the Lync Server. It does so, after the user is signed in, by submitting the following SUBSCRIBE request without a payload.

SUBSCRIBE sip:[email protected] SIP/2.0Via: SIP/2.0/TLS 192.168.0.40:54364Max-Forwards: 70From: <sip:[email protected]>;tag=44f75f3015;epid=5fb4cad0caTo: <sip:[email protected]>Call-ID: 70cf12e227d7463db7b282ab6c4dff37CSeq: 1 SUBSCRIBEContact: <sip:[email protected];opaque=user:epid:-NkxRZvAY1GqwgtgoyCyOwAA;gruu>User-Agent: UCCAPI/4.0.7577.0 OC/4.0.7577.0 (Microsoft Lync 2010)Event: vnd-microsoft-roaming-contactsAccept: application/vnd-microsoft-roaming-contacts+xmlSupported: com.microsoft.autoextendSupported: ms-benotifyProxy-Require: ms-benotifySupported: ms-piggyback-first-notifyProxy-Authorization: TLS-DSK qop="auth", realm="SIP Communications Service", opaque="279520A0", targetname="LYNC-SE.contoso.com", crand="1b0f2b97", cnum="3", response="0d63b6b06fa75d6e1d6498ae1b4f020a509c00c6"Content-Length: 0

The Event header value is specified as “vnd-microsoft-roaming-contacts” and Accept header value is “application/vnd-microsoft-roaming-contacts+xml”.


The server returns the results in a SIP 200 OK response, as shown in the following example.

SIP/2.0 200 OKContact: <sip:LYNC-SE.contoso.com:5061;transport=tls>Authentication-Info: TLS-DSK qop="auth", opaque="279520A0", srand="B0FB0C3F", snum="3", rspauth="b8bb693aec8cf66fbdb40f3749257bad34bcf91c", targetname="LYNC-SE.contoso.com", realm="SIP Communications Service", version=4Content-Length: 585From: "Bob"<sip:[email protected]>;tag=44f75f3015;epid=5fb4cad0caTo: <sip:[email protected]>;tag=01FD4572Call-ID: 70cf12e227d7463db7b282ab6c4dff37CSeq: 1 SUBSCRIBEVia: SIP/2.0/TLS 192.168.0.40:54364;ms-received-port=54364;ms-received-cid=380900Expires: 27503Content-Type: application/vnd-microsoft-roaming-contacts+xmlEvent: vnd-microsoft-roaming-contactssubscription-state: active;expires=27503ms-piggyback-cseq: 1Supported: ms-benotify, ms-piggyback-first-notify

<contactList deltaNum="7" ><group id="1" name="~" externalURI="" /><group id="2" name="Pinned Contacts" externalURI="<groupExtension groupType="pinnedGroup"><email/></groupExtension>" /><contact uri="[email protected]" name="" groups="1" subscribed="true" externalURI="" /><contact uri="[email protected]" name="" groups="1" subscribed="true" externalURI="" ><contactExtension><contactSettings source="outlook" contactId="4ae7fb20-11b7-4acd-9932-b01a3629e8dc" ></contactSettings></contactExtension></contact></contactList>

As returned in this example, groups 1 and 2 are two default contact groups. The first one corresponds to the “Other Contacts” group on the Lync Groups page. The second group is used by Lync and is not visible to the user.

Receiving Remote Presence by Using a Persistent SubscriptionAfter the Contacts list is received, a Lync Server client can start to subscribe to the presence of the remote contacts. This can be done using a polling or persistent subscription. The following SUBSCRIBE request initiates a persistent subscription for the local user (that is, [email protected] in this example) to receive new or updated presence publications (that is, calendarData, contactCard, note, services, and state) by the remote users (that is, [email protected] and [email protected] in this example).

SUBSCRIBE sip:[email protected] SIP/2.0Via: SIP/2.0/TLS 192.168.0.155:51390Max-Forwards: 70From: <sip:[email protected]>;tag=81643067ba;epid=16ce6a1da0To: <sip:[email protected]>


Call-ID: f0dc3382e27740a989d8145f2fc33583CSeq: 1 SUBSCRIBEContact: <sip:[email protected];opaque=user:epid:2OMA-5poxVOPb7Z4ozfhpAAA;gruu>User-Agent: UCCAPI/4.0.7577.0 OC/4.0.7577.0 (Microsoft Lync 2010)Event: presenceAccept: application/msrtc-event-categories+xml, application/xpidf+xml, text/xml+msrtc.pidf, application/pidf+xml, application/rlmi+xml, multipart/relatedSupported: com.microsoft.autoextendSupported: ms-benotifyProxy-Require: ms-benotifySupported: ms-piggyback-first-notifyRequire: adhoclist, categoryListSupported: eventlistProxy-Authorization: TLS-DSK qop="auth", realm="SIP Communications Service", opaque="EF9CEB7C", targetname="Pool01.contoso.com", crand="d3e6517a", cnum="13", response="555c0bb62826a14fbc4cd3c52a550478f2f148c5"Content-Type: application/msrtc-adrl-categorylist+xmlContent-Length: 1476

<batchSub xmlns="http://schemas.microsoft.com/2006/01/sip/batch-subscribe" uri="sip:[email protected]" name=""><action name="subscribe" id="181311632"><adhocList><resource uri="sip:[email protected] "/><resource uri="sip:[email protected] "/></adhocList><categoryList xmlns="http://schemas.microsoft.com/2006/09/sip/categorylist"><category name="state"/><category name="contactCard"/><category name="services"/><category name="note"/><category name="calendarData"/></categoryList></action></batchSub>

This subscription is subject to the limitations of the presence policy discussed earlier. When the CategorySubscriptions property is set to 3000, the maximum number of contacts that Bob can add to his Contacts list is 600, because he has chosen to subscribe to five categories of state, contactCard, services, note and calendarData.

After the request is accepted by the server, the submitting client receives a SIP 200 OK response containing the requested result. Partial results might be returned. A portion of that response is shown in the following example.

SIP/2.0 200 OKms-user-logon-data: RemoteUserAuthentication-Info: TLS-DSK qop="auth", opaque="64DD2BFE", srand="CA11761B", snum="17", rspauth="7948287280886daef0c0ec84e59b83673291ac10", targetname="TK5W1402FE03.fabrikam.com", realm="SIP Communications Service", version=4Contact: <sip:000dco2o40pl1.fabrikam.com:5061;transport=tls;ms-fe=000DCO2O40FE13.fabrikam.com>


Content-Length: 64643From: "Ivan Komashinsky"<sip:[email protected]>;tag=3c9ce897ad;epid=16ce6a1da0To: <sip:[email protected]>;tag=46540080Call-ID: 8f71a150f220450f8f683b6ce3bb57a7CSeq: 1 SUBSCRIBEVia: SIP/2.0/TLS 192.168.1.39:49206;received=157.54.125.148;ms-received-port=12137;ms-received-cid=661DC500Expires: 23183Require: eventlistContent-Type: multipart/related; type="application/rlmi+xml";start=resourceList; boundary=cad79b9531f84c7188ba13cadcb25c46Event: presencesubscription-state: active;expires=23183ms-piggyback-cseq: 1Supported: ms-piggyback-first-notifyRecord-Route: <sip:tk5w1402cl.fabrikam.com:5061;transport=tls;ms-fe=TK5W1402FE03.fabrikam.com;lr;received=10.31.50.36;ms-received-cid=64D8BE00>Record-Route: <sip:sipalt.fabrikam.com:443;transport=tls;opaque=state:Ci.R661dc500;lr;ms-route-sig=fgPISBzC_7dUJmeYljjxHqKd0bLy9wO8YN5M7FTKJpMC39Tc8cR1VafQAA>

--cad79b9531f84c7188ba13cadcb25c46Content-Transfer-Encoding: binaryContent-ID: resourceListContent-Type: application/rlmi+xml

<list xmlns="urn:ietf:params:xml:ns:rlmi" uri="sip:[email protected]" version="0" fullState="false"/><resource uri="sip:[email protected]"><instance id="0" state="resubscribe" cid="[email protected]" poolFqdn="sip:[email protected];gruu;opaque=srvr:HomeServer:-GEAUnGh6lqC9C0_AgsCUQAA"/></resource><resource uri="sip:[email protected] "><instance id="0" state="resubscribe" cid="[email protected]" poolFqdn=" sip:[email protected];gruu;opaque=srvr:HomeServer:-GEAUnGh6lqC9C0_AgsCUQAA"/></resource>

--cad79b9531f84c7188ba13cadcb25c46Content-Transfer-Encoding: binaryContent-Type: application/msrtc-event-categories+xml

<categories xmlns="http://schemas.microsoft.com/2006/09/sip/categories" uri="sip:[email protected]"> <category name="calendarData"/> <category name="contactCard" instance="0" publishTime="2010-07-13T02:48:52.257"> <contactCard xmlns="http://schemas.microsoft.com/2006/09/sip/contactcard" > <identity > <name ><displayName >Anahita</displayName></name> <email >[email protected]</email> </identity>


</contactCard> </category> <category name="contactCard" instance="4" publishTime="2010-07-06T22:49:21.510"> <contactCard xmlns="http://schemas.microsoft.com/2006/09/sip/contactcard" isUCEnabled="false"> </contactCard> </category> <category name="note" instance="0" publishTime="2010-07-06T22:50:09.813"> <note xmlns="http://schemas.microsoft.com/2006/09/sip/note"> <body type="personal" uri="">Another day at work....</body> </note> </category> <category name="state" instance="1" publishTime="2011-05-09T02:47:35.263">

<state xsi:type="aggregateState" lastActive="2011-05-09T02:47:36" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/2006/09/sip/state">

<availability>15500</availability> <delimiter xmlns="http://schemas.microsoft.com/2006/09/sip/commontypes" /> <timeZoneBias>420</timeZoneBias> <timeZoneName>Pacific Daylight Time</timeZoneName> <timeZoneAbbreviation>Pacific Daylight Time</timeZoneAbbreviation> <device>deskphone</device> <end xmlns="http://schemas.microsoft.com/2006/09/sip/commontypes" /></state>

</category> <category name="services" instance="0" publishTime="2011-05-09T02:47:35.263">

<services xmlns="http://schemas.microsoft.com/2006/09/sip/service"> <service uri="sip:[email protected]"> <capabilities> <text render="false" capture="false" deviceAvailability="15500" /> <gifInk render="false" capture="false" deviceAvailability="15500" /> <isfInk render="false" capture="false" deviceAvailability="15500" /> <applicationSharing render="false" capture="false" deviceAvailability="15500" /> <voice render="true" capture="true" deviceAvailability="15500" /> <video render="false" capture="false" deviceAvailability="15500" /> <contentWhiteboard render="false" capture="false" deviceAvailability="15500" /> <contentPoll render="false" capture="false" deviceAvailability="15500" /> <contentPowerPoint render="false" capture="false" deviceAvailability="15500" /> <contentNativeFile render="false" capture="false" deviceAvailability="15500" /> </capabilities> </service></services>

</category>

The message body of the response consists of multiple parts, separated by a GUID value (that is, “--cad79b9531f84c7188ba13cadcb25c46” in this example). The first part consists of the list of the subscribed contacts. And the ensuing parts each contain the subscribed presence of a contact.


In addition, the Lync Server sends the results to all the signed-in clients of the local user using NOTIFY or BENOTIFY requests. In a persistent subscription, the server will continue to send NOTIFY or BENOTIFY whenever the subscribed-to publications are updated.

Receiving Roaming Data by Using Self-SubscriptionA presence application can use the subscription infrastructure to receive published presence data by other users, also known as remote users. The subscription involved is referred to as the remote subscription or, simply, subscription. The application can also use the subscription framework to receive self-consumed data that is stored on the Lync Server. The data include the local user’s list of contacts, the presence data already published by the local user (that is, self-presence), and the application settings configurable by the local user. This process is known as self-subscription.

As with a remote subscription, the self-subscription starts with a SERVICE request. The following example shows a SIP SERVICE request that started a self-subscription.

SUBSCRIBE sip:[email protected] SIP/2.0Via: SIP/2.0/TLS 192.168.0.40:54364Max-Forwards: 70From: <sip:[email protected]>;tag=f85eb73b02;epid=5fb4cad0caTo: <sip:[email protected]>Call-ID: 2e8e76009d544ebab9f571387851db1dCSeq: 1 SUBSCRIBEContact: <sip:[email protected];opaque=user:epid:-NkxRZvAY1GqwgtgoyCyOwAA;gruu>User-Agent: UCCAPI/4.0.7577.0 OC/4.0.7577.0 (Microsoft Lync 2010)Event: vnd-microsoft-roaming-selfAccept: application/vnd-microsoft-roaming-self+xmlSupported: com.microsoft.autoextendSupported: ms-benotifyProxy-Require: ms-benotifySupported: ms-piggyback-first-notifyProxy-Authorization: TLS-DSK qop="auth", realm="SIP Communications Service", opaque="279520A0", targetname="LYNC-SE.contoso.com", crand="778faba6", cnum="5", response="271a742d65e0c9664d65735e7ec19ec24523db7f"Content-Type: application/vnd-microsoft-roaming-self+xmlContent-Length: 268

<roamingList xmlns="http://schemas.microsoft.com/2006/09/sip/roaming-self"><roaming type="categories"/><roaming type="containers"/><roaming type="subscribers"/><roamingEx xmlns="http://schemas.microsoft.com/2007/09/sip/roaming-self-ex" type="delegates"/></roamingList>

For a self-subscription, the Event header has the value of “vnd-microsoft-roaming-self” and the Accept header value is “application/vnd-microsoft-roaming-self+xml”. The self-subscription is persistent because the Expires header is not present in the SIP message. The body of the SIP request message specifies the types of data to be received in the self-subscription. In Lync, as shown in this example, they include the presence categories published by the local user, the containers used by the local user for publications, and the remote users that are currently subscribing to the local user’s presence, and the users designated as the delegates of the local user. The results are returned to the requesting


client in a SIP 200 OK response. For the preceding example, a SIP response is shown in the following example.

Note. The response has been truncated for the sake of brevity. You can view a full response via tracing.

SIP/2.0 200 OKContact: <sip:LYNC-SE.contoso.com:5061;transport=tls>Authentication-Info: TLS-DSK qop="auth", opaque="279520A0", srand="0E94188B", snum="5", rspauth="c66167dfebef6878384e8b3d0ef898005848e848", targetname="LYNC-SE.contoso.com", realm="SIP Communications Service", version=4Content-Length: 30628From: "Bob"<sip:[email protected]>;tag=f85eb73b02;epid=5fb4cad0caTo: <sip:[email protected]>;tag=84670080Call-ID: 2e8e76009d544ebab9f571387851db1dCSeq: 1 SUBSCRIBEVia: SIP/2.0/TLS 192.168.0.40:54364;ms-received-port=54364;ms-received-cid=380900Expires: 26496Require: eventlistContent-Type: application/vnd-microsoft-roaming-self+xmlEvent: vnd-microsoft-roaming-selfsubscription-state: active;expires=26496ms-piggyback-cseq: 1Supported: ms-benotify, ms-piggyback-first-notify

<roamingData xmlns="http://schemas.microsoft.com/2006/09/sip/roaming-self" xmlns:cat="http://schemas.microsoft.com/2006/09/sip/categories" xmlns:con="http://schemas.microsoft.com/2006/09/sip/containers" xmlns:sub="http://schemas.microsoft.com/2006/09/sip/presence-subscribers" xmlns:del="http://schemas.microsoft.com/2007/09/sip/delegates"><categories xmlns="http://schemas.microsoft.com/2006/09/sip/categories" uri="sip:[email protected]"><category name="calendarData" instance="0" publishTime="2010-12-29T18:05:38.560" container="32000" version="2" expireType="static"><calendarData xmlns="http://schemas.microsoft.com/2006/09/sip/calendarData"></calendarData></category><category name="calendarData" instance="1521659821" publishTime="2011-05-06T07:00:08.207" container="32000" version="3" expireType="time" expires="45653"><calendarData xmlns="http://schemas.microsoft.com/2006/09/sip/calendarData"></calendarData></category><category name="calendarData" instance="0" publishTime="2010-12-29T18:05:38.560" container="400" version="1" expireType="static"><calendarData xmlns="http://schemas.microsoft.com/2006/09/sip/calendarData" mailboxID="[email protected]"><WorkingHours xmlns="http://schemas.microsoft.com/exchange/services/2006/types"><TimeZone><Bias>480</Bias><StandardTime><Bias>0</Bias><Time>02:00:00</Time><DayOrder>1</DayOrder><Month>11</Month><DayOfWeek>Sunday</DayOfWeek></StandardTime><DaylightTime><Bias>-60</Bias><Time>02:00:00</Time><DayOrder>2</DayOrder><Month>3</Month><DayOfWeek>Sunday</DayOfWeek></DaylightTime></TimeZone><WorkingPeriodArray><WorkingPeriod><DayOfWeek>Monday Tuesday Wednesday Thursday Friday</DayOfWeek><StartTimeInMinutes>480</StartTimeInMinutes><EndTimeInMinutes>1020</EndTimeInMinutes></WorkingPeriod></WorkingPeriodArray></WorkingHours></calendarData></category><category name="calendarData" instance="1521659821" publishTime="2011-05-06T07:00:08.207" container="400" version="3" expireType="time" expires="45653">


<calendarData xmlns="http://schemas.microsoft.com/2006/09/sip/calendarData" mailboxID="[email protected]"><freeBusy startTime="2011-05-05T07:00:00Z" granularity="PT15M" encodingVersion="1">AAAAAAAAAAAAAAAAAAAAAFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA</freeBusy></calendarData></category><category name="calendarData" instance="0" publishTime="2010-12-29T18:05:38.560" container="300" version="1" expireType="static"><calendarData xmlns="http://schemas.microsoft.com/2006/09/sip/calendarData" mailboxID="[email protected]">

<WorkingHours xmlns:auto-ns1="http://schemas.microsoft.com/2006/09/sip/calendarData" xmlns="http://schemas.microsoft.com/exchange/services/2006/types"><TimeZone><Bias>480</Bias><StandardTime><Bias>0</Bias><Time>02:00:00</Time><DayOrder>1</DayOrder><Month>11</Month><DayOfWeek>Sunday</DayOfWeek></StandardTime><DaylightTime><Bias>-60</Bias><Time>02:00:00</Time><DayOrder>2</DayOrder><Month>3</Month><DayOfWeek>Sunday</DayOfWeek></DaylightTime></TimeZone><WorkingPeriodArray><WorkingPeriod><DayOfWeek>Monday Tuesday Wednesday Thursday Friday</DayOfWeek><StartTimeInMinutes>480</StartTimeInMinutes><EndTimeInMinutes>1020</EndTimeInMinutes></WorkingPeriod></WorkingPeriodArray></WorkingHours>

</calendarData></category><category name="calendarData" instance="1521659821" publishTime="2011-05-06T07:00:08.207" container="300" version="3" expireType="time" expires="45653"><calendarData xmlns="http://schemas.microsoft.com/2006/09/sip/calendarData" mailboxID="[email protected]">

<freeBusy startTime="2011-05-05T07:00:00Z" granularity="PT15M" encodingVersion="1">AAAAAAAAAAAAAAAAAAAAAFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA</freeBusy>

</calendarData></category><category name="calendarData" instance="0" publishTime="2010-12-29T18:05:38.560" container="200" version="1" expireType="static"><calendarData xmlns="http://schemas.microsoft.com/2006/09/sip/calendarData" mailboxID="[email protected]">

The process continues until the user signs out or the subscription is terminated.

Receiving Lync Server Configuration Settings and Other System Data by Using In-band ProvisioningThe subscription mechanism is also used by the Lync Server to provision configuration data and policy settings. This process is known as in-band provisioning and involves the Lync Server client submitting a SUBSCRIBE request containing the provisioning group names and parsing the results returned in a SIP/2.0 200 OK response from the server. For details, see the “Client Provisioning” section in the “Instant Messaging” chapter of the Resource Kit available for download from the Microsoft Download Center at http://go.microsoft.com/fwlink/?LinkId=211003.

SummaryIn this chapter, you learned that Lync Server 2010 provides an enhanced presence service that relays presence information between two communication entities. The process involves


SIP-based messaging to enable the presence publication, subscription, and querying. This presence system is versatile and can handle any application-specific presence data. The versatility is supported by a flexible XML-based presence data model as represented by the enhanced presence category.

Additional ResourcesFor more information, see the following:

SIP: Session Initiation Protocol http://www.ietf.org/rfc/rfc3261.txt SDP: Session Description Protocol http://www.ietf.org/rfc/rfc4566.txt A Model for Presence and Instant Messaging http://tools.ietf.org/rfc/rfc2778.txt Session Initiation Protocol (SIP)-Specific Event Notification

http://tools.ietf.org/rfc/rfc3265.txt A Watcher Information Event Template-Package for the Session Initiation Protocol

(SIP) http://tools.ietf.org/rfc/rfc3857.txt Presence Information Data Format (PIDF) http://tools.ietf.org/rfc/rfc3863.txt Session Initiation Protocol (SIP) Extension for Event State Publication

http://tools.ietf.org/rfc/rfc3903.txt A Data Model for Presence http://tools.ietf.org/rfc/rfc4479.txt RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)

http://tools.ietf.org/rfc/rfc4480.txt Timed Presence Extensions to the Presence Information Data Format (PIDF) to

Indicate Status Information for Past and Future Time Intervals http://tools.ietf.org/rfc/rfc4481.txt

CIPID: Contact Information for the Presence Information Data Format http://tools.ietf.org/rfc/rfc4482.txt

Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF) http://tools.ietf.org/rfc/rfc5196.txt

[MS-PRES]: Presence Protocol Specification http://go.microsoft.com/fwlink/?LinkId=223573

Unified Communications Enhanced Presence Schemas for Microsoft Lync Server 2010 Documentation http://go.microsoft.com/fwlink/?LinkId=223572


chapter_06_enhanced_presence.doc

Documents

presence publications

presence entity

presence information

presence policy

custom presence

presence available

remote presence

enhanced presence operations