Вы находитесь на странице: 1из 51

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

Page 2

Contributors
Project 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

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 3

Table of Contents
Contributors............................................................................................................... 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

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 4

Introduction
Presence is an important element in facilitating efficient real-time communications. Presence
refers to information used to describe an entitys 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

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 5

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 Model


The 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 users 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 Instances


A 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

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 6

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 users 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 users status (for example, presence) a
category instance is published to the server. The server increments the clientprovided 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,

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 7

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

o
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).
User bounded. Publication continues to persist as long as one of the endpoints
of the publishing user is registered.
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.
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">

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 8

<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 Data


While 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

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 9

Category name

Category instance data XML schemas


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


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.
<!-- userState is a concrete type derived from stateType -->
<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.
<!-- stateType is an abstract type used as a base type for specific state -->
<xs:complexType name="stateType" abstract="true">
<xs:sequence>
<xs:element name="availability" type="xs:unsignedInt" minOccurs="0"/>

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 10

<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

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 11

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

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 12

Availability number range

Default activity string

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 Presence


Lync 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 users 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

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 13

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 serverhosted 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 Instances


Public 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,

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 14

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 Presence


Based 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 Operations


The 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.

Publication
In 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

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 15

client request to return the requested publication, provided that the requesting user is a
member of the container.

Publishing Presences Using SIP SERVICE Requests


Publishing 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 doesnt
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 servermaintained 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:bobkelly@contoso.com SIP/2.0
FROM: <sip:bobkelly@contoso.com>;epid=1E5C4E59CA;tag=0153ea48
TO: <sip:bobkelly@contoso.com>;epid=1E5C4E59CA
CSEQ: 5 SERVICE
CALL-ID: 138afca10c4446f5a063925138cd4f26
MAX-FORWARDS: 70
VIA: SIP/2.0/TLS 192.168.0.155:53594;branch=z9hG4bK96be304f
AUTHORIZATION: NTLM realm="SIP Communications Service",targetname="tuk-ocdr101.contoso.com",response="0100000000000000dec685fc58268760",crand="70bd108c",cn
um="6",opaque="17FC1F24",qop="auth"
CONTACT:
<sip:bobkelly@contoso.com;opaque=user:epid:sCPKlagTB1apRfve3oHuPQAA;gruu>;text;au
dio;video;image
CONTENT-LENGTH: 609
SUPPORTED: gruu-10
USER-AGENT: RTCC/4.0.0.0 PresPub
CONTENT-TYPE: application/msrtc-category-publish+xml

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 16

<publish xmlns="http://schemas.microsoft.com/2006/09/sip/rich-presence">
<publications uri="sip:bobkelly@contoso.com">
<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 OK
FROM: "Bob"<sip:bobkelly@contoso.com>;epid=1E5C4E59CA;tag=0153ea48
TO:
<sip:bobkelly@contoso.com>;epid=1E5C4E59CA;tag=A159FEC7C342936628C5CEDC7D11E
057
CSEQ: 5 SERVICE
CALL-ID: 138afca10c4446f5a063925138cd4f26
VIA: SIP/2.0/TLS
192.168.0.155:53594;branch=z9hG4bK96be304f;received=76.121.173.74;ms-receivedport=53594;ms-received-cid=22E61D00
CONTENT-LENGTH: 5816
CONTENT-TYPE: application/vnd-microsoft-roaming-self+xml
AUTHENTICATION-INFO: NTLM rspauth="01000000000000002C72615B58268760",
srand="CFCC1A9B", snum="6", opaque="17FC1F24", qop="auth", targetname="tuk-ocdr101.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:bobkelly@contoso.com">
<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/XMLSchemainstance"
xmlns="http://schemas.microsoft.com/2006/09/sip/state">
<availability>3500</availability>
<activity token="in-a-meeting">

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 17

<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-0426T16:19:31.397" container="2"
version="35" expireType="user">
<state xsi:type="aggregateMachineState" endpointId="fb00e3d8-689a-53c5-8f6fb678a337e1a4"
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-0426T16:19:31.397" container="2"
version="1" expireType="endpoint" endpointId="FB00E3D8-689A-53C58F6F-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-0425T16:34:31.607" container="2"
version="1" expireType="endpoint" endpointId="458D2A22-9EC7-5D55B011-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>

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 18

