Chapter 06 Enhanced Presence

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
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
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
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
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,
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">
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
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.

<xs:complexType name="userState">
<xs:complexContent>
<xs:extension base="tns:stateType">
<xs:sequence>
<xs:sequence minOccurs="0" maxOccurs="1">
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element ref="ct:delimiter"/>
<xs:any namespace="##targetNamespace" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:element ref="ct:end"/>
</xs:sequence>
<xs:element ref="ct:extension" minOccurs="0" maxOccurs="1"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
This example shows that the category instance data type is hierarchical. The userState
category instance data type is derived from the abstract stateType category instance data
type. In addition to the elements and attributes defined in the base type, the XSD definition
in the previous example extends the schema definition of stateType with the <delimiter>,
<end>, and <xs:any> extensions, and the application extension (that is, <extension>)
to the userState category instance data.
To get the complete definition of the userState category instance data type, we must also
look at the base type definition, which is stateType as shown in the following example.

<xs:complexType name="stateType" abstract="true">
<xs:sequence>
<xs:element name="availability" type="xs:unsignedInt" minOccurs="0"/>
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
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
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
Page 12
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
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,
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
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
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"
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"
<state xsi:type="aggregateMachineState" endpointId="fb00e3d8-689a-53c5-8f6fb678a337e1a4"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
</state>
</category>
version="1" expireType="endpoint" endpointId="FB00E3D8-689A-53C58F6F-B678A337E1A4">
<state xmlns="http://schemas.microsoft.com/2006/09/sip/state"
manual="false" xsi:type="machineState">
<delimiter
xmlns="http://schemas.microsoft.com/2006/09/sip/commontypes"></delimiter>
<timeZoneBias>420</timeZoneBias>
<timeZoneName>Pacific Daylight Time</timeZoneName>
<end xmlns="http://schemas.microsoft.com/2006/09/sip/commontypes"></end>
</state>
</category>
version="1" expireType="endpoint" endpointId="458D2A22-9EC7-5D55B011-F8E31CFE459E">
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" manual="false"
xsi:type="machineState">
<delimiter
xmlns="http://schemas.microsoft.com/2006/09/sip/commontypes"></delimiter>
<device>deskphone</device>
Page 18
<end xmlns="http://schemas.microsoft.com/2006/09/sip/commontypes"></end>
</state>
</category>
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">
<custom LCID="1033">Some activity</custom>
</activity>
</state>
</category>
container="100"
<state xsi:type="aggregateState"
</state>
</category>
<category name="legacyInterop" instance="1" publishTime="2011-0426T17:37:15.397" container="100"
<legacyInterop availability="3500" />
</category>
container="200"
<state xsi:type="aggregateState"
<custom LCID="1033"
</activity>
</state>
</category>
<legacyInterop availability="3500" token="in-a-meeting" />
Page 19
</category>
container="400"
<state xsi:type="aggregateState" xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance"
<custom LCID="1033"
</activity><delimiter
xmlns="http://schemas.microsoft.com/2006/09/sip/commontypes" />
</state>
</category>
<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.
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).
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
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"
</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.
manual="true"
</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
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.
manual="true"
<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.
manual="false"
xsi:type="phoneState">
<activity token="on-the-phone"
Page 24
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.
manual="false"
xsi:type="phoneState">
<activity token="in-a-conference"
maxAvailability="8999">
</activity>
</state>
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">
<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
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

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

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.
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.
Page 28
Figure 3. Containers with published category data (resolved from highest container number to lowest)
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
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
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.
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>
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.
<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.
<publication categoryName="otherOptions" instance="2" container="1" version="7"
<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.
Via: SIP/2.0/TLS 192.168.0.40:65000
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
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.
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
Page 36
CSeq: 1 SERVICE
Contact: <sip:anahitab@contoso.com;opaque=user:epid:2OMA5poxVOPb7Z4ozfhpAAA;gruu>
opaque="D5ED691E", targetname="Pool01.contoso.com", crand="e37c5e78", cnum="60",
response="569395c91b5e3c001ec8065b94a56634ce3dd204"
Content-Type: application/msrtc-category-publish+xml
Content-Length: 326
<publications uri="sip:anahitab@contoso.com">
<publication categoryName="alerts" instance="0" container="1" version="8"
<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
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
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.
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
Call-ID: 6ce5f131bf60434c9cf15b14bf82f48e
CSeq: 1 SUBSCRIBE
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
opaque="279520A0", targetname="LYNC-SE.contoso.com", crand="fa6dbab7", cnum="14",
response="c51d1c2ae8c63ed10d6a87d68646ea1e62c10a92"
Content-Type: application/msrtc-adrl-categorylist+xml
Content-Length: 355
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-Type: application/msrtc-event-categories+xml
Page 39
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>
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
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
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>
Supported: msrtc-ucs
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>
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.
Via: SIP/2.0/TLS 192.168.0.40:54364
Max-Forwards: 70
From: <sip:bobkelly@contoso.com>;tag=44f75f3015;epid=5fb4cad0ca
Call-ID: 70cf12e227d7463db7b282ab6c4dff37
CSeq: 1 SUBSCRIBE
Event: vnd-microsoft-roaming-contacts
Accept: application/vnd-microsoft-roaming-contacts+xml
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.
Page 43
The server returns the results in a SIP 200 OK response, as shown in the following example.
SIP/2.0 200 OK
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
Expires: 27503
Content-Type: application/vnd-microsoft-roaming-contacts+xml
Event: vnd-microsoft-roaming-contacts
subscription-state: active;expires=27503
<contactList deltaNum="7" >
<group id="1" name="~" externalURI="" />
<group id="2" name="Pinned Contacts" externalURI="<groupExtension
groupType="pinnedGroup"><email/></groupExtension>" />
<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).
Via: SIP/2.0/TLS 192.168.0.155:51390
Max-Forwards: 70
From: <sip:bobkelly@contoso.com>;tag=81643067ba;epid=16ce6a1da0
Page 44
Call-ID: f0dc3382e27740a989d8145f2fc33583
CSeq: 1 SUBSCRIBE
Contact: <sip:bobkelly@contoso.com;opaque=user:epid:2OMA5poxVOPb7Z4ozfhpAAA;gruu>
Event: presence
Accept: application/msrtc-event-categories+xml, application/xpidf+xml,
text/xml+msrtc.pidf, application/pidf+xml, application/rlmi+xml, multipart/related
Require: adhoclist, categoryList
Supported: eventlist
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
Authentication-Info: TLS-DSK qop="auth", opaque="64DD2BFE", srand="CA11761B",
snum="17", rspauth="7948287280886daef0c0ec84e59b83673291ac10",
Page 45
targetname="TK5W1402FE03.fabrikam.com", realm="SIP Communications Service",

