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.
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.
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
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
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>
Category name
Alerts
calendarData
Device
Note
Mwi
otherOptions
Routing
rccOptions
Page 9
Category name
Services
State
userInformation
userProperties
For details about presence data schemas defined in Lync Server, see Unified
Communications Enhanced Presence Schemas for Microsoft Lync Server 2010
Documentation on the MSDN Library website at http://go.microsoft.com/fwlink/?
LinkId=223572.
As an example, let us look at the user state category instance XML schema. The XSD
definition for this particular presence state is shown in the following example.
<!-- userState is a concrete type derived from stateType -->
<xs:complexType name="userState">
<xs:complexContent>
<xs:extension base="tns:stateType">
<xs:sequence>
<xs:sequence minOccurs="0" maxOccurs="1">
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element ref="ct:delimiter"/>
<xs:any namespace="##targetNamespace" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:element ref="ct:end"/>
</xs:sequence>
<xs:element ref="ct:extension" minOccurs="0" maxOccurs="1"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
This example shows that the category instance data type is hierarchical. The userState
category instance data type is derived from the abstract stateType category instance data
type. In addition to the elements and attributes defined in the base type, the XSD definition
in the previous example extends the schema definition of stateType with the <delimiter>,
<end>, and <xs:any> extensions, and the application extension (that is, <extension>)
to the userState category instance data.
To get the complete definition of the userState category instance data type, we must also
look at the base type definition, which is stateType as shown in the following example.
<!-- stateType is an abstract type used as a base type for specific state -->
<xs:complexType name="stateType" abstract="true">
<xs:sequence>
<xs:element name="availability" type="xs:unsignedInt" minOccurs="0"/>
Page 10
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 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
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
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
Offline
Page 12
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
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
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>
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.
Page 14
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.
Page 16
<publish xmlns="http://schemas.microsoft.com/2006/09/sip/rich-presence">
<publications uri="sip:bobkelly@contoso.com">
<publication categoryName="state" instance="536870912" container="2" version="3"
expireType="user">
<state xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xsi:type="userState"
xmlns="http://schemas.microsoft.com/2006/09/sip/state">
<availability>3500</availability>
<activity token="in-a-meeting">
<custom LCID="1033">Some activity</custom>
</activity>
</state>
</publication>
</publications>
</publish>
The following is the server response of SIP 200 OK to the SERVICE request in the previous
example, which can be identified by the corresponding CSEQ and CALL-ID headers. The
response includes the affected the category instances as a result of the publication request.
SIP/2.0 200 OK
FROM: "Bob"<sip:bobkelly@contoso.com>;epid=1E5C4E59CA;tag=0153ea48
TO:
<sip:bobkelly@contoso.com>;epid=1E5C4E59CA;tag=A159FEC7C342936628C5CEDC7D11E
057
CSEQ: 5 SERVICE
CALL-ID: 138afca10c4446f5a063925138cd4f26
VIA: SIP/2.0/TLS
192.168.0.155:53594;branch=z9hG4bK96be304f;received=76.121.173.74;ms-receivedport=53594;ms-received-cid=22E61D00
CONTENT-LENGTH: 5816
CONTENT-TYPE: application/vnd-microsoft-roaming-self+xml
AUTHENTICATION-INFO: NTLM rspauth="01000000000000002C72615B58268760",
srand="CFCC1A9B", snum="6", opaque="17FC1F24", qop="auth", targetname="tuk-ocdr101.contoso.com", realm="SIP Communications Service"
ms-user-logon-data: RemoteUser
<roamingData xmlns="http://schemas.microsoft.com/2006/09/sip/roaming-self"
xmlns:cat="http://schemas.microsoft.com/2006/09/sip/categories">
<categories xmlns="http://schemas.microsoft.com/2006/09/sip/categories"
uri="sip:bobkelly@contoso.com">
<category name="state" instance="1" publishTime="2011-04-26T17:37:15.397"
container="2"
version="23" expireType="user">
<state xsi:type="aggregateState" xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance"
xmlns="http://schemas.microsoft.com/2006/09/sip/state">
<availability>3500</availability>
<activity token="in-a-meeting">
Page 17
<custom LCID="1033"
xmlns="http://schemas.microsoft.com/2006/09/sip/state">Some activity</custom>
</activity>
<delimiter xmlns="http://schemas.microsoft.com/2006/09/sip/commontypes" />
<timeZoneBias>420</timeZoneBias><timeZoneName>Pacific Daylight
Time</timeZoneName>
<timeZoneAbbreviation>Pacific Daylight Time</timeZoneAbbreviation>
<device>computer</device>
<end xmlns="http://schemas.microsoft.com/2006/09/sip/commontypes" />
</state>
</category>
<category name="state" instance="268435456" publishTime="2011-0426T16:19:31.397" container="2"
version="35" expireType="user">
<state xsi:type="aggregateMachineState" endpointId="fb00e3d8-689a-53c5-8f6fb678a337e1a4"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://schemas.microsoft.com/2006/09/sip/state">
<availability>3500</availability>
</state>
</category>
<category name="state" instance="876227841" publishTime="2011-0426T16:19:31.397" container="2"
version="1" expireType="endpoint" endpointId="FB00E3D8-689A-53C58F6F-B678A337E1A4">
<state xmlns="http://schemas.microsoft.com/2006/09/sip/state"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
manual="false" xsi:type="machineState">
<availability>3500</availability>
<delimiter
xmlns="http://schemas.microsoft.com/2006/09/sip/commontypes"></delimiter>
<timeZoneBias>420</timeZoneBias>
<timeZoneName>Pacific Daylight Time</timeZoneName>
<timeZoneAbbreviation>Pacific Daylight Time</timeZoneAbbreviation>
<device>computer</device>
<end xmlns="http://schemas.microsoft.com/2006/09/sip/commontypes"></end>
</state>
</category>
<category name="state" instance="1002993682" publishTime="2011-0425T16:34:31.607" container="2"
version="1" expireType="endpoint" endpointId="458D2A22-9EC7-5D55B011-F8E31CFE459E">
<state xmlns="http://schemas.microsoft.com/2006/09/sip/state"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" manual="false"
xsi:type="machineState">
<availability>15500</availability>
<delimiter
xmlns="http://schemas.microsoft.com/2006/09/sip/commontypes"></delimiter>
<timeZoneBias>420</timeZoneBias>
<timeZoneName>Pacific Daylight Time</timeZoneName>
<timeZoneAbbreviation>Pacific Daylight Time</timeZoneAbbreviation>
<device>deskphone</device>
Page 18
<end xmlns="http://schemas.microsoft.com/2006/09/sip/commontypes"></end>
</state>
</category>
<category name="state" instance="536870912" publishTime="2011-0426T17:37:15.397" container="2"
version="4" expireType="static">
<state xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://schemas.microsoft.com/2006/09/sip/state"
xsi:type="userState">
<activity token="in-a-meeting">
<custom LCID="1033">Some activity</custom>
</activity>
</state>
</category>
<category name="state" instance="1" publishTime="2011-04-26T17:37:15.397"
container="100"
version="23" expireType="user">
<state xsi:type="aggregateState"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://schemas.microsoft.com/2006/09/sip/state">
<availability>3500</availability>
</state>
</category>
<category name="legacyInterop" instance="1" publishTime="2011-0426T17:37:15.397" container="100"
version="23" expireType="user">
<legacyInterop availability="3500" />
</category>
<category name="state" instance="1" publishTime="2011-04-26T17:37:15.397"
container="200"
version="23" expireType="user">
<state xsi:type="aggregateState"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://schemas.microsoft.com/2006/09/sip/state">
<availability>3500</availability>
<activity token="in-a-meeting">
<custom LCID="1033"
xmlns="http://schemas.microsoft.com/2006/09/sip/state">Some activity</custom>
</activity>
<delimiter xmlns="http://schemas.microsoft.com/2006/09/sip/commontypes" />
<timeZoneBias>420</timeZoneBias>
<timeZoneName>Pacific Daylight Time</timeZoneName>
<timeZoneAbbreviation>Pacific Daylight Time</timeZoneAbbreviation>
<device>computer</device>
<end xmlns="http://schemas.microsoft.com/2006/09/sip/commontypes" />
</state>
</category>
<category name="legacyInterop" instance="1" publishTime="2011-0426T17:37:15.397" container="200"
version="23" expireType="user">
<legacyInterop availability="3500" token="in-a-meeting" />
Page 19
</category>
<category name="state" instance="1" publishTime="2011-04-26T17:37:15.397"
container="400"
version="23" expireType="user">
<state xsi:type="aggregateState" xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance"
xmlns="http://schemas.microsoft.com/2006/09/sip/state">
<availability>3500</availability>
<activity token="in-a-meeting">
<custom LCID="1033"
xmlns="http://schemas.microsoft.com/2006/09/sip/state">Some activity</custom>
</activity><delimiter
xmlns="http://schemas.microsoft.com/2006/09/sip/commontypes" />
<timeZoneBias>420</timeZoneBias>
<timeZoneName>Pacific Daylight Time</timeZoneName>
<timeZoneAbbreviation>Pacific Daylight Time</timeZoneAbbreviation>
<device>computer</device>
<end xmlns="http://schemas.microsoft.com/2006/09/sip/commontypes" />
</state>
</category>
<category name="legacyInterop" instance="1" publishTime="2011-0426T17:37:15.397" container="400"
version="23" expireType="user">
<legacyInterop availability="3500" token="in-a-meeting" />
</category>
</categories>
</roamingData>
The results include all the state category instances affected by the publication request due
to the aggregation. Publishing a user state into container 2 causes the aggregation script to
run. In this example, there were no phone calls or meetings taking place at the time of the
publication. Thus, only the userState and machineState instances were used by the
aggregation script. It can be inferred from the results that the local user had two devices
online. One is a computer and the other is a desk phone. The aggregation script generates
the updated aggregateState, aggregateMachineState, and legacyInterop category
instances in container 2 and output aggregateState and legacyInterop to containers 100,
200 and 400. As the result the local user gets notified of the roaming data of the
userState, machineState, aggregateMachineState, aggregateState, and
legacyInterop category instances in containers 2, 100, 200 and 400.
Note. This publication is an example of the grammar-free publication where the Lync Server honors the
client specifications of the category name, instance ID and container Id. For details about grammar-based
and grammar-free publications, see the Enforcing Interoperability with Lync by Using Publication
Grammars section later in this chapter.
Lync publishes a userState category instance using a SIP SERVICE request when the user
selects a new availability mode (also known as presence status) in Lync, as illustrated in the
following figure.
Page 20
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.
Presence source
Description
Machine state
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
Machine
State Type
Availability
Activity
Description
Active (Busy)
3500
NULL
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
Offline
18500
NULL
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
Be Right Back
12500
Appear Away
15500
Off Work
15500
off-work
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
When the Lync user has stopped interacting with all the devices that are running
Lync for some time, which is configurable using the Lync Options button, Lync
publishes a machineState category instance containing the availability number of
15500 to containers 2 and 3. This causes the aggregation script to create an
aggregateState category instance containing the same availability number. The
resulting aggregateState category instance is user-bounded and has an instance ID
of 1, as shown in the following example.
<state xsi:type="aggregateState" lastActive="2011-04-28T22:38:26"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://schemas.microsoft.com/2006/09/sip/state">
<availability>15500</availability>
<delimiter xmlns="http://schemas.microsoft.com/2006/09/sip/commontypes" />
<timeZoneBias>420</timeZoneBias>
<timeZoneName>Pacific Daylight Time</timeZoneName>
<timeZoneAbbreviation>Pacific Daylight Time</timeZoneAbbreviation>
<device>computer</device>
<end xmlns="http://schemas.microsoft.com/2006/09/sip/commontypes" />
</state>
As a result, the users presence state is described by the default activity string of
Away. In this state, incoming calls ring first before being forwarded to voice mail
when the call is not answered. The Away status changes automatically when user
activity is detected.
When the Lync user manually sets their availability as Appear Away, Lync publishes
a static userState category instance to containers 2 and 3, as shown in the following
example.
<state xmlns="http://schemas.microsoft.com/2006/09/sip/state"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
manual="true"
xsi:type="userState">
<availability>15500</availability>
</state>
In response to this publication, the aggregation script updates the aggregateState
instance to reflect the new user setting. As a result, the users presence icon changes
to yellow and the displayed activity string shows the default activity string as Away,
which is derived from the availability number 15500. The user gets the notifications
of incoming calls from any contacts with the necessary permission. As a static
category instance, the userState publication remains unchanged until the user
resets it manually. This means that the Away status persists in the aggregateState
Page 23
category instance, making the user presence appear as Away, no matter what
other activities are undertaken by the user, until the user manually changes the
status.
When the Lync user selects the Off Work entry from the Availability menu, Lync
publishes a static userState category instance as shown in the following example.
<state xmlns="http://schemas.microsoft.com/2006/09/sip/state"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
manual="true"
xsi:type="userState">
<availability>15500</availability>
<activity token="off-work"
minAvailability="15000"
axAvailability="17999">
<custom LCID="1033">Off work</custom>
</activity>
</state>
In response to this publication, the aggregation script updates the aggregateState
instance with the availability number of 15500 and activity token of off-work. As a
result, the users presence icon changes to yellow in the Lync main window and the
associated activity string reads Off work. In this Away state, the user will not be
notified of any incoming phone calls because they are automatically routed to voice
mail. This userState publication remains unchanged until the user resets it explicitly.
This implies that this Away state persists in the aggregateState category instance,
making the user presence appear Off work, no matter what other activities are
undertaken by the user, until the user manually changes the status.
The Appear Away and Off Work modes are sometimes referred to as lurker modes because
the user can set these states and continue to be aware of everyone elses status around him
or her. All other users think that the user is not active and unavailable.
Lync publishes a phoneState category instance when the user is in a call, which can be a
one-on-one conversation or a multiparty conference call. The availability numbers and the
corresponding activity tokens are shown in the following table.
Table 8. Phone state presence values based on current user activity on the phone device
Availability
Activity token
Description
In a one-on-one
conversation
6500
on-the-phone
In a multiparty conversation
7000
in-a-conference
The following example shows a phoneState category instance when a two-party audio call
is in place.
<state xmlns="http://schemas.microsoft.com/2006/09/sip/state"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
manual="false"
xsi:type="phoneState">
<availability>6500</availability>
<activity token="on-the-phone"
Page 24
minAvailability="6500"
maxAvailability="8999" />
</state>
Publication of this category instance causes the aggregation script to run and, in turn, to
publish an aggregateState category instance containing the availability number (that is,
6500) and activity token (that is, on-the-phone) derived from the input phoneState
instance. While the call is in progress, these availability numbers and activity token are
reflected in aggregateState and the standard activity string of In a call is displayed to
show the users activity status.
For a multiparty conference call, Lync publishes a phoneState category instance as shown
in the following example.
<state xmlns="http://schemas.microsoft.com/2006/09/sip/state"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
manual="false"
xsi:type="phoneState">
<availability>7000</availability>
<activity token="in-a-conference"
minAvailability="7000"
maxAvailability="8999">
</activity>
</state>
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
Availability
Activity token
Description
Free
3500
NULL
Tentative
3500
NULL
In a meeting
6500
in-a-meeting
Out of Office
3500
out-of-office
The following example shows a calendarState published by Lync when the calendar of a
user (that is, bobkelly@contoso.com) indicates a meeting in progress.
<state xmlns="http://schemas.microsoft.com/2006/09/sip/state" manual="false"
uri="bobkelly@contoso.com" startTime="2010-07-01T23:30:00Z"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="calendarState">
<availability>6500</availability>
<activity token="in-a-meeting" minAvailability="6500" maxAvailability="8999" />
<endpointLocation>
</endpointLocation>
<meetingSubject>Project Update and status meeting</meetingSubject>
<meetingLocation>Online Ill forward invite</meetingLocation>
</state>
The calendarState item in the previous example shows that Bob has a meeting in his
calendar for a Project meeting and status update. When this meeting time occurs, Bobs
presence state will be changed to In a meeting, indicated by the value 6500. Note that
there is a maximum value for this state, as there is for most states. Any value between the
minAvailability and the maxAvailability are within the defined range for in a meeting.
It also indicates that Bobs possible user states can be Busy to IdleBusy, which both fall into
the range of minAvailability to maxAvailability.
Page 26
SIP domain names (for example, contoso.com) for anyone in the specified networks, or one
of the following special membership scopes:
Container name
Container ID
Description of container
Default
Self
Aggregation 1
Aggregation 2
External Contacts
100
Colleagues
200
Page 27
Container name
Container ID
Description of container
Workgroup
300
400
Blocked Contacts
32000
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
Page 31
The user can set this option on the Status page in Lync, as shown in the following figure.
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
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.
<publish xmlns="http://schemas.microsoft.com/2006/09/sip/rich-presence">
<publications uri="sip:bobkelly@contoso.com">
<publication categoryName="otherOptions" instance="2" container="1" version="6"
expireType="static">
<otherOptions
xmlns="http://schemas.microsoft.com/2006/09/sip/options/otherOptions">
<privacyModeUserSelection>private</privacyModeUserSelection>
<currentPrivacyMode>standard</currentPrivacyMode>
<lastQueryPrivacyEnabled>true</lastQueryPrivacyEnabled>
<publishActivityHistory>true</publishActivityHistory>
</otherOptions>
</publication>
</publications>
</publish>
While in the process of migrating from the standard privacy mode to the enhanced privacy
mode, Lync publishes the otherOptions category instance containing
migrattingToPrivacy as the value of the <currentPrivacyMode> element. This
communicates that migration is underway to the new enhanced privacy mode.
<publish xmlns="http://schemas.microsoft.com/2006/09/sip/rich-presence">
<publications uri="sip:bobkelly@contoso.com">
<publication categoryName="otherOptions" instance="2" container="1" version="7"
expireType="static">
<otherOptions
xmlns="http://schemas.microsoft.com/2006/09/sip/options/otherOptions">
<privacyModeUserSelection>private</privacyModeUserSelection>
<currentPrivacyMode>migratingToPrivacy</currentPrivacyMode>
<lastQueryPrivacyEnabled>true</lastQueryPrivacyEnabled>
<publishActivityHistory>true</publishActivityHistory>
</otherOptions>
</publication>
</publications>
</publish>
Behind the scenes, the migration involves a number of specific steps, including the
following: containers and their membership specifications must be readjusted; any existing
membership groups (that is, federated, publicCloud, and sameEnterprise) need to be
removed; and the access control entries on the containers need to be changed. Lync does
this by submitting a SERVICE request containing a setContainerMemers command in the
payload and specifying as the Content-Type header value application/msrtcsetcontainermembers+xml. Following is an example of this SIP message.
SERVICE sip:bobkelly@contoso.com SIP/2.0
Via: SIP/2.0/TLS 192.168.0.40:65000
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
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#
Lync publishes the following SIP SERVICE request containing an alerts category instance to
the users Self container (that is, container 1) as shown in the following example.
SERVICE sip:bobkelly@contoso.com SIP/2.0
Via: SIP/2.0/TLS 192.168.0.155:62154
Max-Forwards: 70
From: <sip:anahitab@contoso.com>;tag=62aec7b75a;epid=16ce6a1da0
To: <sip:anahitab@contoso.com>
Call-ID: 89e08728a9b842b9a4a469c044d7e733
Page 36
CSeq: 1 SERVICE
Contact: <sip:anahitab@contoso.com;opaque=user:epid:2OMA5poxVOPb7Z4ozfhpAAA;gruu>
User-Agent: UCCAPI/4.0.7577.0 OC/4.0.7577.0 (Microsoft Lync 2010)
Proxy-Authorization: TLS-DSK qop="auth", realm="SIP Communications Service",
opaque="D5ED691E", targetname="Pool01.contoso.com", crand="e37c5e78", cnum="60",
response="569395c91b5e3c001ec8065b94a56634ce3dd204"
Content-Type: application/msrtc-category-publish+xml
Content-Length: 326
<publish xmlns="http://schemas.microsoft.com/2006/09/sip/rich-presence">
<publications uri="sip:anahitab@contoso.com">
<publication categoryName="alerts" instance="0" container="1" version="8"
expireType="static">
<alerts xmlns="http://schemas.microsoft.com/2006/09/sip/options/alerts"/>
</publication>
</publications>
</publish>
When the request is accepted, Lync Server responds with the following SIP 200 OK message
as shown in the following example.
SIP/2.0 200 OK
ms-user-logon-data: RemoteUser
Authentication-Info: TLS-DSK qop="auth", opaque="D5ED691E", srand="A85DA2CE",
snum="60", rspauth="b25dc9096a20a93ecb712606cc42d980bea07665",
targetname="Pool01.contoso.com", realm="SIP Communications Service", version=4
Content-Length: 497
From: "Anahita"<sip:anahitab@contoso.com>;tag=62aec7b75a;epid=16ce6a1da0
To: <sip:anahitab@contoso.com>;tag=9B07C1614112F9B18B8C6D8A525986E4
Call-ID: 89e08728a9b842b9a4a469c044d7e733
CSeq: 1 SERVICE
Via: SIP/2.0/TLS 192.168.0.155:62154;received=157.54.125.148;ms-receivedport=62154;ms-received-cid=23705D00
Content-Type: application/vnd-microsoft-roaming-self+xml
<roamingData xmlns="http://schemas.microsoft.com/2006/09/sip/roaming-self"
xmlns:cat="http://schemas.microsoft.com/2006/09/sip/categories">
<categories xmlns="http://schemas.microsoft.com/2006/09/sip/categories" uri="sip:
anahitab@contoso.com">
<category name="alerts" instance="0" publishTime="2011-05-06T03:36:33.340"
container="1"
version="9" expireType="static">
<alerts xmlns="http://schemas.microsoft.com/2006/09/sip/options/alerts"></alerts>
</category>
</categories>
</roamingData>
The roaming data is also returned in the self-subscription, which is discussed in details in
the next section.
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.
Page 38
<batchSub xmlns="http://schemas.microsoft.com/2006/01/sip/batch-subscribe"
uri="sip:bobkelly@contoso.com" name="">
<action name="subscribe" id="103843728">
<adhocList>
<resource uri="sip:anahitab@contoso.com"/>
</adhocList>
<categoryList xmlns="http://schemas.microsoft.com/2006/09/sip/categorylist">
<category name="noteHistory"/>
</categoryList>
</action>
</batchSub>
The previous request is either from a query or part of a polling subscription because the
Expires header value is set to zero (0). In a persistent subscription, the Expires header
will be absent from the SUBSCRIBE request.
When accepted, the server responds with an SIP 200 OK response containing the requested
data. An example of the SIP response to this SIP SUBSCRIBE request is shown in the
following example.
SIP/2.0 200 OK
Contact: <sip:LYNC-SE.contoso.com:5061;transport=tls>
Authentication-Info: TLS-DSK qop="auth", opaque="279520A0", srand="5B6EFD4F",
snum="15", rspauth="1891e3d14c9822c7dc1589cf3479fc9febd67bed", targetname="LYNCSE.contoso.com", realm="SIP Communications Service", version=4
Content-Length: 769
From: "Bob"<sip:bobkelly@contoso.com>;tag=8654485aef;epid=5fb4cad0ca
To: <sip:bobkelly@contoso.com>;tag=BE180080
Call-ID: 6ce5f131bf60434c9cf15b14bf82f48e
CSeq: 1 SUBSCRIBE
Via: SIP/2.0/TLS 192.168.0.40:54364;ms-received-port=54364;ms-received-cid=380900
Expires: 0
Require: eventlist
Content-Type: multipart/related; type="application/rlmi+xml";start=resourceList;
boundary=bfd74156b52c441c98b8e3d27b840bbe
Event: presence
subscription-state: terminated;expires=0
ms-piggyback-cseq: 1
Supported: ms-benotify, ms-piggyback-first-notify
--bfd74156b52c441c98b8e3d27b840bbe
Content-Transfer-Encoding: binary
Content-ID: resourceList
Content-Type: application/rlmi+xml
<list xmlns="urn:ietf:params:xml:ns:rlmi" uri="sip:bobkelly@contoso.com" version="0"
fullState="false"/>
--bfd74156b52c441c98b8e3d27b840bbe
Content-Transfer-Encoding: binary
Content-Type: application/msrtc-event-categories+xml
Page 39
<categories xmlns="http://schemas.microsoft.com/2006/09/sip/categories"
uri="sip:anahitab@contoso.com">
<category name="noteHistory" instance="1864567" publishTime="2010-1229T20:19:02.937">
<noteHistory xmlns="http://schemas.microsoft.com/2006/09/sip/note">
<body type="personal" uri="">LYNC 2010 is COOL!!!</body>
</noteHistory>
</category>
</categories>
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.
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
Page 42
</contactExtension>
<m:externalURI></m:externalURI>
<m:deltaNum>137</m:deltaNum>
</m:setContact>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
In this example, the SERVICE request is made to the server (that is, sip:LYNCSE.contoso.com) by the local user (that is, Bob Kelly) to add Anahita to contact groups 1
and 6. New contact groups are added to the server in the same fashion with a different
SOAP envelope containing the specified contact group. The following example illustrates this
SOAP message body for creating a contact group named New Group.
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body><m:addGroup
xmlns:m="http://schemas.microsoft.com/winrtc/2002/11/sip">
<m:name>New Group</m:name>
<m:externalURI/>
<m:deltaNum>135</m:deltaNum>
</m:addGroup>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
To receive the presence publication or update of the contacts, Lync first retrieves the
Contacts list, including contact groups, from the Lync Server. It does so, after the user is
signed in, by submitting the following SUBSCRIBE request without a payload.
SUBSCRIBE sip:bobkelly@contoso.com SIP/2.0
Via: SIP/2.0/TLS 192.168.0.40:54364
Max-Forwards: 70
From: <sip:bobkelly@contoso.com>;tag=44f75f3015;epid=5fb4cad0ca
To: <sip:bobkelly@contoso.com>
Call-ID: 70cf12e227d7463db7b282ab6c4dff37
CSeq: 1 SUBSCRIBE
Contact: <sip:bobkelly@contoso.com;opaque=user:epid:NkxRZvAY1GqwgtgoyCyOwAA;gruu>
User-Agent: UCCAPI/4.0.7577.0 OC/4.0.7577.0 (Microsoft Lync 2010)
Event: vnd-microsoft-roaming-contacts
Accept: application/vnd-microsoft-roaming-contacts+xml
Supported: com.microsoft.autoextend
Supported: ms-benotify
Proxy-Require: ms-benotify
Supported: ms-piggyback-first-notify
Proxy-Authorization: TLS-DSK qop="auth", realm="SIP Communications Service",
opaque="279520A0", targetname="LYNC-SE.contoso.com", crand="1b0f2b97", cnum="3",
response="0d63b6b06fa75d6e1d6498ae1b4f020a509c00c6"
Content-Length: 0
The Event header value is specified as vnd-microsoft-roaming-contacts and Accept header
value is application/vnd-microsoft-roaming-contacts+xml.
Page 43
The server returns the results in a SIP 200 OK response, as shown in the following example.
SIP/2.0 200 OK
Contact: <sip:LYNC-SE.contoso.com:5061;transport=tls>
Authentication-Info: TLS-DSK qop="auth", opaque="279520A0", srand="B0FB0C3F",
snum="3", rspauth="b8bb693aec8cf66fbdb40f3749257bad34bcf91c", targetname="LYNCSE.contoso.com", realm="SIP Communications Service", version=4
Content-Length: 585
From: "Bob"<sip:bobkelly@contoso.com>;tag=44f75f3015;epid=5fb4cad0ca
To: <sip:bobkelly@contoso.com>;tag=01FD4572
Call-ID: 70cf12e227d7463db7b282ab6c4dff37
CSeq: 1 SUBSCRIBE
Via: SIP/2.0/TLS 192.168.0.40:54364;ms-received-port=54364;ms-received-cid=380900
Expires: 27503
Content-Type: application/vnd-microsoft-roaming-contacts+xml
Event: vnd-microsoft-roaming-contacts
subscription-state: active;expires=27503
ms-piggyback-cseq: 1
Supported: ms-benotify, ms-piggyback-first-notify
<contactList deltaNum="7" >
<group id="1" name="~" externalURI="" />
<group id="2" name="Pinned Contacts" externalURI="<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.
Page 44
To: <sip:bobkelly@contoso.com>
Call-ID: f0dc3382e27740a989d8145f2fc33583
CSeq: 1 SUBSCRIBE
Contact: <sip:bobkelly@contoso.com;opaque=user:epid:2OMA5poxVOPb7Z4ozfhpAAA;gruu>
User-Agent: UCCAPI/4.0.7577.0 OC/4.0.7577.0 (Microsoft Lync 2010)
Event: presence
Accept: application/msrtc-event-categories+xml, application/xpidf+xml,
text/xml+msrtc.pidf, application/pidf+xml, application/rlmi+xml, multipart/related
Supported: com.microsoft.autoextend
Supported: ms-benotify
Proxy-Require: ms-benotify
Supported: ms-piggyback-first-notify
Require: adhoclist, categoryList
Supported: eventlist
Proxy-Authorization: TLS-DSK qop="auth", realm="SIP Communications Service",
opaque="EF9CEB7C", targetname="Pool01.contoso.com", crand="d3e6517a", cnum="13",
response="555c0bb62826a14fbc4cd3c52a550478f2f148c5"
Content-Type: application/msrtc-adrl-categorylist+xml
Content-Length: 1476
<batchSub xmlns="http://schemas.microsoft.com/2006/01/sip/batch-subscribe"
uri="sip:bobkelly@contoso.com" name="">
<action name="subscribe" id="181311632">
<adhocList>
<resource uri="sip:anahitab@contoso.com "/>
<resource uri="sip:cyncarey@contoso.com "/>
</adhocList>
<categoryList xmlns="http://schemas.microsoft.com/2006/09/sip/categorylist">
<category name="state"/>
<category name="contactCard"/>
<category name="services"/>
<category name="note"/>
<category name="calendarData"/>
</categoryList>
</action>
</batchSub>
This subscription is subject to the limitations of the presence policy discussed earlier. When
the CategorySubscriptions property is set to 3000, the maximum number of contacts that
Bob can add to his Contacts list is 600, because he has chosen to subscribe to five
categories of state, contactCard, services, note and calendarData.
After the request is accepted by the server, the submitting client receives a SIP 200 OK
response containing the requested result. Partial results might be returned. A portion of that
response is shown in the following example.
SIP/2.0 200 OK
ms-user-logon-data: RemoteUser
Authentication-Info: TLS-DSK qop="auth", opaque="64DD2BFE", srand="CA11761B",
snum="17", rspauth="7948287280886daef0c0ec84e59b83673291ac10",
Page 45
--cad79b9531f84c7188ba13cadcb25c46
Content-Transfer-Encoding: binary
Content-ID: resourceList
Content-Type: application/rlmi+xml
<list xmlns="urn:ietf:params:xml:ns:rlmi" uri="sip:bobkelly@contoso.com" version="0"
fullState="false"/>
<resource uri="sip:anahitab@contoso.com">
<instance id="0" state="resubscribe" cid="anahitab@contoso.com"
poolFqdn="sip:pool01.contoso.com@contoso.com;gruu;opaque=srvr:HomeServer:GEAUnGh6lqC9C0_AgsCUQAA"/>
</resource>
<resource uri="sip:cyncarey@contoso.com ">
<instance id="0" state="resubscribe" cid="cyncarey@contoso.com" poolFqdn="
sip:pool01.contoso.com@contoso.com;gruu;opaque=srvr:HomeServer:GEAUnGh6lqC9C0_AgsCUQAA"/>
</resource>
--cad79b9531f84c7188ba13cadcb25c46
Content-Transfer-Encoding: binary
Content-Type: application/msrtc-event-categories+xml
<categories xmlns="http://schemas.microsoft.com/2006/09/sip/categories"
uri="sip:anahitab@contoso.com">
<category name="calendarData"/>
Page 46
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.
Page 48
subscription is persistent because the Expires header is not present in the SIP message.
The body of the SIP request message specifies the types of data to be received in the selfsubscription. In Lync, as shown in this example, they include the presence categories
published by the local user, the containers used by the local user for publications, and the
remote users that are currently subscribing to the local users presence, and the users
designated as the delegates of the local user. The results are returned to the requesting
client in a SIP 200 OK response. For the preceding example, a SIP response is shown in the
following example.
Note. The response has been truncated for the sake of brevity. You can view a full response via tracing.
SIP/2.0 200 OK
Contact: <sip:LYNC-SE.contoso.com:5061;transport=tls>
Authentication-Info: TLS-DSK qop="auth", opaque="279520A0", srand="0E94188B",
snum="5", rspauth="c66167dfebef6878384e8b3d0ef898005848e848", targetname="LYNCSE.contoso.com", realm="SIP Communications Service", version=4
Content-Length: 30628
From: "Bob"<sip:bobkelly@contoso.com>;tag=f85eb73b02;epid=5fb4cad0ca
To: <sip:bobkelly@contoso.com>;tag=84670080
Call-ID: 2e8e76009d544ebab9f571387851db1d
CSeq: 1 SUBSCRIBE
Via: SIP/2.0/TLS 192.168.0.40:54364;ms-received-port=54364;ms-received-cid=380900
Expires: 26496
Require: eventlist
Content-Type: application/vnd-microsoft-roaming-self+xml
Event: vnd-microsoft-roaming-self
subscription-state: active;expires=26496
ms-piggyback-cseq: 1
Supported: ms-benotify, ms-piggyback-first-notify
<roamingData xmlns="http://schemas.microsoft.com/2006/09/sip/roaming-self"
xmlns:cat="http://schemas.microsoft.com/2006/09/sip/categories"
xmlns:con="http://schemas.microsoft.com/2006/09/sip/containers"
xmlns:sub="http://schemas.microsoft.com/2006/09/sip/presence-subscribers"
xmlns:del="http://schemas.microsoft.com/2007/09/sip/delegates">
<categories xmlns="http://schemas.microsoft.com/2006/09/sip/categories"
uri="sip:bobkelly@contoso.com">
<category name="calendarData" instance="0" publishTime="2010-12-29T18:05:38.560"
container="32000" version="2" expireType="static">
<calendarData
xmlns="http://schemas.microsoft.com/2006/09/sip/calendarData"></calendarData>
</category>
<category name="calendarData" instance="1521659821" publishTime="2011-0506T07:00:08.207" container="32000" version="3" expireType="time" expires="45653">
<calendarData
xmlns="http://schemas.microsoft.com/2006/09/sip/calendarData"></calendarData>
</category>
<category name="calendarData" instance="0" publishTime="2010-12-29T18:05:38.560"
container="400" version="1" expireType="static">
<calendarData xmlns="http://schemas.microsoft.com/2006/09/sip/calendarData"
mailboxID="bobkelly@contoso.com"><WorkingHours
xmlns="http://schemas.microsoft.com/exchange/services/2006/types"><TimeZone><Bias>
480</Bias><StandardTime><Bias>0</Bias><Time>02:00:00</Time><DayOrder>1</Day
Order><Month>11</Month><DayOfWeek>Sunday</DayOfWeek></StandardTime><Dayli
Page 49
ghtTime><Bias>60</Bias><Time>02:00:00</Time><DayOrder>2</DayOrder><Month>3</Month><DayO
fWeek>Sunday</DayOfWeek></DaylightTime></TimeZone><WorkingPeriodArray><Worki
ngPeriod><DayOfWeek>Monday Tuesday Wednesday Thursday
Friday</DayOfWeek><StartTimeInMinutes>480</StartTimeInMinutes><EndTimeInMinutes
>1020</EndTimeInMinutes></WorkingPeriod></WorkingPeriodArray></WorkingHours></c
alendarData>
</category>
<category name="calendarData" instance="1521659821" publishTime="2011-0506T07:00:08.207" container="400" version="3" expireType="time" expires="45653">
<calendarData xmlns="http://schemas.microsoft.com/2006/09/sip/calendarData"
mailboxID="bobkelly@contoso.com"><freeBusy startTime="2011-05-05T07:00:00Z"
granularity="PT15M"
encodingVersion="1">AAAAAAAAAAAAAAAAAAAAAFAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAA</freeBusy></calendarData>
</category>
<category name="calendarData" instance="0" publishTime="2010-12-29T18:05:38.560"
container="300" version="1" expireType="static">
<calendarData xmlns="http://schemas.microsoft.com/2006/09/sip/calendarData"
mailboxID="bobkelly@contoso.com">
<WorkingHours xmlns:autons1="http://schemas.microsoft.com/2006/09/sip/calendarData"
xmlns="http://schemas.microsoft.com/exchange/services/2006/types"><TimeZone><Bias>
480</Bias><StandardTime><Bias>0</Bias><Time>02:00:00</Time><DayOrder>1</Day
Order><Month>11</Month><DayOfWeek>Sunday</DayOfWeek></StandardTime><Dayli
ghtTime><Bias>60</Bias><Time>02:00:00</Time><DayOrder>2</DayOrder><Month>3</Month><DayO
fWeek>Sunday</DayOfWeek></DaylightTime></TimeZone><WorkingPeriodArray><Worki
ngPeriod><DayOfWeek>Monday Tuesday Wednesday Thursday
Friday</DayOfWeek><StartTimeInMinutes>480</StartTimeInMinutes><EndTimeInMinutes
>1020</EndTimeInMinutes></WorkingPeriod></WorkingPeriodArray></WorkingHours>
</calendarData>
</category>
<category name="calendarData" instance="1521659821" publishTime="2011-0506T07:00:08.207" container="300" version="3" expireType="time" expires="45653">
<calendarData xmlns="http://schemas.microsoft.com/2006/09/sip/calendarData"
mailboxID="bobkelly@contoso.com">
<freeBusy startTime="2011-05-05T07:00:00Z"
granularity="PT15M"
encodingVersion="1">AAAAAAAAAAAAAAAAAAAAAFAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAA</freeBusy>
</calendarData>
</category>
<category name="calendarData" instance="0" publishTime="2010-12-29T18:05:38.560"
container="200" version="1" expireType="static">
<calendarData xmlns="http://schemas.microsoft.com/2006/09/sip/calendarData"
mailboxID="bobkelly@contoso.com">
The process continues until the user signs out or the subscription is terminated.
Page 50
Receiving Lync Server Configuration Settings and Other System Data by Using
In-band Provisioning
The subscription mechanism is also used by the Lync Server to provision configuration data
and policy settings. This process is known as in-band provisioning and involves the Lync
Server client submitting a SUBSCRIBE request containing the provisioning group names and
parsing the results returned in a SIP/2.0 200 OK response from the server. For details, see
the Client Provisioning section in the Instant Messaging chapter of the Resource Kit
available for download from the Microsoft Download Center at
http://go.microsoft.com/fwlink/?LinkId=211003.
Summary
In this chapter, you learned that Lync Server 2010 provides an enhanced presence service
that relays presence information between two communication entities. The process involves
SIP-based messaging to enable the presence publication, subscription, and querying. This
presence system is versatile and can handle any application-specific presence data. The
versatility is supported by a flexible XML-based presence data model as represented by the
enhanced presence category.
Additional Resources
For more information, see the following:
Page 51