<end xmlns="http://schemas.microsoft.com/2006/09/sip/commontypes"></end>
</state>
</category>
<category name="state" instance="536870912" publishTime="2011-0426T17: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-0426T17: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-0426T17:37:15.397" container="200"
version="23" expireType="user">
<legacyInterop availability="3500" token="in-a-meeting" />

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 19

</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/XMLSchemainstance"
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-0426T17: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.

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 20

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 Aggregation


Lync 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).

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 21

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 endpointdependent. 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

Busy

6500

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

User is in the available state.


urgent-interruptions-only
(in container 3)

off-work

User is in the busy state.

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 userStates availability is not reset by the user before then. The

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 22

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 users 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 users 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 users 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

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 23

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 users 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 elses 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"

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 24

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 users 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>

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 25

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 users activity status.
Lync publishes a calendarState category instance using the users 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 users 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, bobkelly@contoso.com) indicates a meeting in progress.
<state xmlns="http://schemas.microsoft.com/2006/09/sip/state" manual="false"
uri="bobkelly@contoso.com" 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 Ill 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, Bobs
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 Bobs possible user states can be Busy to IdleBusy, which both fall into
the range of minAvailability to maxAvailability.

Controlling Access to Presence Publications with Containers


A 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:bobkelly@contoso.com) for individual users or presentities, one or more fully qualified

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 26

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 nonenterprise 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

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

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 users Contacts list; the users 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

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

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 900011999 (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.

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 27

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:bobkelly@contoso.com), 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 users 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 owners presence information, except for the owners
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.

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 28

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

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 29

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

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 30

Enforcing Interoperability with Lync by Using Publication Grammars


In 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 grammarfree publications by a presence application.

Enabling Enhanced Privacy Mode in Presence Publications


Lync 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 users 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 users 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 decidecurrently everyone can see my presence
but this could change in the future

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 31

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.

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 32

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
users 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, lets look at an example that follows a user (for
example, bobkelly@contoso.com) 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>

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 33

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:bobkelly@contoso.com">
<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:bobkelly@contoso.com">
<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/msrtcsetcontainermembers+xml. Following is an example of this SIP message.
SERVICE sip:bobkelly@contoso.com SIP/2.0
Via: SIP/2.0/TLS 192.168.0.40:65000

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 34

Max-Forwards: 70
From: <sip:bobkelly@contoso.com>;tag=070d2df50e;epid=5fb4cad0ca
To: <sip:bobkelly@contoso.com>
Call-ID: f065c07412b84c9bab011f1d1a9aeb0e
CSeq: 1 SERVICE
Contact: <sip:bobkelly@contoso.com;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+xml
Content-Length: 487
<setContainerMembers xmlns="http://schemas.microsoft.com/2006/09/sip/containermanagement">
<container id="100" version="3">
<member action="remove" type="federated"/>
</container>
<container id="200" version="4">
<member action="add" type="user" value="anahitab@contoso.com"/>
<member action="add" type="user" value="cyncarey@contoso.com"/>
<member action="add" type="user" value="helpdesk@contoso.com"/>
<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
Presence State
Display Name
Email Address
Title *
Work Phone *
Mobile Phone *
Home Phone *
Other Phone
Company *
Office *

Blocked

External

Colleagues

Workgroup

Friends and Family

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 35

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 Data


In addition to making a local users 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 users Self container (that is, container 1) as shown in the following example.
SERVICE sip:bobkelly@contoso.com SIP/2.0
Via: SIP/2.0/TLS 192.168.0.155:62154
Max-Forwards: 70
From: <sip:anahitab@contoso.com>;tag=62aec7b75a;epid=16ce6a1da0
To: <sip:anahitab@contoso.com>
Call-ID: 89e08728a9b842b9a4a469c044d7e733

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 36

CSeq: 1 SERVICE
Contact: <sip:anahitab@contoso.com;opaque=user:epid:2OMA5poxVOPb7Z4ozfhpAAA;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+xml
Content-Length: 326
<publish xmlns="http://schemas.microsoft.com/2006/09/sip/rich-presence">
<publications uri="sip:anahitab@contoso.com">
<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 OK
ms-user-logon-data: RemoteUser
Authentication-Info: TLS-DSK qop="auth", opaque="D5ED691E", srand="A85DA2CE",
snum="60", rspauth="b25dc9096a20a93ecb712606cc42d980bea07665",
targetname="Pool01.contoso.com", realm="SIP Communications Service", version=4
Content-Length: 497
From: "Anahita"<sip:anahitab@contoso.com>;tag=62aec7b75a;epid=16ce6a1da0
To: <sip:anahitab@contoso.com>;tag=9B07C1614112F9B18B8C6D8A525986E4
Call-ID: 89e08728a9b842b9a4a469c044d7e733
CSeq: 1 SERVICE
Via: SIP/2.0/TLS 192.168.0.155:62154;received=157.54.125.148;ms-receivedport=62154;ms-received-cid=23705D00
Content-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:
anahitab@contoso.com">
<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.

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 37