version=4
Contact: <sip:000dco2o40pl1.fabrikam.com:5061;transport=tls;msfe=000DCO2O40FE13.fabrikam.com>
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
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-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-Type: application/msrtc-event-categories+xml
uri="sip:anahitab@contoso.com">
<category name="calendarData"/>
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"
<device>deskphone</device>
</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>
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.
Via: SIP/2.0/TLS 192.168.0.40:54364
Max-Forwards: 70
From: <sip:bobkelly@contoso.com>;tag=f85eb73b02;epid=5fb4cad0ca
Call-ID: 2e8e76009d544ebab9f571387851db1d
CSeq: 1 SUBSCRIBE
Event: vnd-microsoft-roaming-self
Accept: application/vnd-microsoft-roaming-self+xml
opaque="279520A0", targetname="LYNC-SE.contoso.com", crand="778faba6", cnum="5",
response="271a742d65e0c9664d65735e7ec19ec24523db7f"
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-
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
Authentication-Info: TLS-DSK qop="auth", opaque="279520A0", srand="0E94188B",
snum="5", rspauth="c66167dfebef6878384e8b3d0ef898005848e848", targetname="LYNCSE.contoso.com", realm="SIP Communications Service", version=4
From: "Bob"<sip:bobkelly@contoso.com>;tag=f85eb73b02;epid=5fb4cad0ca
To: <sip:bobkelly@contoso.com>;tag=84670080
Call-ID: 2e8e76009d544ebab9f571387851db1d
CSeq: 1 SUBSCRIBE
Expires: 26496
Require: eventlist
Event: vnd-microsoft-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">
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>
<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
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>
mailboxID="bobkelly@contoso.com"><freeBusy startTime="2011-05-05T07:00:00Z"
granularity="PT15M"
encodingVersion="1">AAAAAAAAAAAAAAAAAAAAAFAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAA</freeBusy></calendarData>
</category>
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>
<freeBusy startTime="2011-05-05T07:00:00Z"
granularity="PT15M"
encodingVersion="1">AAAAAAAAAAAAAAAAAAAAAFAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAA</freeBusy>
</calendarData>
</category>
The process continues until the user signs out or the subscription is terminated.
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
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
A Data Model for Presence http://tools.ietf.org/rfc/rfc4479.txt
RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)
Timed Presence Extensions to the Presence Information Data Format (PIDF) to
Indicate Status Information for Past and Future Time Intervals
CIPID: Contact Information for the Presence Information Data Format
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
Page 51

Chapter 06 Enhanced Presence

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Chapter 06 Enhanced Presence

Transféré par

Droits d'auteur :

Formats disponibles

This document is provided as-is.

Information and views expressed in this document,

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Figure 1. Example of contacts presence shown with color coding

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Enhanced Presence Data Model

Enhanced Presence Category Instances

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Endpoint bounded. Publication expires when the publishing endpoint is no

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

<state > </state>

Enhanced Category Instance Data

Category instance data XML schemas

XSD namespace: http://schemas.microsoft.com/2006/09/sip/options/alerts

XSD namespace: http://schemas.microsoft.com/2006/09/sip/calendarData

XSD file name: calendarData.XSD, calendardatatypes.xsd

XSD namespace: http://schemas.microsoft.com/2006/09/sip/contactcard

XSD namespace: http://schemas.microsoft.com/2006/09/sip/device

XSD namespace: http://schemas.microsoft.com/2006/09/sip/note

XSD namespace: http://schemas.microsoft.com/2006/09/sip/mwi

XSD namespace: http://schemas.microsoft.com/2006/09/sip/options/otherOptions

XSD namespace: http://schemas.microsoft.com/2006/09/sip/routing

XSD namespace: http://schemas.microsoft.com/2006/09/sip/options/rccOptions

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Category instance data XML schemas

XSD namespace: http://schemas.microsoft.com/2006/09/sip/service

XSD namespace: http://schemas.microsoft.com/2006/09/sip/state

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

XSD namespace: http://schemas.microsoft.com/2006/09/sip/categories

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

<xs:element name="activity" type="tns:activityType"

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Availability number range

18000 and higher

Availability number range

Default activity string

18000 and higher

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Availability number range

Default activity string

Standard activity token

Standard activity string

Urgent interruptions only

Aggregated Category Instance Values and Multiple Points of Presence

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Public and Private Category Instances

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

rccOptions, mwi, userInformation, and userProperties categories. Lync also publishes

Categories for Application Data and Custom Presence

Enhanced Presence Operations

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Publishing Presences Using SIP SERVICE Requests

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Microsoft Lync Server 2010 Resource Kit Enhanced Presence

Figure 2. Availability options in Lync 2010

Understanding Lync Server Presence Aggregation