Subscription
Presence 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 Requests


Operationally, 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
(bobkelly@contoso.com) in a query or as part of polling subscription to receive to the
noteHistory of a remote user (anahitab@contoso.com).
SUBSCRIBE sip:bobkelly@contoso.com SIP/2.0
Via: SIP/2.0/TLS 192.168.0.40:54364
Max-Forwards: 70
From: <sip:bobkelly@contoso.com>;tag=8654485aef;epid=5fb4cad0ca
To: <sip:bobkelly@contoso.com>
Call-ID: 6ce5f131bf60434c9cf15b14bf82f48e
CSeq: 1 SUBSCRIBE
Contact: <sip:bobkelly@contoso.com;opaque=user:epid:NkxRZvAY1GqwgtgoyCyOwAA;gruu>
User-Agent: UCCAPI/4.0.7577.0 OC/4.0.7577.0 (Microsoft Lync 2010)
Event: presence
Accept: application/msrtc-event-categories+xml, application/xpidf+xml,
text/xml+msrtc.pidf, application/pidf+xml, application/rlmi+xml, multipart/related
Supported: com.microsoft.autoextend
Supported: ms-benotify
Proxy-Require: ms-benotify
Supported: ms-piggyback-first-notify
Expires: 0
Require: adhoclist, categoryList
Supported: eventlist
Proxy-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+xml
Content-Length: 355

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 38

<batchSub xmlns="http://schemas.microsoft.com/2006/01/sip/batch-subscribe"
uri="sip:bobkelly@contoso.com" name="">
<action name="subscribe" id="103843728">
<adhocList>
<resource uri="sip:anahitab@contoso.com"/>
</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 OK
Contact: <sip:LYNC-SE.contoso.com:5061;transport=tls>
Authentication-Info: TLS-DSK qop="auth", opaque="279520A0", srand="5B6EFD4F",
snum="15", rspauth="1891e3d14c9822c7dc1589cf3479fc9febd67bed", targetname="LYNCSE.contoso.com", realm="SIP Communications Service", version=4
Content-Length: 769
From: "Bob"<sip:bobkelly@contoso.com>;tag=8654485aef;epid=5fb4cad0ca
To: <sip:bobkelly@contoso.com>;tag=BE180080
Call-ID: 6ce5f131bf60434c9cf15b14bf82f48e
CSeq: 1 SUBSCRIBE
Via: SIP/2.0/TLS 192.168.0.40:54364;ms-received-port=54364;ms-received-cid=380900
Expires: 0
Require: eventlist
Content-Type: multipart/related; type="application/rlmi+xml";start=resourceList;
boundary=bfd74156b52c441c98b8e3d27b840bbe
Event: presence
subscription-state: terminated;expires=0
ms-piggyback-cseq: 1
Supported: ms-benotify, ms-piggyback-first-notify

--bfd74156b52c441c98b8e3d27b840bbe
Content-Transfer-Encoding: binary
Content-ID: resourceList
Content-Type: application/rlmi+xml
<list xmlns="urn:ietf:params:xml:ns:rlmi" uri="sip:bobkelly@contoso.com" version="0"
fullState="false"/>
--bfd74156b52c441c98b8e3d27b840bbe
Content-Transfer-Encoding: binary
Content-Type: application/msrtc-event-categories+xml

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 39

<categories xmlns="http://schemas.microsoft.com/2006/09/sip/categories"
uri="sip:anahitab@contoso.com">
<category name="noteHistory" instance="1864567" publishTime="2010-1229T20: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>

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 40

The payload of this SIP response has two related parts. The first part lists the SIP URI of the
subscribing user (that is, sip:bobkelly@contoso.com in this example). The second part
contains the subscribed category data published by the specified remote user (that is,
sip:anahitab@contoso.com 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 Subscription
For 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

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 41

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 servers 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 Presence


A 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 contacts
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.0
Via: SIP/2.0/TLS 10.80.24.214:62084
Max-Forwards: 70
From: <sip:bobkelly@contoso.com>;tag=0c40725f3c;epid=16ce6a1da0
To: <sip:bobkelly@contoso.com>;tag=1DA1AD6C
Call-ID: 47b40f5af3d143279a714400c5e34808
CSeq: 4 SERVICE
Contact: <sip:bobkelly@contoso.com;opaque=user:epid:2OMA5poxVOPb7Z4ozfhpAAA;gruu>
User-Agent: UCCAPI/4.0.7577.0 OC/4.0.7577.0 (Microsoft Lync 2010)
Supported: msrtc-ucs
Proxy-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+xml
Content-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:anahitab@contoso.com</m:URI>
<contactExtension><contactSettings source="outlook" contactId="7bc6ef25-b06b-43059fc6-ebb1a780787b"></contactSettings>

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 42

</contactExtension>
<m:externalURI></m:externalURI>
<m:deltaNum>137</m:deltaNum>
</m:setContact>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
In this example, the SERVICE request is made to the server (that is, sip:LYNCSE.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:bobkelly@contoso.com SIP/2.0
Via: SIP/2.0/TLS 192.168.0.40:54364
Max-Forwards: 70
From: <sip:bobkelly@contoso.com>;tag=44f75f3015;epid=5fb4cad0ca
To: <sip:bobkelly@contoso.com>
Call-ID: 70cf12e227d7463db7b282ab6c4dff37
CSeq: 1 SUBSCRIBE
Contact: <sip:bobkelly@contoso.com;opaque=user:epid:NkxRZvAY1GqwgtgoyCyOwAA;gruu>
User-Agent: UCCAPI/4.0.7577.0 OC/4.0.7577.0 (Microsoft Lync 2010)
Event: vnd-microsoft-roaming-contacts
Accept: application/vnd-microsoft-roaming-contacts+xml
Supported: com.microsoft.autoextend
Supported: ms-benotify
Proxy-Require: ms-benotify
Supported: ms-piggyback-first-notify
Proxy-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.

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 43

The server returns the results in a SIP 200 OK response, as shown in the following example.
SIP/2.0 200 OK
Contact: <sip:LYNC-SE.contoso.com:5061;transport=tls>
Authentication-Info: TLS-DSK qop="auth", opaque="279520A0", srand="B0FB0C3F",
snum="3", rspauth="b8bb693aec8cf66fbdb40f3749257bad34bcf91c", targetname="LYNCSE.contoso.com", realm="SIP Communications Service", version=4
Content-Length: 585
From: "Bob"<sip:bobkelly@contoso.com>;tag=44f75f3015;epid=5fb4cad0ca
To: <sip:bobkelly@contoso.com>;tag=01FD4572
Call-ID: 70cf12e227d7463db7b282ab6c4dff37
CSeq: 1 SUBSCRIBE
Via: SIP/2.0/TLS 192.168.0.40:54364;ms-received-port=54364;ms-received-cid=380900
Expires: 27503
Content-Type: application/vnd-microsoft-roaming-contacts+xml
Event: vnd-microsoft-roaming-contacts
subscription-state: active;expires=27503
ms-piggyback-cseq: 1
Supported: ms-benotify, ms-piggyback-first-notify
<contactList deltaNum="7" >
<group id="1" name="~" externalURI="" />
<group id="2" name="Pinned Contacts" externalURI="&lt;groupExtension
groupType=&quot;pinnedGroup&quot;&gt;&lt;email/&gt;&lt;/groupExtension&gt;" />
<contact uri="anahitab@contoso.com" name="" groups="1" subscribed="true"
externalURI="" />
<contact uri="cyncarey@contoso.com" name="" groups="1" subscribed="true"
externalURI="" >
<contactExtension><contactSettings source="outlook" contactId="4ae7fb20-11b7-4acd9932-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 Subscription


After 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,
bobkelly@contoso.com in this example) to receive new or updated presence publications
(that is, calendarData, contactCard, note, services, and state) by the remote users
(that is, anahitab@contoso.com and cyncarey@contoso.com in this example).
SUBSCRIBE sip:bobkelly@contoso.com SIP/2.0
Via: SIP/2.0/TLS 192.168.0.155:51390
Max-Forwards: 70
From: <sip:bobkelly@contoso.com>;tag=81643067ba;epid=16ce6a1da0

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 44

To: <sip:bobkelly@contoso.com>
Call-ID: f0dc3382e27740a989d8145f2fc33583
CSeq: 1 SUBSCRIBE
Contact: <sip:bobkelly@contoso.com;opaque=user:epid:2OMA5poxVOPb7Z4ozfhpAAA;gruu>
User-Agent: UCCAPI/4.0.7577.0 OC/4.0.7577.0 (Microsoft Lync 2010)
Event: presence
Accept: application/msrtc-event-categories+xml, application/xpidf+xml,
text/xml+msrtc.pidf, application/pidf+xml, application/rlmi+xml, multipart/related
Supported: com.microsoft.autoextend
Supported: ms-benotify
Proxy-Require: ms-benotify
Supported: ms-piggyback-first-notify
Require: adhoclist, categoryList
Supported: eventlist
Proxy-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+xml
Content-Length: 1476
<batchSub xmlns="http://schemas.microsoft.com/2006/01/sip/batch-subscribe"
uri="sip:bobkelly@contoso.com" name="">
<action name="subscribe" id="181311632">
<adhocList>
<resource uri="sip:anahitab@contoso.com "/>
<resource uri="sip:cyncarey@contoso.com "/>
</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 OK
ms-user-logon-data: RemoteUser
Authentication-Info: TLS-DSK qop="auth", opaque="64DD2BFE", srand="CA11761B",
snum="17", rspauth="7948287280886daef0c0ec84e59b83673291ac10",

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 45

targetname="TK5W1402FE03.fabrikam.com", realm="SIP Communications Service",


version=4
Contact: <sip:000dco2o40pl1.fabrikam.com:5061;transport=tls;msfe=000DCO2O40FE13.fabrikam.com>
Content-Length: 64643
From: "Ivan
Komashinsky"<sip:ivankom@fabrikam.com>;tag=3c9ce897ad;epid=16ce6a1da0
To: <sip:ivankom@fabrikam.com>;tag=46540080
Call-ID: 8f71a150f220450f8f683b6ce3bb57a7
CSeq: 1 SUBSCRIBE
Via: SIP/2.0/TLS 192.168.1.39:49206;received=157.54.125.148;ms-receivedport=12137;ms-received-cid=661DC500
Expires: 23183
Require: eventlist
Content-Type: multipart/related; type="application/rlmi+xml";start=resourceList;
boundary=cad79b9531f84c7188ba13cadcb25c46
Event: presence
subscription-state: active;expires=23183
ms-piggyback-cseq: 1
Supported: ms-piggyback-first-notify
Record-Route: <sip:tk5w1402cl.fabrikam.com:5061;transport=tls;msfe=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-routesig=fgPISBzC_7dUJmeYljjxHqKd0bLy9wO8YN5M7FTKJpMC39Tc8cR1VafQAA>

--cad79b9531f84c7188ba13cadcb25c46
Content-Transfer-Encoding: binary
Content-ID: resourceList
Content-Type: application/rlmi+xml
<list xmlns="urn:ietf:params:xml:ns:rlmi" uri="sip:bobkelly@contoso.com" version="0"
fullState="false"/>
<resource uri="sip:anahitab@contoso.com">
<instance id="0" state="resubscribe" cid="anahitab@contoso.com"
poolFqdn="sip:pool01.contoso.com@contoso.com;gruu;opaque=srvr:HomeServer:GEAUnGh6lqC9C0_AgsCUQAA"/>
</resource>
<resource uri="sip:cyncarey@contoso.com ">
<instance id="0" state="resubscribe" cid="cyncarey@contoso.com" poolFqdn="
sip:pool01.contoso.com@contoso.com;gruu;opaque=srvr:HomeServer:GEAUnGh6lqC9C0_AgsCUQAA"/>
</resource>
--cad79b9531f84c7188ba13cadcb25c46
Content-Transfer-Encoding: binary
Content-Type: application/msrtc-event-categories+xml
<categories xmlns="http://schemas.microsoft.com/2006/09/sip/categories"
uri="sip:anahitab@contoso.com">
<category name="calendarData"/>

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 46

<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 >Anahitab@contoso.com</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:mkaur@fabrikam.com">
<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>

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 47

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-Subscription


A 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 users 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:bobkelly@contoso.com SIP/2.0
Via: SIP/2.0/TLS 192.168.0.40:54364
Max-Forwards: 70
From: <sip:bobkelly@contoso.com>;tag=f85eb73b02;epid=5fb4cad0ca
To: <sip:bobkelly@contoso.com>
Call-ID: 2e8e76009d544ebab9f571387851db1d
CSeq: 1 SUBSCRIBE
Contact: <sip:bobkelly@contoso.com;opaque=user:epid:NkxRZvAY1GqwgtgoyCyOwAA;gruu>
User-Agent: UCCAPI/4.0.7577.0 OC/4.0.7577.0 (Microsoft Lync 2010)
Event: vnd-microsoft-roaming-self
Accept: application/vnd-microsoft-roaming-self+xml
Supported: com.microsoft.autoextend
Supported: ms-benotify
Proxy-Require: ms-benotify
Supported: ms-piggyback-first-notify
Proxy-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+xml
Content-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-

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 48

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 selfsubscription. 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 users 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 OK
Contact: <sip:LYNC-SE.contoso.com:5061;transport=tls>
Authentication-Info: TLS-DSK qop="auth", opaque="279520A0", srand="0E94188B",
snum="5", rspauth="c66167dfebef6878384e8b3d0ef898005848e848", targetname="LYNCSE.contoso.com", realm="SIP Communications Service", version=4
Content-Length: 30628
From: "Bob"<sip:bobkelly@contoso.com>;tag=f85eb73b02;epid=5fb4cad0ca
To: <sip:bobkelly@contoso.com>;tag=84670080
Call-ID: 2e8e76009d544ebab9f571387851db1d
CSeq: 1 SUBSCRIBE
Via: SIP/2.0/TLS 192.168.0.40:54364;ms-received-port=54364;ms-received-cid=380900
Expires: 26496
Require: eventlist
Content-Type: application/vnd-microsoft-roaming-self+xml
Event: vnd-microsoft-roaming-self
subscription-state: active;expires=26496
ms-piggyback-cseq: 1
Supported: 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:bobkelly@contoso.com">
<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-0506T07: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="bobkelly@contoso.com"><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</Day
Order><Month>11</Month><DayOfWeek>Sunday</DayOfWeek></StandardTime><Dayli

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 49

ghtTime><Bias>60</Bias><Time>02:00:00</Time><DayOrder>2</DayOrder><Month>3</Month><DayO
fWeek>Sunday</DayOfWeek></DaylightTime></TimeZone><WorkingPeriodArray><Worki
ngPeriod><DayOfWeek>Monday Tuesday Wednesday Thursday
Friday</DayOfWeek><StartTimeInMinutes>480</StartTimeInMinutes><EndTimeInMinutes
>1020</EndTimeInMinutes></WorkingPeriod></WorkingPeriodArray></WorkingHours></c
alendarData>
</category>
<category name="calendarData" instance="1521659821" publishTime="2011-0506T07:00:08.207" container="400" version="3" expireType="time" expires="45653">
<calendarData xmlns="http://schemas.microsoft.com/2006/09/sip/calendarData"
mailboxID="bobkelly@contoso.com"><freeBusy startTime="2011-05-05T07:00:00Z"
granularity="PT15M"
encodingVersion="1">AAAAAAAAAAAAAAAAAAAAAFAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAA</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="bobkelly@contoso.com">
<WorkingHours xmlns:autons1="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</Day
Order><Month>11</Month><DayOfWeek>Sunday</DayOfWeek></StandardTime><Dayli
ghtTime><Bias>60</Bias><Time>02:00:00</Time><DayOrder>2</DayOrder><Month>3</Month><DayO
fWeek>Sunday</DayOfWeek></DaylightTime></TimeZone><WorkingPeriodArray><Worki
ngPeriod><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-0506T07:00:08.207" container="300" version="3" expireType="time" expires="45653">
<calendarData xmlns="http://schemas.microsoft.com/2006/09/sip/calendarData"
mailboxID="bobkelly@contoso.com">
<freeBusy startTime="2011-05-05T07:00:00Z"
granularity="PT15M"
encodingVersion="1">AAAAAAAAAAAAAAAAAAAAAFAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAA</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="bobkelly@contoso.com">
The process continues until the user signs out or the subscription is terminated.

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 50

Receiving Lync Server Configuration Settings and Other System Data by Using
In-band Provisioning
The 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.

Summary
In 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 Resources
For 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

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Page 51