< draft-rosenberg-impp-presence-00.txt   draft-rosenberg-impp-presence-01.txt >
Internet Engineering Task Force IMPP WG
Internet Draft Jonathan Rosenberg
Dean Willis
Robert Sparks
Ben Campbell
dynamicsoft
Henning Schulzrinne
Jonathan Lennox
Columbia U.
Bernard Aboba Internet Engineering Task Force SIMPLE WG
Christian Huitema Internet Draft Rosenberg et al.
David Gurle draft-rosenberg-impp-presence-01.txt Various Places
Microsoft March 2, 2001
Expires: September 2001
Dave Oran
Cisco
draft-rosenberg-impp-presence-00.txt
June 15, 2000
Expires: December, 2000
SIP Extensions for Presence SIP Extensions for Presence
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 50 skipping to change at page 1, line 35
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document proposes an extension to SIP for subscriptions and This document proposes an extension to SIP for subscriptions and
notifications of user presence. Traditional SIP clients already make notifications of user presence. User presence is defined as the
use of the REGISTER method to upload presence state to network willingness and ability of a user to communicate with other users on
servers, in order to enable call establishment. This extension allows the network. Historically, presence has been limited to "on-line" and
that data to be published to subscribers. This is accomplished by "off-line" indicators; the notion of presence here is broader.
defining two new SIP methods - SUBSCRIBE and NOTIFY, and by defining Subscriptions and notifications of user presence are supported by
a new logical entity, the presence agent (PA), which handles defining an event package within the general SIP event notification
subscriptions and notifications. framework. This protocol is also compliant with the Common Presence
and Instant Messaging (CPIM) framework.
1 Introduction 1 Introduction
Presence is (indirectly) defined in RFC2778 [1] as subscription to Presence is (indirectly) defined in RFC2778 [1] as subscription to
and notification of changes in the communications state of a user. and notification of changes in the communications state of a user.
This communications state consists of the set of communications This communications state consists of the set of communications
means, communications address, and status of that user. A presence means, communications address, and status of that user. A presence
protocol is a protocol for providing such a service over the Internet protocol is a protocol for providing such a service over the Internet
or any IP network. or any IP network.
This document proposes an extension to the Session Initiation This document proposes an extension to the Session Initiation
Protocol (SIP) [2] for presence. Baseline SIP is used primarily for Protocol (SIP) [2] for presence. This extension is a concrete
initiation of interactive sessions, such as voice, video, and games. instantiation of the general event notification framework defined for
The process of session initiation requires a system which uses the SIP [3], and as such, makes use of the SUBSCRIBE and NOTIFY methods
communications means, communications addresses, and communications defined there. User presence is particularly well suited for SIP. SIP
status of a user in order to determine the host where initiation registrars and location services already hold user presence
requests can be delivered. A presence system is one where this information; it is uploaded to these devices through REGISTER
information is pushed to subscribers through notification requests, messages, and used to route calls to those users. Furthermore, SIP
as opposed to being pulled by proxy and redirect servers when session networks already route INVITE messages from any user on the network
establishment is desired. In a sense, this makes presence and session to the proxy that holds the registration state for a user. As this
initiation "duals" - one is synchronous (presence systems push data state is user presence, those SIP networks can also allow SUBSCRIBE
the instant it changes) and the other is asynchronous (servers access requests to be routed to the same proxy. This means that SIP networks
presence data for a user at the point where a call is initiated to can be reused to establish global connectivity for presence
that user). The similarities between presence and communications subscriptions and notifications.
establishment is one reason why we chose to base the presence
protocol on SIP. Section 2 explains this in greater detail.
The extension defined here has, as its objectives, scalability,
security, flexibility, and extensibility. To provide scale, our
protocol (1) pushes intelligence to the periphery wherever possible,
as we believe this to be the primary tool for achieving this goal,
(2) allows the global namespace to be divided into a hierarchy, and
(3) allows presence state to be distributed along this hierarchy.
Many of the capabilities of this extension for providing scale are
simply inherited from SIP, which was engineered to handle highly
scalable communications establishment. This extension also makes
communications between differing administrative domains possible. The
scale objectives and mechanisms for achieving it are outlined in
detail in section 9.
Presence deals with highly sensitive data regarding people, and we
can envision future applications which deal with information like the
physical location of individuals, which is even more sensitive. To
handle this, privacy of the information distributed, and
authentication of relevant parties in the system is provided by the
system.
Finally, flexibility is important. It is likely that a protocol for
subscription and notification of events related to communications
will be applied to other applications. Even within the general area
of communications, subscription and notification services are needed
for features like auto callback and message waiting indication. While
these are not directly addressed by this extension, we have
engineered in sufficient flexibility to enable them in a systematic
fashion. This is accomplished by separating the protocol operation
from the underlying transport (UDP, TCP, or anything else can be
used), and by separating the transfer of subscriptions and
notifications from their content. The extension is also flexible in
that it can support client to client subscriptions and notifications
with no server at all (serverless operation), support a single server
for intra-domain operation, multiple servers for intra-domain
operation, and inter-domain operation with a server in one domain,
the other, or both.
2 Why use SIP as a base protocol for presence?
We have chosen the Session Initiation Protocol (SIP) as a starting
point for developing a presence protocol. This is for many reasons.
Overall, our aim is to reuse infrastructure and components which help
solve the problem. We have found that SIP solves a very similar
problem, with the result that minimal work is required to extend it
to solve the problem at hand.
SIPs primary function is to initiate interactive multiparty
communications sessions. The challenge in doing this is to allow a
caller to take a location independent identifier, such as
joe@example.com, and use it to discover the location of the user
(where location in this context refers to a host on the Internet
where the user can be reached), so that the invitation to join a
session can be delivered. The problem is challenging because users
move around, have dynamically assigned IP addresses, may be reachable
at numerous locations and via multiple devices, and may have varying
capabilities at those locations. SIP operates by allowing users to
send communications reachability state to the network, and this
information is used by the network to "rendezvous" the caller with
the called party. Within baseline SIP, this communications
reachability state consists primarily of communications addresses.
However, an extension, caller preferences and callee capabilities
[3], extends this state to include status and capabilities. This
enables a much more powerful form of rendezvous. For example, a
caller can dial a generic number for the called party, specify in the
call establishment request that communications is desired with a
mobile phone, and the call will be preferentially routed to the users
cell phone.
We observed that the information used by network elements within SIP
to rendezvous callers with called users is the *same* information
distributed by a presence protocol. The only difference is in the
application of this information. In SIP, this information is not
distributed to interested parties when it changes, but rather used on
demand to set up a call. In essence, SIP makes use of this state
(uploaded to the network in REGISTER requests) for asynchronously
initiated queries for communications, while presence distributes it
synchronously when it changes. Effectively, session initiation and
presence are "duals" of each other, relying on the same information.
Because of this, extension of SIP to satisfy the needs of a presence
protocol seems very sensible - a re-use of "information".
There is also significant reuse of protocol machinery, and more
importantly, reuse of deployed components, infrastructure, and data.
Conceptually, using the same infrastructure for initiation of
communications, and for distribution of communications state, seems
natural. It means that the same system provides both components of
interactive communications services, working seamlessly and
efficiently. Reuse of the same infrastructure means a big reduction
in management and infrastructure costs for providers. Perhaps most
importantly, using the same underlying protocols and infrastructures
makes it easy to provide new services which integrate voice/video and
presence.
Furthermore, we anticipate that many systems will offer both
communications establishment and presence on the same device, such as
a wireless handset. Therefore, using the same underlying protocol
components for both is a substantial practical advantage in terms of
code reuse and memory footprint reduction, both of which are very
important for wireless handsets. Real SIP implementations exist with
memory footprints well under 100k. As only a subset of SIP is needed
for presence, this number will be even lower for presence-only
systems.
The abstract arguments made in the previous paragraph manifest
themselves through a common set of requirements for both presence and
session initiation. As a result, there are many capabilities already
present in SIP which are directly applicable to presence. In
particular:
Scale: SIP must scale to support initiation of communications
sessions among the global Internet populace. This presents
demanding scale requirements. To meet them, SIP allows for
the global namespace of users to be divided up
hierarchically, with dynamic communications state stored
only in the leaves of the hierarchy. Network elements
(called proxies) within the hierarchy can be stateless,
handling routing of requests downward in the hierarchy, and
responses upwards, without storing any information. This
simulaneously provides both scale and fault tolerance.
Rendezvous: SIP must allow a caller to have an initiation
request routed to the server which has authoritative
information about the location and communications
capabilities of the called user. For presence, a mechanism
is needed to route subscription requests to the server
which has authoritative information about the location and
communications capabilities of the subscribed-to user.
Clearly, these are the same exact problem, and SIPs
existing rendezvous and routing capabilities are directly
applicable for presence.
Identity of Participants: In SIP, it is critical to be able to
identify the initiator of the request, and the target of
the communications. In presence, messages need to identify
the initiator of the subscription, and its target. These
are the same parties. The SIP mechanisms for identification
of entities are therefore directly usable for presence.
Authentication of Initiator: In SIP, it is essential that the
called party be able to verify the identity of the caller,
in order to prevent calls from unwanted parties. In
presence, it is essential that the presentity be able to
verify the identity of the subscriber, in order to prevent
subscriptions from unwanted parties. Both are the same
problem, and readily accomplished with end to end
authentication mechanisms. SIP currently provides three
such mechanisms, one of which is public key based (PGP),
and the other two of which are based on a shared secret
(http basic and digest). The protocol is extensible to
support additional mechanisms. Furthermore, SIP provides
proxy-signed requests, so that the presentity can verify
the domain of the originator.
End-to-end privacy of Data: In SIP, the bodies, and several of
the headers of the request and response messages can be
encrypted, using PGP. This allows for privacy of sessions
users are being invited to. For presence, there is a need
for end to end privacy of the presence state users convey,
which is also encapsulated in bodies. Thus, the SIP
encryption mechanisms can provide privacy for presence.
Hop-by-Hop Encryption: End to end encryption is important, but
requires deployment of a PKI with end user keys. As none
really exists, a secondary level of privacy can be provided
when a transitive trust relationship exists between users
and network elements of multiple administrative domains.
This is through hop by hop encryption between users and
proxies and proxies and proxies. SIP allows hop by hop
encryption based on any number of mechanisms, and this
concept can be reused for privacy of presence as well.
Content: SIP uses MIME to carry content in its messages.
Normally, this content is the Session Description Protocol
(SDP) [4] which defines sessions, but other content is
allowed. Subscription requests need to carry documents that
describe details of the subscription, and notification
requests carry documents that describe the state of the
presentity. We propose that MIME is also used for this
purpose. This provides important extensibility
capabilities. As these capabilities are already provided by
SIP, no additional work is needed to support them in
presence.
Transport Independence: SIP is used to establish communications This extension is based on the concept of a presence agent, which is
sessions. A widely varying set of devices is likely to make a new logical entity that is capable of accepting subscriptions,
use of such services, including PCs, wireless PDAs (in storing subscription state, and generating notifications when there
fact, the 3GPP wireless standards body has already chosen are changes in user presence. The entity is defined as a logical one,
SIP as the signaling platform for third generation wireless since it is generally co-resident with another entity, and can even
devices), standalone phones, cell phones, laptops, and even move around during the lifetime of a subscription.
Internet appliances. In recognition of the diverse
connectivity these devices have, SIP is transport neutral,
and can run over any protocol, including TCP and UDP. It
can also be run over the newer SCTP [5], and a process for
doing so is defined in a companion document [6].
Soft State: In SIP, the communications state pushed into the This extension is also compliant with the Common Presence and Instant
network must be periodically refreshed in order for it to Messaging (CPIM) framework that has been defined in [4]. This allows
remain present. This soft state mechanism provides SIP for presence to easily interwork with other presence systems
robustness against system crashes. The period of refresh compliant to CPIM.
can be negotiated through a simple two phase mechanism. In
presence, this mechanism is not only needed for
communications state, but also for subscriptions, which
represent a new piece of state in the system. SIPs existing
refresh mechanisms can be reused for this purpose.
These similarities mean that the majority of SIPs mechanisms are 2 Definitions
directly applicable for presence. SIP proxies can route presence
requests with no change. Section 12 details those components of SIP
which are, and are not, needed for presence.
3 Definitions
This document uses the terms as defined in [1]. Additionally, the This document uses the terms as defined in [1]. Additionally, the
following terms are defined and/or additionally clarified: following terms are defined and/or additionally clarified:
User Agent (UA): A SIP User Agent. A UA is capable of sending
and receiving SIP requests.
User Agent Server (UAS): A UAS is the component of a UA which
receives requests, and responds to them.
User Agent Client (UAC): A UAC is the component of a UA which
sends requests, and receives responses.
Registrar: A registrar is a SIP server which can receive and
process REGISTER requests. These requests are used to
construct address bindings.
Proxy: A proxy is a SIP proxy. A SIP proxy receives a SIP
request, modifies some of the headers, and forwards the
request to a next-hop server, which can be another proxy,
or possibly a user agent.
Presence User Agent (PUA): A Presence User Agent manipulates Presence User Agent (PUA): A Presence User Agent manipulates
presence information for a presentity. In SIP terms, this presence information for a presentity. In SIP terms, this
means that a PUA generates REGISTER requests, conveying means that a PUA generates REGISTER requests, conveying
some kind of information about the presentity. We some kind of information about the presentity. We
explicitly allow multiple PUAs per presentity. This means explicitly allow multiple PUAs per presentity. This means
that a user can have many devices (such as a cell phone and that a user can have many devices (such as a cell phone and
PDA), each of which is independently generating a component PDA), each of which is independently generating a component
of the overall presence information for a presentity. PUAs of the overall presence information for a presentity. PUAs
push data into the presence system, but are outside of it, push data into the presence system, but are outside of it,
in that they do not receive SUBSCRIBE messages, or send in that they do not receive SUBSCRIBE messages, or send
skipping to change at page 7, line 46 skipping to change at page 3, line 14
Presence Agent (PA): A presence agent is a SIP user agent which Presence Agent (PA): A presence agent is a SIP user agent which
is capable of receiving SUBSCRIBE requests, responding to is capable of receiving SUBSCRIBE requests, responding to
them, and generating notifications of changes in presence them, and generating notifications of changes in presence
state. A presence agent must have complete knowledge of the state. A presence agent must have complete knowledge of the
presence state of a presentity. Typically, this is presence state of a presentity. Typically, this is
accomplished by co-locating the PA with the accomplished by co-locating the PA with the
proxy/registrar, or the presence user agent of the proxy/registrar, or the presence user agent of the
presentity. A PA is always addressable with a SIP URL. presentity. A PA is always addressable with a SIP URL.
Presence Server: A presence server is a presence agent that is Presence Server: A presence server is a logical entity that can
colocated with a proxy/registrar. It is aware of the act as either a presence agent or as a proxy server for
SUBSCRIBE requests. When acting as a PA, it is aware of the
presence information of the presentity through some presence information of the presentity through some
protocol means. This protocol means can be SIP REGISTER protocol means. This protocol means can be SIP REGISTER
requests, but other mechanisms are allowed. requests, but other mechanisms are allowed. When acting as
a proxy, the SUBSCRIBE requests are proxied to another
entity that may act as a PA.
Presence Client: A presence client is a presence agent that is Presence Client: A presence client is a presence agent that is
colocated with a PUA. It is aware of the presence colocated with a PUA. It is aware of the presence
information of the presentity because it is co-located with information of the presentity because it is co-located with
the entity that manipulates this presence information. the entity that manipulates this presence information.
4 Overview of Operation 3 Overview of Operation
In this section, we present an overview of the operation of this In this section, we present an overview of the operation of this
extension. It defines two new methods, SUBSCRIBE (for subscribing to extension.
changes in state), and NOTIFY (for notifying subscribers of changes
in state).
4.1 Architecture
We define a new type of SIP user agent, called a Presence Agent, or
PA. A PA is a logical function, and is usually co-located with either
a proxy/registrar, or a PUA. A PA is capable of storing subscriptions
and generating notifications. Since a PA can reside either in either
a proxy/registrar or within the PUA, the system allows both "network"
and "client" generated notifications and management of subscriptions.
In fact, the role of PA is defined on a subscription by subscription
basis, and can change during the lifetime of the subscription. This
allows for the PA function to migrate from PUA to presence server and
back, depending on the connectivity of the PUA.
PAs generate notifications. These notifications can be delivered
directly to the subscriber, or proxies on the subscription path can
elect to receive the notifications as well. Such flexibility allows
each administrative domain to make its own decision regarding the
tradeoffs between security, scalability, and provision of services.
This flexibility is inherited from SIP.
The architecture is depicted in Figure 1.
4.2 Message Flow
A subscriber, acting as a User Agent Client (in SIP, an end system
which sends requests is called a User Agent Client, or UAC) wishing
to subscribe to some presentity constructs a SIP SUBSCRIBE request
message. The request URI of this request is a normal SIP URL
identifying the address of the presentity. This request URI is
rewritten by SIP proxies (which are very similar to HTTP proxies) as
the request travels towards the recipient. For example, a request for
sip:joe@example.com will arrive at the example.com server, which
looks up Joe in some corporate database, and then determines that Joe
can be reached internally at sip:joe@engineering.example.com. This
new address is placed in the request URI of the outgoing request, and
+-------+
| |
/\| Proxy |\
/ | | \ SUB
SUB / +-------+ \
/ \
/ \/
+-------+ +-------+
| | | |
| Proxy | | Proxy |
| | | |
+-------+ +-------+
/ \
/ \ / \ SUB
/ \ \
/ \ <---- \/
/ Sub- \ -------- +----------+
/ scriber\ -------- | |
/-----------\ NOTIFY ----- |Proxy/ |
|Registrar/|
|PA |
| |
+----------+
/
SUB // /\ ^
NOTIFY / / |
// / |REGISTER
/ / |
// / |
/ \ / / \ / \
/PA+\ / \ / \
/ PUA \ / PUA \ / PUA \
------- ------- -------
Figure 1: Architecture of Presence System
sent to the server for engineering.example.com. Since the request URI
is rewritten by proxies, some means is needed to convey the identity
of the original desired recipient. Thus, the sender also places the
URL for the desired recipient in the mandatory To field. The From
field identifies the originator of the message. The message must also
contain a Call-ID. In SIP, the Call-ID is used to associate a group
of requests with the same session. Here, the usage is the same; the
session in this case is initiated by a SUBSCRIBE. All SUBSCRIBE
messages that refresh the subscription, and all NOTIFY messages
generated for that subscription, are part of the same session, and
thus share the same Call-ID value. Call-ID has no meaning beyond
being a common identifier.
Each SUBSCRIBE also carries a CSeq, which is a sequence number plus
the name of the method of the request (the method name is there to
support SIP features not required for presence). The CSeq uniquely
identifies each SUBSCRIBE and NOTIFY in the session, and increases
for each subsequent request in the same direction. Each SIP request
also carries a Via header. Via headers contain a trace of the IP
addresses or FQDNs of the systems that the request traversed. As a
request travels from proxy to proxy towards the recipient, each adds
its address, "pushing" them into a header, much like the operation of
a stack. The stack of addresses is reflected in the response, and
each proxy "pops" the top address off, and uses that to determine
where to send the response. This allows proxies to forward UDP
requests statelessly, so that they need not even remember where the
request came from to forward the response. Finally, clients using
this extension MUST insert a Contact header into the request (Contact
is used for routing of requests in the reverse direction, from the
target of the original message to the initiator of the original
message).
The SUBSCRIBE request MAY contain a body. The body contains
additional information that describes the subscription. SIP uses the
standard MIME headers (Content-Type, Content-Length, and Content-
Encoding) to identify the content.
An example subscription request looks like:
SUBSCRIBE sip:jdrosen@dynamicsoft.com SIP/2.0
Via: SIP/2.0/UDP userpc.example.com
To: sip:jdrosen@dynamicsoft.com
From: sip:user@example.com
Contact: sip:user@userpc.example.com
Call-ID: knsd08alas9dy@3.4.5.6
CSeq: 1 SUBSCRIBE
Content-Length: 0
The request MAY be sent using UDP or TCP (SIP supports both UDP and
TCP (and even SCTP [6] transport; reliability is guaranteed over UDP
and congestion control is provided through a simple retransmission
scheme with exponential backoff).
The request MAY be sent to a local outbound proxy (a local outbound
proxy is a device similar to an http proxy; it receives requests
which are not destined for itself, and then forwards them towards the
final destination), or MAY be sent directly to the server in the
domain specified in the request URI. This is identical to baseline
SIP. Local outbound proxies are RECOMMENDED in order to provide
domain-based third party signatures (i.e., resign the request with a
key for the entire domain). These proxies SHOULD perform proxy
authentication, verifying the identity of the originator, before
resigning.
Proxies forward the message according to configured routing logic
combined with DNS SRV record procedures. Pre-established security
associations MAY be used, or SAs MAY be established on demand. The
SAs themselves SHOULD be based on IPSec ESP in transport mode [7] to
provide privacy services for instant messages. Keys for ESP MAY be
established administratively. If administrative keys are not
available, IKE is used for key exchange [8]. If a proxy receives a
request that does not arrive over a SA, it MAY reject the request.
This decision is based on the local security policy of the proxy.
Each proxy adds its address to the Via header as it forwards the
request. Proxies MAY also record route; this means that they can
request to receive all subsequent messages for the same Call-ID. By
not record-routing, proxies will see only the initial request they
forward; all subsequent requests in the same session will bypass the
proxy, and go on a more direct path between the end systems. Record-
routing is done by inserting a header into the forwarded request
(called Record-Route) which contains the address of the proxy. Like
the Via headers, Record-Route has a "stack" property, since proxies
"push" values into the message. The entire Record-Route stack is
reflected in the response to the SUBCRIBE, but unlike Via, no
addresses are "popped" in the response. In this fashion, both sender
and recipient of the SUBSCRIBE have a list of the message path for
subsequent requests. This path list is built into a Route header by
the end systems, and placed in subsequent requests. The Route header
is like a loose source route in IP, and specifies the path that the
request should take. Record-routing gives each proxy the capability
to independently decide the right trade off of scale (achieved by not
record routing) and services (generally achieved by record routing).
Proxies which are aware that they are behind a firewall, for example,
can record-route, ensuring that messages from inside to outside
always come from the proxy.
Eventually, the SUBSCRIBE request is forwarded to a proxy which is
co-located with a registrar. A registrar is an entity in SIP that has
dynamic application layer routing information. When a client starts
up, they send the registrar a REGISTER request that binds an address
in the domain of the registrar to the address of the machine they are
residing on. Continuing with the example above, the proxy for
engineering.example.com receives the request for Joe. Joe had
formerly registered a binding from sip:joe@engineering.example.com to
sip:joe@mypc.engineering.example.com, which contains the FQDN of the
host Joe is using. In fact, the binding established by a REGISTER can
be one to many, so that a user can indicate the ability to be
contacted at multiple hosts (laptop, PDA, cell phone). This
information is fundamentally presence. For that reason, the
proxy/registrar can elect to act as a PA for this subscription. A
proxy/registrar which can act as a PA is known as a presence server.
Before accepting the subscription, the presence server will generally
need to obtain authorization from the principal. This extension does
not specify how the presence server would obtain authorization from
the principal. Authorization can be provided ahead of time through
web configuration, for example. Another approach is to obtain
authorization at the time of the subscription. One approach for such
authorization is defined in a separate document [9]. If authorization
cannot be obtained at the time of subscription, the presence server
can return a 202 (Accepted) response, which indicates that the
subscription might have been accepted. When authorization is finally
obtained (because the principal becomes online and is queried once
again for authorization), the presence server can then enable the
subscription and begin generation of notifications for it.
Instead of acting as a PA, the presence server can act as a proxy for
a subscription, and forward it to a presence client. A presence
client makes itself known to the presence server by registering
(using SIP REGISTER) a Contact address that includes the methods tag
of "SUBSCRIBE". The tag is defined in the caller preferences
specification [3]. This specification allows, among other things, for
clients to indicate in a REGISTER that they would prefer to receive
messages with specific methods. Proxies receiving requests with a
particular method forward it to the contact address which has
indicated it can handle that method. This allows for a user with a
single SIP address to use separate user agents for presence and for
other communications. Alternatively, users can use the same user
agents for both.
An example registration using this tag looks like:
REGISTER sip:dynamicsoft.com SIP/2.0
Via: SIP/2.0/UDP mypc.dynamicsoft.com
To: sip:jdrosen@dynamicsoft.com
From: sip:jdrosen@dynamicsoft.com
Call-ID: asidhasd@1.2.3.4
CSeq: 39 REGISTER
Contact: sip:jdrosen@pua-pc.dynamicsoft.com;methods="SUBSCRIBE"
Contact: http://www.cs.columbia.edu/~jdrosen
Content-Length: 0
One of the Contact headers contains the SUBSCRIBE value in the
methods tag. The presence server can therefore forward the request to
that address. If there are no registrations with the methods tag of
"SUBSCRIBE", there are no presence clients, and the presence server
SHOULD assume the role of PA.
In fact, it is possible that two different presence clients register
for the same presentity. In this case, the presence server, acting as
a proxy, may fork the SUBSCRIBE, which means it sends multiple copies
of the request, one to each presence client. Each client will
presumably query its principal about whether the subscription is
acceptable. In the common case where a principal has left their
presence tool running at work, and then gone home and started the
tool there, the principal will accept the subscription at home. This
causes a success response to be generated, and forwarded to the
presence server (which is acting as a proxy), and then back to the
subscriber. The presence tool at home then assumes responsibility for
that subsription. The tool at work can continue to support
subscriptions it received previously.
Independently of whether the PA resides in the presence server or
presence client, if a SUBSCRIBE request arrives and is acceptable, a
200 OK response is generated, and the PA stores state for the
subscription. The 200 OK response contains a copy of the current
presence state of the presentity. The 200 OK response to the
SUBSCRIBE listed above might look like:
SIP/2.0 200 OK
Via: SIP/2.0/UDP presenceserver.dynamicsoft.com
Via: SIP/2.0/UDP userpc.example.com
To: sip:jdrosen@dynamicsoft.com
From: sip:user@example.com
Contact: sip:user@userpc.example.com
Record-Route: sip:jdrosen@example.com;maddr=presenceserver.dynamicsoft.com
Expires: 3600
Call-ID: knsd08alas9dy@3.4.5.6
CSeq: 1 SUBSCRIBE
Content-Type: application/xpidf+xml
Content-Length: 287
<?xml version="1.0"?>
<!DOCTYPE presence
PUBLIC "-//IETF//DTD RFCxxxx XPIDF 1.0//EN" "xpidf.dtd">
<presence>
<presentity uri="sip:jdrosen@dynamicsoft.com;method="SUBSCRIBE">
<atom id="779js0a98">
<address uri="sip:jdrosen@dynamicsoft.com;method=INVITE">
<status status="open"/>
</address>
</atom>
</presentity>
</presence>
Notice that the response has mirrored many fields from the request,
including the To, From, Call-ID, CSeq, and Via headers. The PA has
also added a Contact header, providing an address where it can be
reached. The response also contains a Record-Route header. This
header was presumably inserted by the proxy (the address in the maddr
header is that of a presence server acting as a proxy), and is
reflected in the 200 OK response. The response also contains a
presence document for the presentity, and a Contact header. The
Contact headers in a response to SUBSCRIBE list all the current
addresses which have been subscribed.
A subscription is uniquely defined by the combination of the Call-ID,
To, and From header fields in the SUBSCRIBE. Subscriptions are soft-
state; they must be refreshed periodically by the subscriber in order
to remain active. The Expires header in the 200 OK response is used
to indicate the lifetime of the subscription; the subscriber must
resend the subscription before then, or it is deleted from the PA.
When the presence information for the presentity changes, the PA
generates a NOTIFY request for each subscriber. Recall that a PA is
assumed to know about all changes in the presence information for a
presentity; it will know this either because it is co-located with
the PUA, otherwise it is co-located with the registrar, and will
learn about changes in presence information from REGISTER requests.
The NOTIFY request is routed using the Record-Route and Contact
headers obtained from the subscription, as is done in baseline SIP.
For example, the PA will generate a NOTIFY that looks like this:
NOTIFY sip:user@userpc.example.com
Via: SIP/2.0/UDP pua-pc.dynamicsoft.com
To: sip:user@example.com
From: sip:jdrosen@dynamicsoft.com
Contact: sip:jdrosen@pua-pc.dynamicsoft.com
Route: sip:user@userpc.example.com;maddr=userpc.example.com
Call-ID: knsd08alas9dy@3.4.5.6
CSeq: 1 NOTIFY
Content-Type: application/xpidf+xml
Content-Length: 290
<?xml version="1.0"?>
<!DOCTYPE presence
PUBLIC "-//IETF//DTD RFCxxxx XPIDF 1.0//EN" "xpidf.dtd">
<presence>
<presentity uri="sip:jdrosen@dynamicsoft.com;method="SUBSCRIBE">
<atom id="779js0a98">
<address uri="sip:jdrosen@dynamicsoft.com;method=INVITE">
<status status="closed"/>
</address>
</atom>
</presentity>
</presence>
This NOTIFY is sent to the presence server
(presenceserver.dynamicsoft.com) because of the maddr parameter in
the Record-Route. The presence server receives this, and sees the
Route header. It removes the Route header, places the URI
sip:user@userpc.example.com into the Request URI, and sends it to the
IP address corresponding to the maddr parameter, in this case, also
userpc.example.com. In this way, the NOTIFY takes the same path as
the SUBSCRIBE took.
As an optimization, notifications do not need to be sent if the
subscriber is not actually online. This improves scalability.
When a client wishes to fetch the current communications state of a
user, it generates a SUBSCRIBE request, with an Expires header with
time 0 (that is, a subscription which immediately expires). Once it
hits the PA, a 200 OK response is generated (assuming authorization
exists) containing the current presence state. The subscription is
then immediately expired. The result is a fetch of presence
information without generation of a subscription. Note that since
fetch is accomplished using SUBSCRIBE, the same security mechanisms
and authorization requirements are used for both.
5 Subscriptions
This section defines detailed syntax and semantics associated with
subscriptions.
5.1 Generating subscriptions
Subscription is accomplished using the new SUBSCRIBE method, defined
below.
Subscribe = "SUBSCRIBE"
Like all SIP method names, the SUBSCRIBE method name is case
sensitive. SUBSCRIBE is used when a subscriber wishes to receive
asynchronous notifications about events generated by some object.
These events can be changes in the state of the object, or any other
type of event. The address of the object is placed by the subscriber
in the To header and also the request URI. The body of the SUBSCRIBE
method MAY contain information to limit the set of events for which
notifications are sent, or otherwise provide modifiers to the
subscription. If no body is present, all events generated by the
object cause notifications.
In its application to presence of people, the object is actually a
presentity, and its address is the SIP URL for the presentity.
Tables 1 and 2 extend tables 4 and 5 of SIP with two additional
columns, defining the headers that can be used in the SUBSCRIBE and
NOTIFY requests and responses.
Subscriptions are soft-state, and must be periodically refreshed. The
refresh interval is suggested by the client in the SUBSCRIBE request
(using the Expires header) and the actual value returned in the
SUBSCRIBE response in the Expires header; see Section 6.20 of SIP. If
no value is present, the default is one hour. The response to the
subscription MUST contain an Expires header indicating the actual
expiration of the subscription. This time will never be later than
the time offered in the request, if it is offered. The subscription
SHOULD be refreshed before this expiration of the client still
desires the subscription to be valid.
A SUBSCRIBE request MUST contain a To header, identifying the logical
identity of the user or object who is being subcribed to (i.e., the
where enc. e-e SUBSCRIBE NOTIFY
___________________________________________________
Accept R e o o
Accept 415 e o o
Accept-Encoding R e o o
Accept-Encoding 415 e o o
Accept-Language R e o o
Accept-Language 415 e o o
Allow 200 e o o
Allow 405 e m m
Authorization R e o o
Authorization r e o o
Call-ID gc n e m m
Contact R e m o
Contact 2xx e m o
Contact 3xx e o o
Contact 485 e o o
Content-Encoding e e o o
Content-Length e e m m
Content-Type e e * *
CSeq gc n e m m
Date g e o o
Encryption g n e o o
Expires g e o o
From gc n e m m
Hide R n h o o
Max-Forwards R n e o o
Organization g c h o o
Table 1: Summary of header fields, A--O
address of the presentity).
A SUBSCRIBE request, of course, MUST contain a Request-URI. For
requests generated by a UAC, this SHOULD be identical to the To
field. As the SUBSCRIBE request traverses proxy servers, the
Request-URI is rewritten to the address of the subscribed-to entity
as known in the next-hop server.
A SUBSCRIBE request MUST contain a Call-ID header (simply an opaque
identifier) and a From header. The From header contains logical
identity of the user requesting the subscription. Generally, this is
a SIP URL, although it need not be. Note that as a logical
identifier, it will generally not contain a complete hostname, such
as sip:user@pc10.engineering.example.com, but rather contain a
logical name, such as sip:user@example.com.
where enc. e-e SUB NOTIFY
__________________________________________________________
Priority R c e - -
Proxy-Authenticate 407 n h o o
Proxy-Authorization R n h o o
Proxy-Require R n h o o
Record-Route R h o o
Record-Route 2xx,401,484 h o o
Require R e o o
Retry-After R c e - -
Retry-After 404,413,480,486 c e o o
500,503 c e o o
600,603 c e o o
Response-Key R c e o o
Route R h o o
Server r c e o o
Subject R c e - -
Timestamp g e o o
To gc(1) n e m m
Unsupported 420 e o o
User-Agent g c e o o
Via gc(2) n e m m
Warning r e o o
WWW-Authenticate R c e o o
WWW-Authenticate 401 c e o o
Table 2: Summary of header fields, P--Z; (1): copied with possible When an entity, the subscriber, wishes to learn about presence
addition of tag; (2): UAS removes first Via header field information from some user, it creates a SUBSCRIBE request. This
request identifies the desired presentity in the request URI, using
either a presence URL or a SIP URL. The subscription is carried along
SIP proxies as any other INVITE would be. It eventually arrives at a
presence server, which can either terminate the subscription (in
which case it acts as the presence agent for the presentity), or
proxy it on to a presence client. If the presence client handles the
subscription, it is effectively acting as the presence agent for the
presentity. The decision about whether to proxy or terminate the
SUBSCRIBE is a local matter; however, we describe one way to effect
such a configuration, using REGISTER.
A subscription is uniquely identified by the combination of the To, The presence agent (whether in the presence server or presence
Call-ID and the From field in the SUBSCRIBE request. Refreshes of client) first authenticates the subscription, then authorizes it. The
subscriptions SHOULD reuse the same Call-ID if possible, since means for authorization are outside the scope of this protocol, and
subscriptions are uniquely identified at presence servers using the we expect that many mechanisms will be used. Once authorized, the
Call-ID. Two subscriptions from the same user, for the same user, but presence agent sends a 202 Accepted response. It also sends an
with different Call-IDs, are considered different subscriptions. We immediate NOTIFY message containing the state of the presentity. As
anticipate that reuse of the same Call-ID will not be possible the state of the presentity changes, the PA generates NOTIFYs for all
through reboot cycles. This is acceptable, however. The soft-state subscribers.
nature of subscriptions will cause the old one to expire. Note this
is exactly the same as usage of Call-ID in registrations.
A SUBSCRIBE request MUST contain a CSeq header. As specified in [2], The SUBSCRIBE message effectively establishes a session with the
The CSeq header MUST increment for each subsequent request for the presence agent. As a result, the SUBSCRIBE can be record-routed, and
same To, From, and Call-ID field (thus, the CSeq in each refresh MUST rules for tag handling and Contact processing mirror those for
increase). The CSeq header uniquely identifies and orders each INVITE. Similarly, the NOTIFY message is handled in much the same way
refresh of a particular subscription. a re-INVITE within a call leg is handled.
A SUBSCRIBE request MUST contain a Via header, formatted as defined 4 Naming
in RFC 2543 [2]. Via headers are used to properly forward the
response to the SUBSCRIBE.
A SUBSCRIBE request MUST contain a Contact header. This indicates the A presentity is identified in the most general way through a presence
address(es) (as a SIP URL) to which the client would like to receive URI [4], which is of the form pres:user@domain. These URIs are
notifications. This MUST be be one or more SIP addresses, containing protocol independent. Through a variety of means, these URIs can be
the fully qualified domain names for the host generating the resolved to determine a specific protocol that can be used to access
subscription, or the IP address of the host generating the the presentity. Once such a resolution has taken place, the
subscription. Other addresses are possible, supporting third party presentity can be addressed with a sip URL of nearly identical form:
subscriptions. If it contains multiple addresses, notifications will sip:user@domain. The protocol independent form (the pres: URL) can be
be sent to each address. If no Contact header is present, no thought of as an abstract name, akin to a URN, which is used to
notifications will be sent. identify elements in a presence system. These are resolved to
concrete URLs that can be used to directly locate those entities on
the network.
The SUBSCRIBE request MAY contain a body, and when present, the When subscribing to a presentity, the subscription can be addressed
Content-Length, Content-Type, and Content-Encoding are used as using the protocol independent form or the sip URL form. In the SIP
specified in [2]. There are many applications for bodies within a context, "addressed" refers to the request URI. It is RECOMMENDED
SUBSCRIBE request - for example, providing more detailed information that if the entity sending a SUBSCRIBE is capable of resolving the
about what the subscription is for. Derivation of semantics of the protocol independent form to the SIP form, this resolution is done
purpose of the body is based on the Content-Type and Content- before sending the request. However, if the entity is incapable of
Disposition headers. doing this translation, the protocol independent form is used in the
request URI. Performing the translation as early as possible means
that these requests can be routed by SIP proxies that are not aware
of the presence namespace.
A SUBSCRIBE request MAY contain an Accept header, indicating the The result of this naming scheme is that a SUBSCRIBE request is
allowed presence description formats which may be returned in a addressed to a user the exact same way an INVITE request would be
notification. When not present, the server assumes only the addressed. This means that the SIP network will route these messages
lightweight presence format [10] is supported. along the same path an INVITE would travel. One of these entities
along the path may act as a PA for the subscription. Typically, this
will either be the presence server (which is the proxy/registrar
where that user is registered), or the presence client (which is one
of the user agents associated with that presentity).
This extension does NOT neccessitate the use of either Require or SUBSCRIBE messages also contain logical identifiers that define the
Proxy-Require. These headers SHOULD NOT be present unless some other originator and recipient of the subscription (the To and From header
extensions are needed beyond this one. fields). Since these identifiers are logical ones, it is RECOMMENDED
that these use the protocol independent format whenever possible.
This also makes it easier to interwork with other systems which
recognize these forms.
Usage of the other headers specified as optional in Tables 1 and 2 is The Contact, Record-Route and Route fields do not identify logical
defined in [2]. entities, but rather concrete ones used for SIP messaging. As such,
they MUST use the SIP URL forms in both SUBSCRIBE and NOTIFY.
5.2 Sending subscriptions 5 Presence Event Package
The SUBSCRIBE request MAY be sent directly to the server identified The SIP event framework [3] defines an abstract SIP extension for
in the Request URI. Alternatively, it can be sent to a local outbound subscribing to, and receiving notifications of, events. It leaves the
proxy server. Usage of local outbound proxies is RECOMMENDED with definition of many additional aspects of these events to concrete
presence in order to provide security features. extensions, also known as event packages. This extension qualifies as
an event package. This section fills in the information required by
[3].
An example subscription message looks like: 5.1 Package Name
SUBSCRIBE sip:user@example.com SIP/2.0 The name of this package is "presence". This name MUST appear within
Via: SIP/2.0/UDP myhost.example.com the Event header in SUBSCRIBE request and NOTIFY request. This
From: Professor Smith <sip:professor@university.edu> section also serves as the IANA registration for the event package
To: Joe User <sip:user@example.com> "presence".
Contact: sip:professor@mypc.university.edu
Call-ID: 986sdo909y66555@12.33.4.5
CSeq: 4937872 SUBSCRIBE
Accept: text/uri-list, text/xml-presence
5.3 Proxying subscriptions TODO: Define IANA template in sub-notify and fill it in here.
Proxies forward SUBSCRIBE requests as they would any other request. Example:
The result is that the SUBSCRIBE eventually arrives at a server where
the user is registered. Section 5.4 outlines processing in these
servers.
5.4 Presence server processing of SUBSCRIBE Event: presence
This section outlines the processing of a new subscription request 5.2 SUBSCRIBE bodies
for a presentity served by a presence server.
When a SUBSCRIBE request arrives, the presence server SHOULD send a The body of a SUBSCRIBE request MAY contain a body. The purpose of
100 Trying response. the body depends on its type. In general, subscriptions will normally
not contain bodies. The request URI, which identifies the presentity,
combined with the event package name, are sufficient for user
presence.
The next job of the presence server is to determine if it will act as We anticipate that document formats could be defined to act as
a proxy for this subscription, or as a PA. Once this determination is filters for subscriptions. These filters would indicate certain user
made, processing follows Section 5.3 in the case of a proxy, and presence events that would generate notifies, or restrict the set of
Section 5.5 in the case of a PA. data returned in NOTIFY requests. For example, a presence filter
might specify that the notifications should only be generated when
the status of the users instant message inbox changes. It might also
say that the content of these notifications should only contain the
IM related information.
If the presentity identified in the request URI has at least one 5.3 Expiration
registered Contact that indicates support of the SUBSCRIBE method, User presence changes as a result of events that include:
the presence server MAY proxy the request, or MAY act as a PA. If no
Contacts are registered for the presentity, or if there are Contacts,
but none indicate support for the SUBSCRIBE method, the presence
server SHOULD assume the role of PA.
If there was more than one Contact which indicated support of the o Turning on and off of a cell phone
SUBSCRIBE method, the proxy MAY fork the request (that is, send the
subscription to more than one PA). Standard SIP processing, as
defined in Section 12.4 of RFC2543 [2], is used to collect responses
and send a single response upstream, towards the subscriber.
Basically, the algorithm specified will result in a 200 OK being
forwarded upstream if any of the presence clients responded with a
200 OK. If more than one presence client responded with a 200 OK,
only one of them is forwarded upstream. Note that this may cause
multiple PAs to generate notifications for the same presentity. This
is acceptable; each PA is generating the same information. The
redundant information is discarded at the subscriber [11].
If the presence server was formerly acting as a PA for a subscription o Modifying the registration from a softphone
(in other words, the presence server was a PA for a subscription with
the same Call-ID, To, and From field, but different CSeq), but is now
a proxy, the presence server MUST cease acting as PA for this
subscription if the proxied request generates a final response,
unless that final response is 405 (Method not Allowed) (which means
the presence client isn't actually a presence client, since it
doesn't support SUBSCRIBE).
It is possible for the role of PA to migrate from presence server to o Changing the status on an instant messaging tool
presence client dynamically. Consider first the case of a presence
server acting as a PA, because there were no presence clients
available. At some point, the presence client comes online (known to
the presence server through a registration). When the subscription is
next refreshed, the presence server can act as a proxy instead of a
PA, and forward the subscription to the presence client. This
terminates the subscription on the server, and allows it to become
active on the presence client. By transferring subscriptions on
refreshes, handling of subscriptions to gradually transition from a
presence server to a presence client.
The role of presence server migrates back in much the same way. When These events are usually triggered by human intervention, and occur
the presence client goes offline (by unregistering the Contact with a frequency on the order of minutes or hours. As such, it is
address with the methods="SUBSCRIBE" tag), subscription refreshes subscriptions should have an expiration in the middle of this range,
will now terminate at the presence server, causing the presence which is roughly one hour. Therefore, the default expiration time for
server to act as a PA for those subscriptions. This will cause the subscriptions within this package is 3600 seconds. As per [3], the
subscriptions to gradually become active at the presence server. subscriber MAY include an alternate expiration time. Whatever the
indicated expiration time, the server MAY reduce it but MUST NOT
increase it.
As an optimization, the presence server can cache the active 5.4 NOTIFY Bodies
subscriptions at the client. This is done by observing the SUBSCRIBE
requests, and the 200 OK responses, which pass by the presence server
(which is acting as a proxy). When the presence client goes offline,
the presence server can simply instantiate the cached subscriptions
immediately. Note that caching of subscriptions imposes a security
risk unless the presence server can authenticate and verify the
integrity of SUBSCRIBE requests and their responses.
5.5 Presence agent processing of SUBSCRIBE The body of the notification contains a presence document. This
document describes the user presence of the presentity that was
subscribed to. All subscribers MUST support the presence data format
described in [fill in with IMPP document TBD], and MUST list its MIME
type, [fill in with MIME type] in an Accept header present in the
SUBSCRIBE request.
The presence agent MAY authenticate the request (using a 401 Other presence data formats might be defined in the future. In that
response, NOT 407, since the PA is a user agent in SIP terminology). case, the subscriptions MAY indicate support for other presence
formats. However, they MUST always support and list [fill in with
MIME type of IMPP presence document] as an allowed format.
Once authenticated, the PA determines if this is a subscription Of course, the notifications generated by the presence agent MUST be
refresh, or a new subscription. If the Call-ID, To, and From field in one of the formats specified in the Accept header in the SUBSCRIBE
match that of an existing subscription, the subscription is a request.
refresh. Otherwise, it is a new subscription.
5.5.1 Refreshes 5.5 Processing Requirements at the PA
A PA MAY reject a refresh if it determines that the subscription is
no longer acceptable (for example, if the subscription was permitted
on a timed basis). In this case, the subscription is removed from the
system, and a 6xx class response is sent. Note that a 4xx or 5xx
error response MUST NOT cause the subscription to be removed from the
system.
The remainder of the discussion on refreshes assumes that the User presence is highly sensitive information. Because the
subscription is still acceptable. implications of divulging presence information can be severe, strong
requirements are imposed on the PA regarding subscription processing,
especially related to authentication and authorization.
Each notification address (as indicated in the Contact header), is A presence agent MUST authenticate all subscription requests. This
independently refreshed. This allows different expiration times for authentication can be done using any of the mechanisms defined for
different notification addresses. Differing expiration times can be SIP. It is not considered sufficient for the authentication to be
indicated using the expires parameter of the Contact header, just as transitive; that is, the authentication SHOULD use an end-to-end
is done for registrations [2]. mechanism. The SIP basic authentication mechanism MUST NOT be used.
When a presence agent receives a subscription refresh, it updates the It is RECOMMENDED that any subscriptions that are not authenticated
expiration time of each notification address in the subscription. As do not cause state to be established in the PA. This can be
with the initial subscription, the server MAY lower the amount of accomplished by generating a 401 in response to the SUBSCRIBE, and
time until expiration, but MUST NOT increase it. The final expiration then discarding all state for that transaction. Retransmissions of
time is placed in the Expires header in the response, or into the the SUBSCRIBE generate the same response, guaranteeing reliability
expires parameters of the Contact headers in the response. The 200 OK even over UDP.
response SHOULD also contain a copy of the current presence state of
the presentity, in a format listed in the Accept header of the
SUBSCRIBE, else the Light Presence Information Data Format (LPIDF)
[10] if no Accept header is present. If the Accept header was present
but empty, no presence information is placed in the response.
If no refresh for a notification address is received before its Furthermore, a PA MUST NOT accept a subscription unless authorization
expiration time, that address is removed from the list of addresses. has been provided by the presentity. The means by which authorization
If all notification addresses are removed, the entire subscription is are provided are outside the scope of this document. Authorization
deleted. may have been provided ahead of time through access lists, perhaps
specified in a web page. Authorization may have been provided by
means of uploading of some kind of standardized access control list
document. Back end authorization servers, such as a DIAMETER [5],
RADIUS [6], or COPS [7], can also be used. It is also useful to be
able to query the user for authorization following the receipt of a
subscription request for which no authorization information was
present. Appendix A provides a possible solution for such a scenario.
5.5.2 New subscriptions The result of the authorization decision by the server will be
reject, accept, or pending. Pending occurs when the server cannot
obtain authorization at this time, and may be able to do so at a
later time, when the presentity becomes available.
The presence server first determines if the subscriber is authorized. Unfortunately, if the server informs the subscriber that the
How such authorization is determined is outside the scope of this subscription is pending, this will divulge information about the
document. Authorizations may have been pre-granted by the presentity presentity - namely, that they have not granted authorization and are
or the system administrator. Alternatively, when the subscription not available to give it at this time. Therefore, a PA SHOULD
arrives, the PA may query the user to determine if authorization is generate the same response for both pending and accepted
permitted. Such querying is straightforward in the case of a PA co- subscriptions. This response SHOULD be a 202 Accepted response.
resident with a PUA (in which case a screen pop or something else can
be used). In the case of a PA co-resident with a proxy/registrar, a
remote authorization protocol, such as [9], or even the Common Open
Policy Service (COPS) [12] can be used.
If authorization was refused, the request SHOULD be rejected with a If the server informs the subscriber that the subscription is
600 class response. If authorization could not be obtained (for rejected, this also divulges information about the presentity -
example, because the principal was offline or not available), the PA namely, that they have explicitly blocked the subscription
SHOULD generate a 202 response. This response tells the subscriber previously, or are available at this time and chose to decline the
that the subscription is pending. The PA may reattempt authorization subscription. If the policy of the server is not to divulge this
at a later time, possibly when the principal comes back online. See information, the PA MAY respond with a 202 Accepted response even
[9], which describes a SIP extension that can be used for though the subscription is rejected. Alternatively, if the policy of
authorization of users. The subscriber SHOULD refresh the the presentity or the PA is that it is acceptable to inform the
subscription as per a 200 response. The subscriber knows the subscriber of the rejection, a 603 Decline SHOULD be used.
subscription is accepted when either (1) a NOTIFY for that
subscription appears, or (2) a refresh generates a 200 response.
If authorization has been granted, the PA MUST respond to SUBSCRIBE Note that since the response to a subscription does not contain any
with a 200 OK response. The response MUST contain an indication of useful information about the presentity, privacy and integrity of
expiration time for each notification address in the SUBSCRIBE. The SUBSCRIBE responses is not deemed important.
200 OK response SHOULD also contain a copy of the current presence
state of the presentity, in a format listed in the Accept header of
the SUBSCRIBE, else the Light Presence Information data Format
(LPIDF) [10] if no Accept header is present. If the Accept header was
present but empty, no presence information is placed in the response.
The PA MAY sign the 200 OK response. 5.6 Generation of Notifications
The PA also instantiates a subscription for the subscriber. The Upon acceptance of a subscription, the PA SHOULD generate an
subscription is indexed by the Call-ID in the SUBSCRIBE and the URI immediate NOTIFY with the current presence state of the presentity.
in the From field (including the tag). The PA generates Route headers
(using the Contact and Record-Route headers from the request) to be
used for sending notifications. These Route headers are constructed
exactly as if the SUBSCRIBE request were an INVITE. The Route headers
are stored for use in subsequent notifications.
5.6 Subscriber processing of SUBSCRIBE response If a subscription is received, and is marked as pending or was
rejected, the PA SHOULD generate an immediate NOTIFY. This NOTIFY
should contain a valid state for the presentity, yet be one which
provides no useful information about the presentity. An example of
this is to provide an IM URL that is the same form as the presence
URL, and mark that IM address as "not available". The reason for this
process of "lying" is that without it, a subscriber could tell the
difference between a pending subscription and an accepted
subscription based on the existence and content of an immediate
NOTIFY. The approach defined here ensures that the presence delivered
in a NOTIFY generated by a pending or rejected subscription is also a
valid one that could have been delivered in a NOTIFY generated by an
accepted subscription.
The subscriber will receive a single final response to the SUBSCRIBE If the policy of the presence server or the presentity is that it is
request. If this response is a 600 class response, the subscription acceptable to divulge information about whether the subscription
request has been denied. If the response is a 200 class response, the succeeded or not, the immediate NOTIFY need not be sent for pending
subscription has been accepted. The response may contain the current or rejected subscriptions.
presence state of the presentity. The 200 OK response will contain
expiration information (either in an Expires header, and/or in the
expires parameter of Contact headers in the 200 OK response)
indicating when the subscription expires. The subscriber MUST refresh
the subscription before an expiration time if it wishes to continue
to receive notifications to the address with that expiration. The
SUBSCRIBE response will also contain Record-Route headers; these are
used to build a Route header set for use in subsequent subscription
refreshes. The construction of the Route headers follows those for a
200 OK response to INVITE as documented in RFC2543 [2], except that
Contact headers are not included in the processing.
SUBSCRIBE is like REGISTER, in that the Contact headers Of course, once a subscription is accepted, the PA SHOULD generate a
don't refer to signaling addresses, but rather notification NOTIFY for the subscription when it determines that the presence
addresses. Unlike REGISTER, a Route needs to be built for state of the presentity has changed. Section 6 describes how the PA
SUBSCRIBE, and this Route should not include the Contact makes this determination.
headers.
To refresh the subscription, the subscriber contructs a new SUBSCRIBE For reasons of privacy, it will frequently be necessary to encrypt
request. The Call-ID, To, and From in this request MUST match those the contents of the notifications. This can be accomplished using the
of the previous SUBSCRIBE request. The CSeq header MUST be higher standard SIP encryption mechanisms. The encryption should be
than that of the previous SUBSCRIBE request. The Via header is performed using the key of the subscriber as identified in the From
constructed as described in 5.2. The request MUST contain the Route field of the SUBSCRIBE. Similarly, integrity of the notifications is
header constructed from the response to the initial SUBSCRIBE. The important to subscribers. As such, the contents of the notifications
request MAY contain Accept, Content-Length, Content-Type, and SHOULD be authenticated using one of the standardized SIP mechanisms.
Content-Encoding headers as described in Section 5.2. The request URI Since the NOTIFY are generated by the presence server, which may not
is constructed from the Route headers, as defined in RFC2543 [2]. The have access to the key of the user represented by the presentity, it
request is then sent to the server in the request URI. will frequently be the case that the NOTIFY are signed by a third
party. It is RECOMMENDED that the signature be by an authority over
domain of the presentity. In other words, for a user
pres:user@example.com, the signator of the NOTIFY SHOULD be the
authority for example.com.
As long as the subscription remains active, the subscriber will 5.7 Rate Limitations on NOTIFY
receive notifications of presence state from the PA.
5.7 Unsubscribing For reasons of congestion control, it is important that the rate of
notifications not become excessive. As a result, it is RECOMMENDED
that the PA not generate notifications for a single presentity at a
rate faster than once every 5 seconds.
A subscriber may unsubscribe by sending a SUBSCRIBE request with an 5.8 Refresh Behavior
Expires header of 0. The Contact header indicates the particular
address that is being unsubscribed. This MAY be a *, indicating that
all Contacts for that particular subscription (as identified by the
Call-ID, To, and From) are to be removed. If all Contacts are
removed, the PA deletes the subscription.
5.8 Fetching Since SUBSCRIBE is routed by proxies as any other method, it is
possible that a subscription might fork. The result is that it might
arrive at multiple devices which are configured to act as a PA for
the same presentity. Each of these will respond with a 202 response
to the SUBSCRIBE. Based on the forking rules in SIP, only one of
these responses is passed to the subscriber. However, the subscriber
will receive notifications from each of those PA which accepted the
subscriptions. The SIP event framework allows each package to define
the handling for this case.
Fetching is similar to a subscribing, in that it returns the current The processing in this case is identical to the way INVITE would be
presence state. However, no notifications are sent for future changes handled. The 202 Accepted to the SUBSCRIBE will result in the
in the presence state. Rather than inventing a new method for this, installation of subscription state in the subscriber. The
it is readily accomplished with a SUBSCRIBE along with an Expires: 0 subscription is associated with the To and From (both with tags) and
header and no Contact header. The absence of any Contact header is Call-ID from the 202. When notifications arrive, those from the PA's
what distinguishes it from the similar operation of unsubscribing. whose 202's were discarded in the forking proxy will not match the
The advantage of using SUBSCRIBE is that the server can simply subscription ID stored at the subscriber (the From tags will differ).
process the request independently of whether its a fetch or longer These SHOULD be responded to with a 481. This will disable the
lived subscription; the authorization and processing steps are subscriptions from those PA. Furthermore, when refreshing the
identical. The only difference is whether an actual subscription is subscription, the refresh SHOULD make use of the tags from the 202
instantiated for the user or not. and make use of any Contact or Record-Route headers in order to
deliver the SUBSCRIBE back to the same PA that sent the 202.
This parallels how fetching of registrations is done in SIP. Note The result of this is that a presentity can have multiple PAs active,
that fetching has no effect on existing subscriptions. but these should be homogeneous, so that each can generate the same
set of notifications for the presentity. Supporting heterogeneous
PAs, each of which generated notifications for a subset of the
presence data, is complex and difficult to manage. If such a feature
is needed, it can be accomplished with a B2BUA rather than through a
forking proxy.
6 Publication 6 Publication
Publication is the process by which presence information is uploaded
from the presence user agents to the presence agent. The information
uploaded through publications is the content used to formulate
presence documents distributed through notifications.
Publication can be done using any number of means, including
proprietary protocols. There are many cases where this is both
necessary and desirable.
However, we define a standard mechanism for publication of presence
information from a PUA to a presence server. This mechanism is
entirely based on the existing SIP registration and caller
preferences specifications [3]. Simply put, the Contact headers
placed in registrations are the presence information published by the
presence user agents. The caller preferences extension provides a
large set of parameters which can be used to provide additional
information, beyond location, which provided by SIP REGISTER.
Usage of REGISTER to publish presence information has several The user presence for a presentity can be obtained from any number of
important features: different ways. Baseline SIP defines a method that is used by all SIP
clients - the REGISTER method. This method allows a UA to inform a
o It supports communications means represented by any URL SIP network of its current communications addresses (ie., Contact
scheme, including HTTP and SMTP. addresses) . Furthermore, multiple UA can independently register
Contact addresses for the same SIP URL. These Contact addresses can
o It supports distributed presence information, whereby multiple be SIP URLs, or they can be any other valid URL.
PUAs can independently update state for different
communications addresses for the same presentity.
o It supports third party updates, so that one entity can update
presence state for another.
o Caller preferences allows for relative weights to be assigned
to the addresses.
o Caller preferences allows for arbitrary characteristics to be
assigned to the addresses.
o Caller preferences allows for descriptions to contain Using the register information for presence is straightforward. The
arbitrary text that can be used for notes. address of record in the REGISTER (the To field) identifies the
presentity. The Contact headers define communications addresses that
describe the state of the presentity. The use of the SIP caller
preferences extension [8] is RECOMMENDED for use with UAs that are
interested in presence. It provides additional information about the
Contact addresses that can be used to construct a richer presence
document. The "description" attribute of the Contact header is
explicitly defined here to be used as a free-form field that allows a
user to define the status of the presentity at that communications
address.
We also allow REGISTER requests to contain presence documents, so We also allow REGISTER requests to contain presence documents, so
that the PUAs can publish more complex information. that the PUAs can publish more complex information.
Note that we do not provide for locking mechanisms, which would allow Note that we do not provide for locking mechanisms, which would allow
a client to lock presence state, fetch it, and update it atomically. a client to lock presence state, fetch it, and update it atomically.
We believe that this is not neeeded for the majority of use cases, We believe that this is not neeeded for the majority of use cases,
and introduces substantial complexity. Most presence operations do and introduces substantial complexity. Most presence operations do
not require get-before-set, since the SIP register mechanism works in not require get-before-set, since the SIP register mechanism works in
such a way that data can be updated without a get. such a way that data can be updated without a get.
The application of registered contacts to presence increases the The application of registered contacts to presence increases the
requirements for authenticity. Therefore, REGISTER requests used by requirements for authenticity. Therefore, REGISTER requests used by
presence user agents SHOULD be authenticated using either SIP presence user agents SHOULD be authenticated using either SIP
authentication mechanisms, or a hop by hop mechanism. authentication mechanisms, or a hop by hop mechanism.
7 Notification To indicate presence for instant messaging, the UA MAY either
register contact addresses that are SIP URLs with the "methods"
Notification is the process of transmitting presence state to parameter set to indicate the method MESSAGE, or it MAY register an
subscribers. It is done by a PA. IM URL.
7.1 When to send TODO: This section needs work. Need to define a concrete example of
mapping a register to a presence document, once IMPP generates the
document format.
Notifications are sent when the state of the presentity changes, and 6.1 Migrating the PA Function
that state change is one for which a notification is desired.
Notifications SHOULD be sent in a timely fashion after the state has
changed. Description of the cases in which state changes should
trigger notifications is handled by subscription documents
transmitted in SUBSCRIBE requests. If no such document was present,
the PA SHOULD assume that all state changes are reported. Similarly,
the subscription document describes the subscribers preferences for
the detailed content present in the notification. The actual data
sent would be computed through the intersection requested content,
and the content authorized by the subscribed party in their access
controls. In the absense of a subscription document, it is assumed
that the subscriber wants all data.
As an important optimization, a PA MAY elect not to send a notify to It is important to realize that the PA function can be colocated with
a subscriber if it knows that the subscriber is not available to several elements:
receive notifications. This can be known by having the PA subscribe
to the subscriber. In particular, the ability to receive
notifications represents another piece of presence state which can be
uploaded in a REGISTER, and discovered through a SUBSCRIBE. For
example, if userA subscribes to userB, userA would include, in its
registrations, an address that indicates its ability to receive
NOTIFY requests:
REGISTER sip:example.com SIP/2.0 o It can be co-located with the proxy server handling
Via: SIP/2.0/UDP userApc.example.com registrations for the presentity. In this way, the PA knows
To: sip:userA@example.com the presence of the user through registrations.
From: sip:userA@example.com
Call-ID: 8ynllz9a6ajsda009@9.8.7.6
CSeq: 1 REGISTER
Contact: sip:userA@userApc.example.com;methods=NOTIFY
Content-Length: 0
If userB also subscribes to userA, userB would be aware of this
communications address for notifications. It could then match it
against the notification addresses in the subscription from userA,
and determine whether a notification address was currently active.
We anticipate that most subscriptions will be symmetric, that is, A o It can be co-located with a PUA for that presentity. In the
subscribes to B and B subscribes to A. In this case, no extra case of a single PUA per presentity, the PUA knows the state
subscriptions are required for this optimization. of the presentity by sheer nature of its co-location.
Note that this optimization is likely to work only when notifications o It can be co-located in any proxy along the call setup path.
are sent by clients. This is because presence servers are not likely That proxy can learn the presence state of the presentity by
to be privy to presence state of the subscribers. generating its own SUBSCRIBE in order to determine it. In this
case, the PA is effectively a B2BUA.
7.2 Formatting of NOTIFY Because of the soft-state nature of the subscriptions, it becomes
possible for the PA function to migrate during the lifetime of a
subscription. The most workable scenario is for the PA function to
migrate from the presence server to the PUA, and back.
The generation of notifications is relatively straightforward. The Consider a subscription that is installed in a presence server.
presence data is constructed based on rules outside of the scope of Assume for the moment that the presence server can determine that a
this document. Note that the entity generating a notification MUST downstream UA is capable of acting as a PA for the presentity. When a
use a presence format listed among those in the Accept header in the subscription refresh arrives, the PA destroys its subscription, and
SUBSCRIBE request. If not present, the Lightweight Presence then acts as a proxy for the subscription. The subscription is then
Information Data Format (LPIDF) [10] type is assumed. routed to the UA, where it can be accepted. The result is that the
subscription becomes installed in the PUA.
The NOTIFY MUST contain the same Call-ID as the SUBSCRIBE for which For this migration to work, the PUA MUST be prepared to accept
it is acting as a notification. The From field MUST match the To SUBSCRIBE requests which already contain tags in the To field.
field in the SUBSCRIBE, and the To field MUST match the From field in Furthermore, the PUA MUST insert a Contact header into the 202, and
the SUBSCRIBE. The From field MUST contain a tag, which allows for this header MUST be used by the subscriber to update the contact
notifications from presence server and PUA to be distinguished, as address for the subscription.
far as SIP transaction processing are concerned.
For SIP experts - this represents a slightly different TODO: Does this work? What about getting a Record-Route in place at
operation than for INVITE. When a user sends an INVITE, the PUA. This might only be possible for refreshes that don't use
they will receive a 200 OK with a tag. Requests in the Route or tags.
reverse direction then contain that tag, and that tag only,
in the From field. Here, the response to SUBSCRIBE may
contain a tag in the To field, and a NOTIFY will contain a
tag in the From field. However, the UA may receive NOTIFY
requests with tags in the From field that do not match the
tag in the 200 OK received to the initial SUBSCRIBE. This
is because only a single 200 OK is returned to a SUBSCRIBE
request, as opposed to multiple 200 OK for INVITE. Thus,
the UA MUST be prepared to receive NOTIFYs with many
different tags, each from a different PUA.
The CSeq MUST be formatted as described in SIP [2]. In particular, The presence server determines that a PUA is capable of supporting a
note that the CSeq space is different in the direction of notifier to PA function through the REGISTER message. Specifically, if a PUA
subscriber and subscriber to notifier, and is from a different space wishes to indicate support for the PA function, it SHOULD include a
for presence clients and presence servers. NOTIFY SHOULD NOT contain contact address in its registration with a caller preferences
a Contact header. "methods" parameter listing SUBSCRIBE.
If the SUBSCRIBE request contained Record-Route and/or Contact 7 Mapping to CPIM
headers, the Route header for NOTIFY is computed as per [2], as if
the SUBSCRIBE were an INVITE, and the NOTIFY were a BYE. The
request-URI is also computed as per [2].
NOTIFY requests SHOULD be authenticated, using any of the end to end This section defines how a SIP for presence messages are converted to
SIP authentication mechanisms. Note that the shared secret mechanisms CPIM, and how a CPIM messages are converted to SIP for presence. SIP
are likely to only work for presence client generated notifications, to CPIM conversion occurs when a SIP system sends a SUBSCRIBE request
since shared secrets will exist only between end users, not between that contains a pres URL or SIP URL that corresponds to a user in a
servers and end users. When presence servers are generating the domain that runs a different presence protocol. CPIM to SIP involves
notifications, public key based authentication is RECOMMENDED. the case where a user in a different protocol domain generates a
subscription that is destined for a user in a SIP domain.
7.3 Responding to NOTIFY Note that the process defined below requires that the gateway store
subscription state. This unfortunate result is due to the need to
remember the Call-ID, CSeq, and Route headers for subscriptions from
the SIP side, so that they can be inserted into the SIP NOTIFY
generated when a CPIM notification arrives.
The subscriber SHOULD be prepared to receive notifications from 7.1 SIP to CPIM
different sources for the same presentity. The mechanisms for
combining these notifications to the overall presentity state is
outside the scope of this document, but is described in [11].
If a NOTIFY is received by a UA for a subscription which does not SIP for presnce is converted to CPIM through a SIP to CPIM abstract
exist, the UA SHOULD respond with a 481 (Unknown Call Leg). It is gateway service, depicted in Figure 1.
RECOMMENDED that the UA also send a SUBSCRIBE method, with the To
field copied from the From of the NOTIFY, the From copied from the To
of the NOTIFY, Expires equal to zero, and Contact wildcarded (*).
This will request that the subscription which generated the unwanted
notification be removed.
If the NOTIFY is properly formed and desired, the UA MUST respond +-------------+
with a 200 OK. Notification responses will not normally contain | |
bodies. They MAY if the request contained an Accept header listing | SIP to CPIM|
acceptable bodies in the response. | Conversion |
| |
SIP | | CPIM
---------------> | | ---------------->
| |
| |
| |
| |
| |
| |
+-------------+
If the notification generates no final response at all, and times Figure 1: SIP to CPIM Conversion
out, or if the notification generates a 481 response, the entity
generating the notification should invalidate that notification
address in the subscription. If invalidation of the address results
in no notification addresses remaining in the subscription, the
entire subscription is deleted. This prevents notifications from
being generated to users that have gone offline, or to those users
who were mistakenly subscribed but have no presence client at all.
The soft state nature of subscriptions will ensure that valid
subscriptions will be refreshed if accidentally deleted.
8 Access controls The first step is that a SUBSCRIBE request is received at a gateway.
The gateway generates a CPIM subscription request, with its
parameters filled in as follows:
Access controls are mechanisms which allow the user controlling a o The watcher identity in the CPIM message is copied from the
presentity to define rules about who is allowed to subscribe, what From field of the SUBSCRIBE. If the From field contains a SIP
data they see, and when. Access controls are a critical component of URL, it is converted to an equivalent pres URL by dropping all
a presence solution, but are ideally separated from the underlying SIP URL parameters, and changing the scheme to pres.
presence protocol. This is because access controls are fundamentally
a mechanism for influencing policy decisions made by presence
servers; policy can be controlled in numerous ways, and for maximum
flexibility and modularity, should be kept separate.
Some possibilities for access controls include: This conversion may not work - what if the SIP URL has
no user name. Plus, converting from a URL back to a
URN in this fashion may not do it correctly.
Web Based: A user can go to a secure web page, enter in access o The target identity in the CPIM message is copied from the
controls, and have the data pushed to the presence server Request-URI field of the SUBSCRIBE. This may need to be
through proprietary means (the presence server itself may converted to a pres URL as well.
run a web server). This provides the opportunity for
substantial differentiation in access control services,
without interoperability issues. However, it is not
suitable for automated control over access controls.
CPL Based: The call processing language (CPL) [13] is used to o The duration parameter in the CPIM message is copied from the
define call processing rules (i.e., policy) for call setup Expires header in the SUBSCRIBE. If the Expires header
requests. We observe that the same policies will likely specifies an absolute time, it is converted to a delta-time by
make sense for subscriptions as well. Therefore, CPL, the gateway. If no Expires header is present, one hour is
possibly with some extensions, can be used for access assumed.
controls for presence. These access controls can be
uploaded in a SIP REGISTER request [14].
COPS: The Common Open Policy Service (COPS) [12] protocol allows o The transID parameter in the CPIM message is constructed by
for general purpose outsourced policy decisions. It could appending the Call-ID, the URI in the To field, the URI in the
easily be used by presence servers to define processing of From field, the CSeq and the tag in the From field, and the
subscriptions. request URI, and computing a hash of the resulting string.
This hash is used as the transID. Note that the request URI is
included in the hash. This is to differentiate forked requests
within the SIP network that may arrive at the same gateway.
Some of the things access controls can be used for are: The CPIM service then responds with either a success or failure. In
the case of success, the SIP to CPIM gateway service generates a 202
response to the SUBSCRIBE. It adds a tag to the To field in the
response, which is the same as the transID field in the success
response. The 202 response also contains a Contact header, which is
the value of the target from the SUBSCRIBE request. It is important
that the Contact header be set to the target, since that makes sure
that subscription refreshes have the same value in the request URI as
the original subscription. The duration value from the CPIM success
response is placed into the Expires header of the 202. The gateway
stores the Call-ID and Route header set for this subscription.
o Pre-authorizing subscribers, so that their subscriptions are If the CPIM service responds with a failure, the SIP to CPIM gateway
automatically accepted. generates a 603 response. It adds a tag to the To field in the
response, which is the same as the transID field in the failure
response.
o Blocking subscribers, so that their subscription requests are When the CPIM system generates a notification request, the SIP to
automatically rejected CPIM gateway creates a SIP NOTIFY request. The request is constructed
using the standard RFC2543 [2] procedures for constructing a request
within a call leg. This will result in the To field containing the
watcher field from CPIM, and the From field containing the target
field from the CPIM notification. The tag in the From field will
contain the transID. The presence information is copied into the body
of the notification. The Call-ID and Route headers are constructed
from the subscription state stored in the gateway. If no notification
has yet been generated for this subscription, an initial CSeq value
is selected and stored.
o Specifying that only subsets of presence information are SUBSCRIBE refreshes are handled identically to initial subscriptions
reported to selected subscribers as above.
o Specifying that false presence information can be given to If a subscription is received with an Expires of zero, the SIP to
selected subscribers CPIM gateway generates an unsubscribe message into the the CPIM
system. The watcher parameter is copied from the From field of the
SUBSCRIBE. The target parameter is copied from the Request URI field
of the SUBSCRIBE. The transID is copied from the tag in the To field
of the SUBSCRIBE request.
9 Providing scalability The response to an unsubscribe is either success or failure. In the
case of success, a 202 response is constructed in the same fashion as
above for a success response to a CPIM subscriber. All subscription
state is removed. In the case of failure, a 603 response is
constructed in the same fashion as above, and then subscription state
is removed, if present.
This section briefly overviews the mechanisms in this extension which 7.2 CPIM to SIP
provide scalability, a critical goal for any presence protocol.
We have observed that scalability is limited by the messaging and CPIM to SIP conversion occurs when a CPIM subscription request
processing load at presence servers. As the processing load is arrives on the CPIM side of the gateway. This scenario is shown in
proportional to the message load, we can consider just the message Figure 2.
load to determine the scale bottlenecks at a presence server. This
load is equal to:
load = (presentities * The CPIM subscription request is converted into a SIP SUBSCRIBE
subscribers per presentity * request. To do that, the first step is to determine if the subscribe
notifications per presentity) + is for an existing subscription. That is done by taking the target in
the CPIM subscription request, and matching it against targets for
existing subscriptions. If there are none, it is a new subscription,
otherwise, its a refresh.
(presentities * If its a new subscription, the gateway generates a SIP SUBSCRIBE
subscribers per presentity) request in the following manner:
The first term represents the notification load, and the second, the o The From field in the request is set to the watcher field in
subscription load. The dominant factor is the notification load. We the CPIM subscription request
address this load by providing three mechanisms - one for the
reduction of each of these terms.
9.1 Partitioning of the namespace o The To field in the request is set to the target field in the
CPIM subscription request
The load on an individual server can be reduced by partitioning the o The Expires header in the SUBSCRIBE request is set to the
namespace, so that a single presence server handles only a small duration field in the CPIM subscription request
number of presentities. This is accomplished through proxy servers,
which can receive a subscription, determine the subdomain which owns
the presence for that user, and forward the subscription to that
subdomain. The subdomain itself may have proxies which do this. The
result is that the presence namespace can be divided hierarchically,
with proxies providing routing towards the leafs, which handle the
actual presence servers.
As an example, a subscription request to sip:joe@example.com reaches o The tag in the From field is set to the transID in the CPIM
the main proxy server for example.com. This server does nothing but subscription request.
look up users in a directory server, mapping them to subdomains. This
particular user is in engineering, so the proxy maps the request URI
to sip:joe@engineering.example.com, and forwards it to the
engineering.example.com server. A different user may have been
forwarded to the marketing.example.com server. These servers, in
turn, can rely on databases or other configuration to map these
addresses into further subdomains. For example, the engineering
server might map sip:joe@engineering.example.com to
sip:joe@electrical.engineering.example.com. As these proxies are
generally stateless, they can be easily clustered, with load
balancing provided through DNS SRV records. Use of SRV records also
provides for fault tolerance among the cluster.
SIP proxy servers can be stateless; assisting only in the routing of +-------------+
requests, and not maintaining any state at all. Furthermore, through | |
SIPs Record-Routing mechanisms, proxies can assist in routing the | CPIM to SIP |
first SUBSCRIBE request; refreshes can bypass the proxies to improve | Conversion |
scale. | |
SIP SUBSCRIBE | | CPIM subscription request
<--------------> | | <--------------->
| |
| |
| |
| |
| |
| |
+-------------+
9.2 Client notifications Figure 2: CPIM to SIP Conversion
The load can also be reduced by completely eliminating notifications This SUBSCRIBE message is then sent.
from the presence server. This is accomplished through the mechanisms
described in this extension that allow, by default, a presence client
to generate notifications for a subscriber. This follows the well
known Internet scalability principle of pushing intelligence to the
periphery.
9.3 Distributed subscription state If the subscription is a refresh, a SUBSCRIBE request is generated in
the same way. However, there will also be a tag in the To field,
copied from the subscription state in the gateway, and a Route
header, obtained from the subscription state in the gateway.
All the subscriptions from one domain to another can be aggregated by When a response to the SUBSCRIBE is received, a response is sent to
co-locating a PA with a local outbound proxy. This is shown in Figure the CPIM system. The duration parameter in this response is copied
2. from the Expires header in the SUBSCRIBE response (a conversion from
an absolute time to delta time may be needed). The transID in the
response is copied from the tag in the From field of the response. If
the response was 202, the status is set to indeterminate. If the
response was any other 200 class response, the status is set to
sucess. For any other final response, the status is set to failure.
In the figure, domain X has two subscribers for a single presentity If the response was a 200 class response, subscription state is
in domain Y. Both subscribers use a local outbound proxy, so that the established. This state contains the tag from the To field in the
SUBSCRIBE messages pass through a single proxy. When the proxy sees a SUBSCRIBE response, and the Route header set computed from the
subscription for a user in an outside domain, it acts as a PA, and Record-Routes and Contact headers in the 200 class response. The
accepts the subscription itself. Since a PA must be aware of the subscription is indexed by the presentity identification (the To
complete presence state of the presentity, the presence server itself field of the SUBSCRIBE that was generated).
subscribes to the presentity the first time it gets a subscription
for that presentity. Subsequent subscriptions from inside domain X
for the same presentity do not need to trigger additional
subscriptions outside. A single subscription from domain X is used.
So, in the figure, the first subscription request, SUBSCRIBE 1, might If an unsubscribe request is received from the CPIM side, the gateway
look like: checks if the subscription exists. If it does, a SUBSCRIBE is
generated as described above. However, the Expires header is set to
zero. If the subscription does not exist, the gateway generates a
failure response and sends it to the CPIM system. When the response
to the SUBSCRIBE request arrives, it is converted to a CPIM response
as described above for the initial SUBSCRIBE response. In all cases,
any subscription state in the gateway is destroyed.
SUBSCRIBE sip:presentity@domainy.com SIP/2.0 When a NOTIFY is received from the SIP system, a CPIM notification
Via: SIP/2.0/UDP subscriberA-pc.domainx.com request is sent. This notification is constructed as follows:
From: sip:subscriberA@domainx.com
To: sip:presentity@domainy.com
Call-ID: uobhasd97@7.3.4.2
CSeq: 1 SUBSCRIBE
Contact: sip:subscriberA@subscriberA-pc.domainX.com
Content-Length: 0
++++++++++
++++++++ +++++
+++ +++
++ ++++++++++++
+ ++
+ ++
+---------+ + + +---------+
| +----+ | +SUBSCRIBE 3 | |
| | | |-------------------> | |
| | PA | | ++ + | Proxy |
| +----+ | +++++ + | |
| Outbound| ++ + | |
| Proxy | + + | |
+---------+ ++ + +---------+
SUBSCRIBE ^ ^ + ++ \
1 / \ + ++ \
/ \ SUBSCRIBE + ++++ \ SUBSCRIBE 3
//-----\\ \ 2 ++ ++++++ \
// \\ \ ++ ++ \
| Subscriber | \ ++ +++ >
\\ A // \ ++ ++ +---------+
\\-----// \ + ++ | |
//------\\ ++ + | Presence|
|/ \| + + | Server |
| Subscriber | + ++ | |
|\ B /| + + | |
\\------// + + +---------+
+ ++
+ +
++ +
DOMAIN X + + /\
+ + / \
++++ + /PUA \
+++++ ++ /------\
++++++ +
++ DOMAIN Y ++
++ ++
+++++++++++++++++++
Figure 2: Distributing Subscription State o The CPIM watcher is set to the URI in the To field of the
NOTIFY.
When this is received at the outbound proxy/PA for domain X, the PA o The CPIM target is set to the URI in the From field of the
itself generates a subscription for presentity, SUBSCRIBE 3: NOTIFY.
Via: SIP/2.0/UDP outboundproxy.domainx.com o The transID is computed using the same mechanism as for the
From: sip:domainx.com SUBSCRIBE in Section 7.1
To: sip:presentity@domainy.com
Call-ID: gghhjjoo@0.1.2.3
CSeq: 77 SUBSCRIBE
Contact: sip:outboundproxy.domainX.com
Content-Length: 0
Note that this subscription lists the outbound proxy/PA as the o The presence component of the notification is extracted from
originating host (in the Via and Contact fields), and sip:domainx.com the body of the SIP NOTIFY request.
as the identity of the subscriber. This subcription is forwarded to
the PA for presentity in domain Y. If it is willing to accept a
domain wide subscription (after authenticating the request, of
course, as coming from the owner of the domain), a 200 OK is
generated. Once this arrives at the outbound proxy, it can accept the
subscription from subscriber 1.
When subscriber 2 subscribes, using SUBSCRIBE 2: The gateway generates a 200 response to the SIP NOTIFY and sends it
as well.
SUBSCRIBE sip:presentity@domainy.com SIP/2.0 TODO: some call flow diagrams with the parameters
Via: SIP/2.0/UDP subscriberB-pc.domainx.com
From: sip:subscriberB@domainx.com
To: sip:presentity@domainy.com
Call-ID: qwertyuiop@11.22.33.44
CSeq: 12 SUBSCRIBE
Contact: sip:subscriberB@subscriberB-pc.domainX.com
Content-Length: 0
this subscription is accepted by the outbound proxy/PA. No 8 Firewall and NAT Traversal
subscriptions are generated or forwarded to domain Y.
This process results in the subscription state being distributed It is anticipated that presence services will be used by clients and
throughout the network, with each domain holding the subscriptions presentities that are connected to proxy servers on the other side of
from users within its own domain. In fact, the process can take place firewalls and NATs. Fortunately, since the SIP presence messages do
recursively, resulting in distribution of presence state over a tree not establish independent media streams, as INVITE does, firewall and
of domains. That achieves scale; a presentity that might get millions NAT traversal is much simpler than described in [9] and [10].
of subscribers would be readily served by such an architecture.
The important concept to note here is that this aggregation process Generally, data traverses NATs and firewalls when it is sent over TCP
is a matter of local optimization in domain X; as far as domain Y is or TLS connections established by devices inside the firewall/NAT to
concerned, there is a single subscription, and processing that devices outside of it. As a result, it is RECOMMENDED that SIP for
subscription is no different than processing any other subscription. presence entities maintain persistent TCP or TLS connections to their
This is possible because we have defined presence operations to be next hop peers. This includes connections opened to send a SUBSCRIBE,
invoked on logical entities, PAs, which can dynamically be NOTIFY, and most importantly, REGISTER. By keeping the latter
instantiated on a subscription by subscription basis in any device connection open, it can be used by the SIP proxy to send messages
which can somehow determine the complete presence state of a from outside the firewall/NAT back to the client. It is also
presentity. In the case here, the outbound proxy is instantiating the recommended that the client include a Contact cookie as described in
PA, and it is allowing the PA to know the presence state of a [10] in their registration, so that the proxy can map the presentity
presentity through another subscription. URI to that connection.
The drawback of this optimization is that it introduces security Furthermore, entities on either side of a firewall or NAT should
issues. The subscription from domainX is now domain wide; the record-route in order to ensure that the initial connection
presentity cannot authenticate the identity of every subscriber established for the subscription is used for the notifications as
within the domain. It is forced into a trust relationship with that well.
domain, such that domain Y trusts that domain X is authenticating
each subscriber. Furthermore, the ability of the presentity to
authorize some subscribers from domain X, but not others, is lost,
unless there is some means to convey access control across domains.
As a result, the decision about whether to accept such domain wide
subscriptions is up to the security policy of the presence server.
Clearly, such subscriptions might be accepted for certain
presentities (ones with many subscribers), but not others.
10 Security considerations 9 Security considerations
There are numerous security considerations for presence. Many are There are numerous security considerations for presence. Many are
outlined above; this section considers them issue by issue. outlined above; this section considers them issue by issue.
10.1 Privacy 9.1 Privacy
Privacy encompasses many aspects of a presence system: Privacy encompasses many aspects of a presence system:
o Subscribers may not want to reveal the fact that they have o Subscribers may not want to reveal the fact that they have
subscribed to certain users subscribed to certain users
o Users may not want to reveal that they have accepted o Users may not want to reveal that they have accepted
subscriptions from certain users subscriptions from certain users
o Notifications (and fetch results) may contain sensitive data o Notifications (and fetch results) may contain sensitive data
which should not be revealed to anyone but the subscriber which should not be revealed to anyone but the subscriber
Privacy is provided through a combination of hop by hop encryption Privacy is provided through a combination of hop by hop encryption
and end to end encryption. The hop by hop mechanisms provide scalable and end to end encryption. The hop by hop mechanisms provide scalable
privacy services, disable attacks involving traffic analysis, and privacy services, disable attacks involving traffic analysis, and
hide all aspects of presence messages. However, they operate based on hide all aspects of presence messages. However, they operate based on
transitivity of trust, and they cause message content to be revealed transitivity of trust, and they cause message content to be revealed
to proxies. The end to end mechanisms do not require transitivity of to proxies. The end-to-end mechanisms do not require transitivity of
trust, and reveal information only to the desired recipient. However, trust, and reveal information only to the desired recipient. However,
end to end encryption cannot hide all information, and is susceptible end-to-end encryption cannot hide all information, and is susceptible
to traffic analysis. Strong end to end authentication and encryption to traffic analysis. Strong end to end authentication and encryption
also requires that both participants have public keys, which is not also requires that both participants have public keys, which is not
generally the case. Thus, both mechanisms combined are needed for generally the case. Thus, both mechanisms combined are needed for
complete privacy services. complete privacy services.
SIP allows any hop by hop encryption scheme. It is RECOMMENDED that SIP allows any hop by hop encryption scheme. It is RECOMMENDED that
between network servers (proxies to proxies, proxies to redirect between network servers (proxies to proxies, proxies to redirect
servers), transport mode ESP [7] is used to encrypt the entire servers), transport mode ESP [11] is used to encrypt the entire
message. Between a UAC and its local proxy, TLS [15] is RECOMMENDED. message. Between a UAC and its local proxy, TLS [12] is RECOMMENDED.
Similarly, TLS SHOULD be used between a presence server and the PUA. Similarly, TLS SHOULD be used between a presence server and the PUA.
The presence server can determine whether TLS is supported by the The presence server can determine whether TLS is supported by the
receiving client based on the transport parameter in the Contact receiving client based on the transport parameter in the Contact
header of its registration. If that registration contains the token header of its registration. If that registration contains the token
"tls" as transport, it implies that the PUA supports TLS. "tls" as transport, it implies that the PUA supports TLS.
Furthermore, we allow for the Contact header in the SUBSCRIBE request Furthermore, we allow for the Contact header in the SUBSCRIBE request
to contain TLS as a transport. The Contact header is used to route to contain TLS as a transport. The Contact header is used to route
subsequent messages between a pair of entities. It defines the subsequent messages between a pair of entities. It defines the
address and transport used to communicate with the user agent. Even address and transport used to communicate with the user agent. Even
though TLS might be used between the subscriber and its local proxy, though TLS might be used between the subscriber and its local proxy,
skipping to change at page 35, line 34 skipping to change at page 18, line 27
SUBSCRIBE message has been successfully routed. This would provide SUBSCRIBE message has been successfully routed. This would provide
end to end privacy and authentication services with low proxy end to end privacy and authentication services with low proxy
overheads. overheads.
SIP encryption MAY be used end to end for the transmission of both SIP encryption MAY be used end to end for the transmission of both
SUBSCRIBE and NOTIFY requests. SIP supports PGP based encryption, SUBSCRIBE and NOTIFY requests. SIP supports PGP based encryption,
which does not require the establishment of a session key for which does not require the establishment of a session key for
encryption of messages within a given subscription (basically, a new encryption of messages within a given subscription (basically, a new
session key is established for each message as part of the PGP session key is established for each message as part of the PGP
encryption). Work has recently begun on the application of S/MIME encryption). Work has recently begun on the application of S/MIME
[16] for SIP. Tunneling of TLS over SIP, for the purposes of [13] for SIP.
establishment of an end to end private key for encryption, is also
under investigation.
10.2 Message integrity and authenticity 9.2 Message integrity and authenticity
It is important for the message recipient to ensure that the message It is important for the message recipient to ensure that the message
contents are actually what was sent by the originator, and that the contents are actually what was sent by the originator, and that the
recipient of the message be able to determine who the originator recipient of the message be able to determine who the originator
really is. This applies to both requests and responses of SUBSCRIBE really is. This applies to both requests and responses of SUBSCRIBE
and NOTIFY. This is supported in SIP through end to end and NOTIFY. This is supported in SIP through end to end
authentication and message integrity. SIP provides PGP based authentication and message integrity. SIP provides PGP based
authentication and integrity (both challenge-response and public key authentication and integrity (both challenge-response and public key
signatures), and http basic and digest authentication. signatures), and http basic and digest authentication. HTTP Basic is
NOT RECOMMENDED.
10.3 Outbound authentication 9.3 Outbound authentication
When local proxies are used for transmission of outbound messages, When local proxies are used for transmission of outbound messages,
proxy authentication is RECOMMENDED. This is useful to verify the proxy authentication is RECOMMENDED. This is useful to verify the
identity of the originator, and prevent spoofing and spamming at the identity of the originator, and prevent spoofing and spamming at the
originating network. originating network.
10.4 Replay prevention 9.4 Replay prevention
To prevent the replay of old subscriptions and notifications, all To prevent the replay of old subscriptions and notifications, all
signed SUBSCRIBE and NOTIFY requests and responses MUST contain a signed SUBSCRIBE and NOTIFY requests and responses MUST contain a
Date header covered by the message signature. Any message with a date Date header covered by the message signature. Any message with a date
older than several minutes in the past, or more than several minutes older than several minutes in the past, or more than several minutes
into the future, SHOULD be discarded. into the future, SHOULD be discarded.
Furthermore, all signed SUBSCRIBE and NOTIFY requests MUST contain a Furthermore, all signed SUBSCRIBE and NOTIFY requests MUST contain a
Call-ID and CSeq header covered by the message signature. A user Call-ID and CSeq header covered by the message signature. A user
agent or presence server MAY store a list of Call-ID values, and for agent or presence server MAY store a list of Call-ID values, and for
each, the higest CSeq seen within that Call-ID. Any message that each, the higest CSeq seen within that Call-ID. Any message that
arrives for a Call-ID that exists, whose CSeq is lower than the arrives for a Call-ID that exists, whose CSeq is lower than the
highest seen so far, is discarded. highest seen so far, is discarded.
Finally, challenge-response authentication (http basic, digest, of Finally, challenge-response authentication (http digest or PGP) MAY
PGP) MAY be used to prevent replay attacks. be used to prevent replay attacks.
10.5 Denial of service attacks 9.5 Denial of service attacks
Denial of service attacks are a critical problem for an open, inter- Denial of service attacks are a critical problem for an open, inter-
domain, presence protocol. Here, we discuss several possible attacks, domain, presence protocol. Here, we discuss several possible attacks,
and the steps we have taken to prevent them. and the steps we have taken to prevent them.
10.5.1 Smurf attacks through false contacts 9.5.1 Smurf attacks through false contacts
Unfortunately, presence is a good candidate for smurfing attacks Unfortunately, presence is a good candidate for smurfing attacks
because of its amplification properties. A single SUBSCRIBE message because of its amplification properties. A single SUBSCRIBE message
could generate a nearly unending stream of notifications, so long as could generate a nearly unending stream of notifications, so long as
a suitably dynamic source of presence data can be found. Thus, a a suitably dynamic source of presence data can be found. Thus, a
simple way to launch an attack is to send subscriptions to a large simple way to launch an attack is to send subscriptions to a large
number of users, and in the Contact header (which is where number of users, and in the Contact header (which is where
notifications are sent), place the address of the target. notifications are sent), place the address of the target.
The only reliable way to prevent these attacks is through The only reliable way to prevent these attacks is through
authentication and authorization. End users will hopefully not accept authentication and authorization. End users will hopefully not accept
subscriptions from random unrecognized users. Also, the presence subscriptions from random unrecognized users. Also, the presence
client software could be programmed to warn the user when the Contact client software could be programmed to warn the user when the Contact
header in a SUBSCRIBE is from a domain which does not match that of header in a SUBSCRIBE is from a domain which does not match that of
the From field (which identifies the subscriber). the From field (which identifies the subscriber).
Also, note that as described in Section 7.3, if a notify is not Also, note that as described in [3], if a NOTIFY is not acknowledged
acknowledged or was not wanted, the subscription that generated it is or was not wanted, the subscription that generated it is removed.
removed. This eliminates some of the amplification properties of This eliminates the amplification properties of providing false
providing false Contact addresses. Contact addresses.
10.5.2 Annoyance subscriptions
A user can attempt to "annoy" another by subscribing, and on
rejection, subscribe again. If subscriptions cause screen pops, this
can result in a DoS attack whereby screen pops are constantly pushed
onto the subscribed parties machine. To avoid this attack, PUAs
SHOULD cache rejected subscriptions and automatically reject
subsequent ones (of course, the UA will want a way for the subscriber
to remove the negative cached entries if they change their mind). In
addition, the PUA SHOULD use access control mechanisms to block those
subscriptions at the presence server as well.
10.6 Firewall traversal
The extension defined here is firewall and NAT friendly, in that it
can be configured in such a way as to traverse any device which
allows outgoing TCP connections to an external server.
Consider the configuration in Figure 3:
The key to enabling traversal of the firewall is to ensure that all
SUBSCRIBE requests, their responses, and subsequent notifications and
their responses, all traverse a long lived connection opened from the
proxy inside the firewall (on the left) out towards the proxy or
presence server in the remote domain.
SIP supports long lived connections, but what is needed here is a
means for the proxy inside the firewall to request to the presence
entity on the far side that (1) the connection be kept open, and (2)
the presence entity record-route, so that notifications pass over the
same connection. These are accomplished with a simple extension [17].
In this environment, the proxy would need to be aware it is behind a
firewall, so that it can request the persistent connection, and use
TCP in the first place. Note that a subscriber could also do this,
allowing for firewall traversal even in the absence of a proxy inside
the firewall.
Since usage of these persistent connections is not mandatory, it can
be used when needed, but for non-firewalled networks, end to end
notifications can be used instead, increasing scalability.
11 Addressing Transport
SIP, and this protocol based on it, is very flexible in its usage of
|
|
|
|
INSIDE | OUTSIDE
|
|
|
|
+--------+ | +--------+
| | | | |
| | | |Presence|
| Proxy | --------------+--------- | Entity |
| | | | |
| | | | |
+--------+ | +--------+
| |
| |
| |
| |
| |
| |
| |
/------\ |
// \\ |
| Subscriber | |
| | |
\\ //
\------/ Firewall
Figure 3: Architecture of Presence System
transport protocols. Both TCP and UDP operation are defined; SIP is
reliable over any transport and provides its own application layer
congestion control, reliability and sequencing. New transports can be
used, such as the Stream Control Transmission Protocol (SCTP) [5],
which may prove useful for presence messages [6], or TLS. SIPs
ability to run over UDP may provide useful for an eventual
application of multicast to presence information. Notifications, in
particular, might be very amenable to multicast distribution.
This flexibility is needed because, simply put, one size does not fit
all. UDP is beneficial in that it can be used in stateless proxy
servers, improving scale and performance. It is also faster, as no
explicit connection setup is required. It may also be appropriate for
small devices, such as wireless handsets, which may not readily
support persistent connections. However, TCP is advantageous in many
cases for liveness determination, congestion control, and its
superior segmentation and reassembly capabilities.
12 Required SIP features
SIP contains many components and capabilities, only some of which are
needed to support presence. It is a common misconception to believe
that SIP is only good for initiating phone calls. Since SIP separates
the definition of a session to other protocols, such as the Session
Description Protocol (SDP) [4], SIP is best viewed as a real-time
rendezvous system, which allows content to be delivered from one
user, to the current location(s) where another user, the desired
target, is located. This rendezvous system can be used to deliver
invitations to sessions, as is accomplished with the INVITE method,
but other data, such as subscriptions and notifications, can be
delivered.
As such, most of the generic components of SIP as they relate to
message routing are useful and needed for this extension, and most of
those related specifically to INVITE, BYE, ACK, and CANCEL processing
are not needed.
This section outlines those components needed, and those not needed,
for presence.
12.1 Needed components
The following are the SIP components needed in a PA, PUA, or
subscriber (all three are classified as user agents in SIP
terminology) to support this extension:
o Basic SIP parser, capable of generating To, From, Call-ID,
CSeq, To, Via, Route, Accept, Allow, Require, Record-Route,
Expires, Contact, Content-Length, and Content-Type headers, in
addition to the request and response line.
o UDP transmission mechanisms for non-INVITE requests, which is
nothing more than a periodic retransmit of a request with
exponential backoff.
o Implementation of the client and server state machine for
non-INVITE requests (used for reliable transport), documented
in Section 10.4.1 of SIP [2].
o The ability to send SIP REGISTER requests, and process
responses, and refresh those registrations.
o Construction and usage of Route headers.
o Support the Require mechanism for protocol extension, as
defined in Section 6.30 of RFC 2543.
o Reject requests with unknown methods, returning an Allow
header in the response.
o Reject requests with unknown bodies, returning an Accept
header in the response.
o Send and process SIP responses based solely on the 100s digit.
o Send responses based on the Via header processing rules of
Section 6.40
If a UA wishes to implement security, it needs to support the
security mechanisms defined in RFC 2543.
A presence server must additionally act as a proxy, and therefore
must additionally be able to:
o Parse and generate SIP messages, understanding the To, From,
Call-ID, CSeq, Via, Route, Record-Route, and Proxy-Require
headers, in addition to the request and response line.
o If co-located with a registrar, process SIP REGISTER requests
and generate responses
o Perform the proxying functions described in Section 12 of RFC
2543; these rules mainly concern connection management, Via
processing, loop detection, and transport.
12.2 Components not needed
User agents supporting presence do not need to support the following
SIP capabilities:
o Processing of INVITE, ACK, CANCEL, BYE requests
o Support for the INVITE reliability mechanisms and state
machines
o multiple 200 OK responses
o SDP processing
o re-INVITEs
Elimination of INVITE processing alone results in a substantial
reduction in required features.
13 Example message flows 10 Example message flows
THe following subsections exhibit example message flows, to further The following subsections exhibit example message flows, to further
clarify behavior of the protocol. clarify behavior of the protocol.
13.1 Client to Client Subscription with Presentity State Changes 10.1 Client to Client Subscription with Presentity State Changes
This call flow illustrates subscriptions and notifications that do This call flow illustrates subscriptions and notifications that do
not involve a presence server. not involve a presence server.
The watcher subscribes to the presentity and the presentity includes The watcher subscribes to the presentity, and the subscription is
its current state in the 200 OK response message. The presentity accepted, resulting in a 202 Accepted response. The presentity
subsequently changes state (is on the phone), resulting in a new subsequently changes state (is on the phone), resulting in a new
notification. The flow finishes with the watcher canceling the notification. The flow finishes with the watcher canceling the
subscription. subscription.
Watcher Presentity Watcher Presentity
------- ----------- ------- -----------
| F1 SUBSCRIBE | | F1 SUBSCRIBE |
| ----------------------------->| | ----------------------------->|
| F2 200 OK | | F2 202 Accepted |
|<------------------------------| |<------------------------------|
| F3 NOTIFY | | F3 NOTIFY |
|<------------------------------| |<------------------------------|
| F4 200 OK | | F4 200 OK |
|------------------------------>| |------------------------------>|
| F5 NOTIFY | | F5 NOTIFY |
|<------------------------------| |<------------------------------|
| F6 200 OK | | F6 200 OK |
|------------------------------>| |------------------------------>|
| F7 SUBSCRIBE (unsub) | | F7 SUBSCRIBE (unsub) |
|------------------------------>| |------------------------------>|
| F8 200 OK | | F8 202 Accepted |
|<------------------------------| |<------------------------------|
Message Details Message Details
F1 SUBSCRIBE watcher -> presentity F1 SUBSCRIBE watcher -> presentity
SUBSCRIBE sip:presentity@pres.example.com SIP/2.0 SUBSCRIBE sip:presentity@pres.example.com SIP/2.0
Via: SIP/2.0/UDP watcherhost.example.com:5060 Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <sip:user@watcherhost.example.com> From: User <pres:user@example.com>
To: Resource <sip:presentity@pres.example.com> To: Resource <pres:presentity@example.com>
Call-ID: 3248543@watcherhost.example.com Call-ID: 3248543@watcherhost.example.com
CSeq : 1 SUBSCRIBE CSeq : 1 SUBSCRIBE
Expires: 600 Expires: 600
Accept: application/xpidf+xml, text/lpidf Accept: application/xpidf+xml
Event: presence
Contact: sip:user@watcherhost.example.com Contact: sip:user@watcherhost.example.com
F2 200 OK presentity->watcher F2 202 Accepted presentity->watcher
SIP/2.0 200 OK SIP/2.0 202 Accepted
Via: SIP/2.0/UDP watcherhost.example.com:5060 Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <sip:user@watcherhost.example.com> From: User <pres:user@example.com>
To: Resource <sip:presentity@pres.example.com> To: Resource <pres:presentity@example.com>;tag=88a7s
Call-ID: 3248543@watcherhost.example.com Call-ID: 3248543@watcherhost.example.com
Cseq: 1 SUBSCRIBE Cseq: 1 SUBSCRIBE
Event: presence
Expires: 600 Expires: 600
Content-Type: application/xpidf+xml Contact: sip:presentity@pres.example.com
Content-Length: 351
<?xml version="1.0"?>
<!DOCTYPE presence
PUBLIC "-//IETF//DTD RFCxxxx XPIDF 1.0//EN" "xpidf.dtd">
<presence>
<presentity uri="sip:presentity@pres.example.com;method=SUBSCRIBE"/>
<atom id="779js0a98">
<address uri="sip:presentity@pres.example.com;method=INVITE">
<status status="open"/>
</address>
</atom>
</presence>
F3 NOTIFY Presentity->watcher F3 NOTIFY Presentity->watcher
NOTIFY sip:user@watcherhost.example.com SIP/2.0 NOTIFY sip:user@watcherhost.example.com SIP/2.0
Via: SIP/2.0/UDP pres.example.com:5060 Via: SIP/2.0/UDP pres.example.com:5060
From: Resource <sip:presentity@pres.example.com> From: Resource <pres:presentity@example.com>;tag=88a7s
To: User <sip:user@watcherhost.example.com> To: User <pres:user@example.com>
Call-ID: 3248543@watcherhost.example.com Call-ID: 3248543@watcherhost.example.com
CSeq: 1 NOTIFY CSeq: 1 NOTIFY
Event: presence
Content-Type: application/xpidf+xml Content-Type: application/xpidf+xml
Content-Length: 352 Content-Length: 120
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE presence <presence entityInfo="pres:presentity@example.com">
PUBLIC "-//IETF//DTD RFCxxxx XPIDF 1.0//EN" "xpidf.dtd"> <tuple destination="sip:presentity@example.com" status="open"/>
<presence>
<presentity uri="sip:presentity@pres.example.com;method=SUBSCRIBE"/>
<atom id="779js0a98">
<address uri="sip:presentity@pres.example.com;method=INVITE">
<status status="inuse"/>
</address>
</atom>
</presence> </presence>
F4 200 OK watcher->presentity F4 200 OK watcher->presentity
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/UDP pres.example.com:5060 Via: SIP/2.0/UDP pres.example.com:5060
From: Resource <sip:presentity@pres.example.com> From: Resource <pres:presentity@example.com>
To: User <sip:user@watcherhost.example.com> To: User <pres:user@example.com>
Call-ID: 3248543@watcherhost.example.com Call-ID: 3248543@watcherhost.example.com
CSeq: 1 NOTIFY CSeq: 1 NOTIFY
F5 NOTIFY Presentity->watcher F5 NOTIFY Presentity->watcher
NOTIFY sip:user@watcherhost.example.com SIP/2.0 NOTIFY sip:user@watcherhost.example.com SIP/2.0
Via: SIP/2.0/UDP pres.example.com:5060 Via: SIP/2.0/UDP pres.example.com:5060
From: Resource <sip:presentity@pres.example.com> From: Resource <pres:presentity@example.com>
To: User <sip:user@watcherhost.example.com> To: User <pres:user@example.com>
Call-ID: 3248543@watcherhost.example.com Call-ID: 3248543@watcherhost.example.com
CSeq: 2 NOTIFY CSeq: 2 NOTIFY
Event: presence
Content-Type: application/xpidf+xml Content-Type: application/xpidf+xml
Content-Length: 351 Content-Length: 120
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE presence <presence entityInfo="pres:presentity@example.com">
PUBLIC "-//IETF//DTD RFCxxxx XPIDF 1.0//EN" "xpidf.dtd"> <tuple destination="sip:presentity@example.com" status="closed"/>
<presence>
<presentity uri="sip:presentity@pres.example.com;method=SUBSCRIBE"/>
<atom id="779js0a98">
<address uri="sip:presentity@pres.example.com;method=INVITE">
<status status="open"/>
</address>
</atom>
</presence> </presence>
F6 200 OK watcher->presentity F6 200 OK watcher->presentity
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/UDP pres.example.com:5060 Via: SIP/2.0/UDP pres.example.com:5060
From: Resource <sip:presentity@pres.example.com> From: Resource <pres:presentity@example.com>
To: User <sip:user@watcherhost.example.com> To: User <pres:user@example.com>
Call-ID: 3248543@watcherhost.example.com Call-ID: 3248543@watcherhost.example.com
CSeq: 2 NOTIFY CSeq: 2 NOTIFY
F7 SUBSCRIBE watcher -> presentity F7 SUBSCRIBE watcher -> presentity
SUBSCRIBE sip:presentity@pres.example.com SIP/2.0 SUBSCRIBE sip:presentity@pres.example.com SIP/2.0
Via: SIP/2.0/UDP watcherhost.example.com:5060 Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <sip:user@watcherhost.example.com> From: User <pres:user@example.com>
To: Resource <sip:presentity@pres.example.com> To: Resource <pres:presentity@example.com>
Call-ID: 3248543@watcherhost.example.com Call-ID: 3248543@watcherhost.example.com
Event: presence
CSeq : 2 SUBSCRIBE CSeq : 2 SUBSCRIBE
Expires: 0 Expires: 0
Accept: application/xpidf+xml, text/lpidf Accept: application/xpidf+xml
Contact: sip:user@watcherhost.example.com Contact: sip:user@watcherhost.example.com
F8 200 OK presentity->watcher F8 202 Accepted presentity->watcher
SIP/2.0 200 OK SIP/2.0 202 Accepted
Via: SIP/2.0/UDP watcherhost.example.com:5060 Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <sip:user@watcherhost.example.com> From: User <pres:user@example.com>
To: Resource <sip:presentity@pres.example.com> To: Resource <pres:presentity@example.com>
Call-ID: 3248543@watcherhost.example.com Call-ID: 3248543@watcherhost.example.com
Event: presence
Cseq: 2 SUBSCRIBE Cseq: 2 SUBSCRIBE
Expires:0 Expires:0
Content-Type: text/lpidf
Content-Length: 113
To: sip:presentity@pres.example.com 10.2 Presence Server with Client Notifications
Contact: sip:presentity@pres.example.com;method=INVITE;
description="open"
13.2 Presence Server with Client Notifications
This call flow shows the involvement of a presence server in the This call flow shows the involvement of a presence server in the
handling of subscriptions. In this scenario, the client has indicated handling of subscriptions. In this scenario, the client has indicated
that it will handle subscriptions and thus notifications. The message that it will handle subscriptions and thus notifications. The message
flow shows a change of presence state by the client and a flow shows a change of presence state by the client and a
cancellation of the subscription by the watcher. cancellation of the subscription by the watcher.
Presence Presence
Watcher Server PUA Watcher Server PUA
| | F1 REGISTER | | | F1 REGISTER |
| |<---------------------| | |<---------------------|
| | F2 200 OK | | | F2 200 OK |
| |--------------------->| | |--------------------->|
| F3 SUBSCRIBE | | | F3 SUBSCRIBE | |
|--------------------->| | |--------------------->| |
| | F4 SUBSCRIBE | | | F4 SUBSCRIBE |
| |--------------------->| | |--------------------->|
| | F5 200 OK | | | F5 202 |
| |<---------------------| | |<---------------------|
| F6 200 OK | | | F6 202 | |
|<---------------------| | |<---------------------| |
| | F7 REGISTER | | F7 NOTIFY | |
|<--------------------------------------------+
| F8 200 OK | |
|-------------------------------------------->|
| | F9 REGISTER |
| |<---------------------| | |<---------------------|
| | F8 200 OK | | | F10 200 OK |
| |--------------------->| | |--------------------->|
| F9 NOTIFY | | | F11 NOTIFY | |
|<--------------------------------------------+ |<--------------------------------------------+
| F10 200 OK | | | F12 200 OK | |
|-------------------------------------------->| |-------------------------------------------->|
| F11 SUBSCRIBE | |
|--------------------->| |
| | F12 SUBSCRIBE |
| |--------------------->|
| | F13 200 OK |
| |<---------------------|
| F14 200 OK | |
|<---------------------| |
Message Details Message Details
F1 REGISTER PUA->server F1 REGISTER PUA->server
REGISTER sip:example.com SIP/2.0 REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com:5060 Via: SIP/2.0/UDP pua.example.com:5060
To: <sip:resource@example.com> To: <sip:resource@example.com>
From: <sip:resource@example.com> From: <sip:resource@example.com>
Call-ID: 2818@pua.example.com Call-ID: 2818@pua.example.com
CSeq: 1 REGISTER CSeq: 1 REGISTER
Contact: <sip:id@pua.example.com;method=MESSAGE> Contact: <sip:id@pua.example.com>;methods="MESSAGE"
;description="open" ;description="open"
Contact: <sip:id@pua.example.com;method=SUBSCRIBE> Contact: <sip:id@pua.example.com>;methods="SUBSCRIBE"
Expires: 600 Expires: 600
F2 200 OK server->PUA F2 200 OK server->PUA
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/UDP pua.example.com:5060 Via: SIP/2.0/UDP pua.example.com:5060
To: <sip:resource@example.com> To: <sip:resource@example.com>
From: <sip:resource@example.com> From: <sip:resource@example.com>
Call-ID: 2818@pua.example.com Call-ID: 2818@pua.example.com
CSeq: 1 REGISTER CSeq: 1 REGISTER
Contact: <sip:id@pua.example.com;method=MESSAGE> Contact: <sip:id@pua.example.com>;methods="MESSAGE"
;description="open" ;description="open"
Contact: <sip:id@pua.example.com;method=SUBSCRIBE> Contact: <sip:id@pua.example.com>;methods="SUBSCRIBE"
Expires: 600 Expires: 600
F3 SUBSCRIBE watcher->server F3 SUBSCRIBE watcher->server
SUBSCRIBE sip:resource@example.com SIP/2.0 SUBSCRIBE sip:resource@example.com SIP/2.0
Via: SIP/2.0/UDP watcherhost.example.com:5060 Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <sip:user@example.com> From: User <pres:user@example.com>
To: Resource <sip:resource@example.com> To: Resource <pres:resource@example.com>
Call-ID: 32485@watcherhost.example.com Call-ID: 32485@watcherhost.example.com
CSeq : 1 SUBSCRIBE CSeq : 1 SUBSCRIBE
Expires: 600 Expires: 600
Event: presence
Accept: application/xpidf+xml
Contact: sip:user@watcherhost.example.com Contact: sip:user@watcherhost.example.com
F4 SUBSCRIBE server->PUA F4 SUBSCRIBE server->PUA
SUBSCRIBE sip:id@pua.example.com SIP/2.0 SUBSCRIBE sip:id@pua.example.com SIP/2.0
Via: SIP/2.0/UDP server.example.com:5060 Via: SIP/2.0/UDP server.example.com:5060
Via: SIP/2.0/UDP watcherhost.example.com:5060 Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <sip:user@example.com> From: User <pres:user@example.com>
To: Resource <sip:resource@example.com> To: Resource <pres:resource@example.com>
Call-ID: 32485@watcherhost.example.com Call-ID: 32485@watcherhost.example.com
CSeq : 1 SUBSCRIBE CSeq : 1 SUBSCRIBE
Event: presence
Expires: 600 Expires: 600
Accept: application/xpidf+xml
Contact: sip:user@watcherhost.example.com Contact: sip:user@watcherhost.example.com
F5 200 OK PUA->server F5 202 Accepted PUA->server
SIP/2.0 200 OK SIP/2.0 202 Accepted
Via: SIP/2.0/UDP server.example.com:5060 Via: SIP/2.0/UDP server.example.com:5060
Via: SIP/2.0/UDP watcherhost.example.com:5060 Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <sip:user@example.com> From: User <pres:user@example.com>
To: Resource <sip:resource@example.com> To: Resource <pres:resource@example.com>;tag=ffd2
Call-ID: 32485@watcherhost.example.com Call-ID: 32485@watcherhost.example.com
CSeq : 1 SUBSCRIBE CSeq : 1 SUBSCRIBE
Event: presence
Expires: 600 Expires: 600
Content-Type: text/lpidf
Content-Length: 115
To: sip:resource@example.com
Contact: <sip:id@pua.example.com;method=MESSAGE>
;description="open"
F6 200 OK server->watcher F6 200 OK server->watcher
SIP/2.0 200 OK
SIP/2.0 202 Accepted
Via: SIP/2.0/UDP watcherhost.example.com:5060 Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <sip:user@example.com> From: User <pres:user@example.com>
To: Resource <sip:resource@example.com> To: Resource <pres:resource@example.com>;tag=ffd2
Call-ID: 32485@watcherhost.example.com Call-ID: 32485@watcherhost.example.com
CSeq : 1 SUBSCRIBE CSeq : 1 SUBSCRIBE
Event: presence
Expires: 600 Expires: 600
Content-Type: text/lpidf
Content-Length: 115
To: sip:resource@example.com F7 NOTIFY PUA->watcher
Contact: <sip:id@pua.example.com;method=MESSAGE>
;description="open"
F7 REGISTER PUA->server NOTIFY sip:user@watcherhost.example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com:5060
To: User <pres:user@example.com>
From: Resource <pres:resource@example.com>;tag=ffd2
Call-ID: 32485@watcherhost.example.com
CSeq : 1 NOTIFY
Event: presence
Content-Type: application/xpidf+xml
Content-Length: 120
<?xml version="1.0"?>
<presence entityInfo="pres:resource@example.com">
<tuple destination="im:resource@example.com" status="open"/>
</presence>
F8 200 OK watcher->PUA
SIP/2.0 200 OK
Via: SIP/2.0/UDP pua.example.com:5060
To: User <pres:user@example.com>
From: Resource <pres:resource@example.com>;tag=ffd2
Call-ID: 32485@watcherhost.example.com
CSeq : 1 NOTIFY
F9 REGISTER PUA->server
REGISTER sip:example.com SIP/2.0 REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com:5060 Via: SIP/2.0/UDP pua.example.com:5060
To: <sip:resource@example.com> To: <sip:resource@example.com>
From: <sip:resource@example.com> From: <sip:resource@example.com>
Call-ID: 2818@pua.example.com Call-ID: 2818@pua.example.com
CSeq: 2 REGISTER CSeq: 2 REGISTER
Contact: <sip:id@pua.example.com;method=MESSAGE> Contact: <sip:id@pua.example.com>;methods="MESSAGE"
;description="inuse" ;description="busy"
Contact: <sip:id@pua.example.com>;methods="SUBSCRIBE"
Expires: 600 Expires: 600
F8 200 OK server->PUA F10 200 OK server->PUA
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/UDP pua.example.com:5060 Via: SIP/2.0/UDP pua.example.com:5060
To: <sip:resource@example.com> To: <sip:resource@example.com>
From: <sip:resource@example.com> From: <sip:resource@example.com>
Call-ID: 2818@pua.example.com Call-ID: 2818@pua.example.com
CSeq: 2 REGISTER CSeq: 2 REGISTER
Contact: <sip:id@pua.example.com;method=MESSAGE> Contact: <sip:id@pua.example.com>;methods="MESSAGE"
;description="inuse"; expires=600 ;description="busy"
Contact: <sip:id@pua.example.com;method=SUBSCRIBE> Contact: <sip:id@pua.example.com>;methods="SUBSCRIBE"
; expires=210 Expires: 600
F9 NOTIFY PUA->watcher F11 NOTIFY PUA->watcher
NOTIFY sip:user@watcherhost.example.com SIP/2.0 NOTIFY sip:user@watcherhost.example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com:5060 Via: SIP/2.0/UDP pua.example.com:5060
To: User <sip:user@example.com> To: User <pres:user@example.com>
From: Resource <sip:resource@example.com> From: Resource <pres:resource@example.com>;tag=ffd2
Call-ID: 32485@watcherhost.example.com Call-ID: 32485@watcherhost.example.com
CSeq : 1 NOTIFY CSeq : 2 NOTIFY
Content-Type: text/lpidf Event: presence
Content-Length: 116 Content-Type: application/xpidf+xml
Content-Length: 120
To: sip:resource@example.com <?xml version="1.0"?>
Contact: <sip:id@pua.example.com;method=MESSAGE> <presence entityInfo="pres:resource@example.com">
;description="inuse" <tuple destination="im:resource@example.com" status="busy"/>
</presence>
F10 200 OK watcher->PUA F12 200 OK watcher->PUA
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/UDP pua.example.com:5060 Via: SIP/2.0/UDP pua.example.com:5060
To: User <sip:user@example.com> To: User <pres:user@example.com>
From: Resource <sip:resource@example.com> From: Resource <pres:resource@example.com>;tag=ffd2
Call-ID: 32485@watcherhost.example.com
CSeq : 1 NOTIFY
F11 SUBSCRIBE watcher->server
SUBSCRIBE sip:resource@example.com SIP/2.0
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <sip:user@example.com>
To: Resource <sip:resource@example.com>
Call-ID: 32485@watcherhost.example.com
CSeq : 2 SUBSCRIBE
Expires: 0
Contact: sip:user@watcherhost.example.com
F12 SUBSCRIBE server->PUA
SUBSCRIBE sip:resource@example.com SIP/2.0
Via: SIP/2.0/UDP server.example.com:5060
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <sip:user@example.com>
To: Resource <sip:resource@example.com>
Call-ID: 32485@watcherhost.example.com
CSeq : 2 SUBSCRIBE
Expires: 0
Contact: sip:user@watcherhost.example.com
F13 200 OK PUA->server
SIP/2.0 200 OK
Via: SIP/2.0/UDP server.example.com:5060
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <sip:user@example.com>
To: Resource <sip:resource@example.com>
Call-ID: 32485@watcherhost.example.com
CSeq : 2 SUBSCRIBE
Content-Type: text/lpidf
Content-Length: 115
To: sip:resource@example.com
Contact: <sip:id@pua.example.com;method=MESSAGE>
; description="open"
F14 200 OK server->watcher
SIP/2.0 200 OK
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <sip:user@example.com>
To: Resource <sip:resource@example.com>
Call-ID: 32485@watcherhost.example.com Call-ID: 32485@watcherhost.example.com
CSeq : 2 SUBSCRIBE CSeq : 2 NOTIFY
Content-Type: text/lpidf
Content-Length: 115
To: sip:resource@example.com
Contact: <sip:id@pua.example.com;method=MESSAGE>
; description="open"
13.3 Presence Server Notifications 10.3 Presence Server Notifications
This message flow illustrates how the presence server can be the This message flow illustrates how the presence server can be the
responsible for sending notifications for a presentity. The presence responsible for sending notifications for a presentity. The presence
server will do this if the presentity has not sent a registration server will do this if the presentity has not sent a registration
indicating an interest in handling subscriptions. This flow assumes indicating an interest in handling subscriptions. This flow assumes
that the watcher has previously been authorized to subscribe to this that the watcher has previously been authorized to subscribe to this
resource at the server. resource at the server.
Watcher Server PUA Watcher Server PUA
| F1 SUBSCRIBE | | | F1 SUBSCRIBE | |
|------------------>| | |------------------>| |
| F2 200 OK | | | F2 202 Accepted | |
|<------------------| | |<------------------| |
| | F3 REGISTER | | F3 NOTIFY | |
| |<-------------------|
| | F4 200 OK |
| |------------------->|
| F5 NOTIFY | |
|<------------------| | |<------------------| |
| F6 200 OK | | | F4 200 OK | |
|------------------>| | |------------------>| |
| | F7 REGISTER | | | F5 REGISTER |
| |<-------------------| | |<-------------------|
| | F8 200 OK | | | F6 200 OK |
| |------------------->| | |------------------->|
| F9 NOTIFY | | | F7 NOTIFY | |
|<------------------| | |<------------------| |
| F10 200 OK | | | F8 200 OK | |
|------------------>| | |------------------>| |
Message Details Message Details
F1 SUBSCRIBE watcher->server F1 SUBSCRIBE watcher->server
SUBSCRIBE sip:resource@example.com SIP/2.0 SUBSCRIBE sip:resource@example.com SIP/2.0
Via: SIP/2.0/UDP watcherhost.example.com:5060 Via: SIP/2.0/UDP watcherhost.example.com:5060
To: <sip:resource@example.com> To: <pres:resource@example.com>
From: <sip:user@example.com> From: <pres:user@example.com>
Call-ID: 2010@watcherhost.example.com Call-ID: 2010@watcherhost.example.com
CSeq: 1 SUBSCRIBE CSeq: 1 SUBSCRIBE
Event: presence
Accept: application/xpidf+xml
Contact: <sip:user@watcherhost.example.com> Contact: <sip:user@watcherhost.example.com>
Expires: 600 Expires: 600
F2 200 OK server->watcher F2 202 OK server->watcher
SIP/2.0 200 OK SIP/2.0 202 Accepted
Via: SIP/2.0/UDP watcherhost.example.com:5060 Via: SIP/2.0/UDP watcherhost.example.com:5060
To: <sip:resource@example.com> To: <pres:resource@example.com>;tag=ffd2
From: <sip:user@example.com> From: <pres:user@example.com>
Call-ID: 2010@watcherhost.example.com Call-ID: 2010@watcherhost.example.com
CSeq: 1 SUBSCRIBE CSeq: 1 SUBSCRIBE
Event: presence
Expires: 600 Expires: 600
Content-Type: text/lpidf Contact: sip:example.com
Content-Length: 114
To: sip:resource@example.com
Contact: <sip:resource@example.com;method=MESSAGE>
;description="closed"
F3 REGISTER PUA->server
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com:5060
To: <sip:resource@example.com>
From: <sip:resource@example.com>
Call-ID: 110@pua.example.com
CSeq: 1 REGISTER
Contact: <sip:id@pua.example.com;method=MESSAGE>
;description="open"
Expires: 600
F4 200 OK server->PUA
SIP/2.0 200 OK
Via: SIP/2.0/UDP pua.example.com:5060
To: <sip:resource@example.com>
From: <sip:resource@example.com>
Call-ID: 110@pua.example.com
CSeq: 1 REGISTER
Contact: <sip:id@pua.example.com;method=MESSAGE>
; description="open"; expires=600
F5 NOTIFY server-> watcher F3 NOTIFY server-> watcher
NOTIFY sip:user@watcherhost.example.com SIP/2.0 NOTIFY sip:user@watcherhost.example.com SIP/2.0
Via: SIP/2.0/UDP server.example.com:5060 Via: SIP/2.0/UDP server.example.com:5060
From: <sip:resource@example.com> From: <pres:resource@example.com>;tag=ffd2
To: <sip:user@example.com> To: <pres:user@example.com>
Call-ID: 2010@watcherhost.example.com Call-ID: 2010@watcherhost.example.com
Event: presence
CSeq: 1 NOTIFY CSeq: 1 NOTIFY
Content-Type: text/lpidf Content-Type: application/xpidf+xml
Content-Length: 111 Content-Length: 120
To: sip:resource@example.com <?xml version="1.0"?>
Contact: <sip:id@pua.example.com;method=MESSAGE> <presence entityInfo="pres:resource@example.com">
; description="open" <tuple destination="im:resource@example.com" status="open"/>
</presence>
F6 200 OK F4 200 OK
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/UDP server.example.com:5060 Via: SIP/2.0/UDP server.example.com:5060
From: <sip:resource@example.com> From: <pres:resource@example.com>;tag=ffd2
To: <sip:user@example.com> To: <pres:user@example.com>
Call-ID: 2010@watcherhost.example.com Call-ID: 2010@watcherhost.example.com
CSeq: 1 NOTIFY CSeq: 1 NOTIFY
F7 REGISTER F5 REGISTER
REGISTER sip:example.com SIP/2.0 REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com:5060 Via: SIP/2.0/UDP pua.example.com:5060
To: <sip:resource@example.com> To: <sip:resource@example.com>
From: <sip:resource@example.com> From: <sip:resource@example.com>
Call-ID: 110@pua.example.com Call-ID: 110@pua.example.com
CSeq: 2 REGISTER CSeq: 2 REGISTER
Contact: <sip:id@pua.example.com;methods=MESSAGE> Contact: <sip:id@pua.example.com>;methods="MESSAGE"
;description="Away from keyboard" ;description="Away from keyboard"
Expires: 600 Expires: 600
F8 200 OK F6 200 OK
Via: SIP/2.0/UDP pua.example.com:5060 Via: SIP/2.0/UDP pua.example.com:5060
To: <sip:resource@example.com> To: <sip:resource@example.com>
From: <sip:resource@example.com> From: <sip:resource@example.com>
Call-ID: 110@pua.example.com Call-ID: 110@pua.example.com
CSeq: 2 REGISTER CSeq: 2 REGISTER
Contact: <sip:id@pua.example.com;methods=MESSAGE> Contact: <sip:id@pua.example.com>;methods="MESSAGE"
; description="Away from keyboard" ; description="Away from keyboard"
; expires=600 ; expires=600
F9 NOTIFY F7 NOTIFY
NOTIFY sip:user@watcherhost.example.com SIP/2.0 NOTIFY sip:user@watcherhost.example.com SIP/2.0
Via: SIP/2.0/UDP server.example.com:5060 Via: SIP/2.0/UDP server.example.com:5060
From: <sip:resource@example.com> From: <pres:resource@example.com>;tag=ffd2
To: <sip:user@example.com> To: <pres:user@example.com>
Call-ID: 2010@watcherhost.example.com Call-ID: 2010@watcherhost.example.com
CSeq: 2 NOTIFY CSeq: 2 NOTIFY
Content-Type: text/lpidf Event: presence
Content-Length: 125 Content-Type: application/xpidf+xml
Content-Length: 120
To: sip:resource@example.com <?xml version="1.0"?>
Contact: <sip:id@pua.example.com;method=MESSAGE> <presence entityInfo="pres:resource@example.com">
; description="Away from keyboard" <tuple destination="im:resource@example.com" status="Away from keyboard"/>
</presence>
F10 200 OK F8 200 OK
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/UDP server.example.com:5060 Via: SIP/2.0/UDP server.example.com:5060
From: <sip:resource@example.com> From: <sip:resource@example.com>;tag=ffd2
To: <sip:user@example.com> To: <pres:user@example.com>
Call-ID: 2010@watcherhost.example.com Call-ID: 2010@watcherhost.example.com
CSeq: 2 NOTIFY CSeq: 2 NOTIFY
13.4 Presence Server Notifications with Client Authorization of 11 Open Issues
Subscription
This call flow expands on the call flow in 13.3 by showing how the
Presence Server gets authorization for a new subscription from the
client. The authorization is done using the QAUTH method defined in
[9].
Presence
Watcher Server PUA
| | F1 REGISTER |
| |<---------------------|
| | F2 200 OK |
| |--------------------->|
| F3 SUBSCRIBE | |
|--------------------->| |
| F4 202 Accepted | |
|<---------------------| |
| | F5 QAUTH |
| |--------------------->|
| | F6 200 OK |
| |<---------------------|
| F7 NOTIFY | |
|<---------------------| |
| F8 200 OK | |
|--------------------->| |
| | F9 REGISTER |
| |<---------------------|
| | F10 200 OK |
| |--------------------->|
| F11 NOTIFY | |
|<---------------------| |
| F12 200 OK | |
|--------------------->| |
| F13 SUBSCRIBE | |
|--------------------->| |
| F14 200 OK | |
|<---------------------| |
Message Details:
F1 REGISTER PUA->server
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com:5060
To: <sip:resource@example.com>
From: <sip:resource@example.com>
Call-ID: 12@pua.example.com
CSeq: 1 REGISTER
Contact: <sip:id@pua.example.com;methods=MESSAGE>
;description="open"
Contact: <sip:id@pua.example.com;methods=QAUTH>
Expires: 600
F2 200 OK server->PUA
SIP/2.0 200 OK
Via: SIP/2.0/UDP pua.example.com:5060
To: <sip:resource@example.com>
From: <sip:resource@example.com>
Call-ID: 12@pua.example.com
CSeq: 1 REGISTER
Contact: <sip:id@pua.example.com;methods=MESSAGE>
;description="open"
Contact: <sip:id@pua.example.com;methods=QAUTH>
Expires: 600
F3 SUBSCRIBE watcher->server
SUBSCRIBE sip:resource@example.com SIP/2.0
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <sip:user@example.com>
To: Resource <sip:resource@example.com>
Call-ID: 3248546@watcherhost.example.com
CSeq: 1 SUBSCRIBE
Expires: 600
Contact: sip:user@watcherhost.example.com
F4 202 Accepted server->watcher
SIP/2.0 202 Accepted
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <sip:user@example.com>
To: Resource <sip:resource@example.com>
Call-ID: 3248546@watcherhost.example.com
CSeq: 1 SUBSCRIBE
Expires: 600
F5 QAUTH server->PUA
QAUTH sip:id@pua.example.com SIP/2.0
Via: SIP/2.0/UDP server.example.com:5060
From: User <sip:user@example.com>
To: Resource <sip:resource@example.com>
Call-ID: 2874@server.example.com
CSeq: 1 QAUTH
Expires: Sun, 14 Jun 2036 00:00:00 GMT
Contact: sip:server.example.com
F6 200 OK PUA->server
SIP/2.0 200 OK
Via: SIP/2.0/UDP server.example.com:5060
From: User <sip:user@example.com>
To: Resource <sip:resource@example.com>
Call-ID: 2874@server.example.com
CSeq: 1 QAUTH
Expires: Sun, 14 Jun 2036 00:00:00 GMT
F7 NOTIFY server->watcher
NOTIFY sip:user@watcherhost.example.com SIP/2.0
Via: SIP/2.0/UDP server.example.com:5060
From: <sip:resource@example.com>
To: <sip:user@example.com>
Call-ID: 3248546@watcherhost.example.com
CSeq: 1 NOTIFY
Content-Type: text/lpidf
Content-Length: 111
To: sip:resource@example.com
Contact: <sip:resource@example.com;method=MESSAGE>
; description="open"
F8 200 OK
SIP/2.0 200 OK
Via: SIP/2.0/UDP server.example.com:5060
From: <sip:resource@example.com>
To: <sip:user@example.com>
Call-ID: 3248546@watcherhost.example.com
CSeq: 1 NOTIFY
F9 REGISTER PUA->server
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com:5060
To: <sip:resource@example.com>
From: <sip:resource@example.com>
Call-ID: 12@pua.example.com
CSeq: 2 REGISTER
Contact: <sip:id@pua.example.com;methods=MESSAGE>
;description="hiding in storm shelter"
Contact: <sip:id@pua.example.com;methods=QAUTH>
Expires: 600
F10 200 OK server->PUA
SIP/2.0 200 OK
Via: SIP/2.0/UDP pua.example.com:5060
To: <sip:resource@example.com>
From: <sip:resource@example.com>
Call-ID: 12@pua.example.com
CSeq: 2 REGISTER
Contact: <sip:id@pua.example.com;methods=MESSAGE>
;description="hiding in storm shelter"
Contact: <sip:id@pua.example.com;methods=QAUTH>
Expires: 600
F11 NOTIFY server->watcher
NOTIFY sip:user@watcherhost.example.com SIP/2.0
Via: SIP/2.0/UDP server.example.com:5060
From: <sip:resource@example.com>
To: <sip:user@example.com>
Call-ID: 3248546@watcherhost.example.com
CSeq: 2 NOTIFY
Content-Type: text/lpidf
Content-Length: 131
To: sip:resource@example.com
Contact: <sip:resource@example.com;method=MESSAGE>
; description="hiding in storm shelter"
F12 200 OK watcher->server
SIP/2.0 200 OK
Via: SIP/2.0/UDP server.example.com:5060
From: <sip:resource@example.com>
To: <sip:user@example.com>
Call-ID: 3248546@watcherhost.example.com
CSeq: 2 NOTIFY
F13 SUBSCRIBE watcher->server
SUBSCRIBE sip:resource@example.com SIP/2.0
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <sip:user@example.com>
To: Resource <sip:resource@example.com>
Call-ID: 3248546@watcherhost.example.com
CSeq: 2 SUBSCRIBE
Expires: 0
Contact: sip:user@watcherhost.example.com
F14 200 OK server->watcher
SIP/2.0 200 OK
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <sip:user@example.com>
To: Resource <sip:resource@example.com>
Call-ID: 3248546@watcherhost.example.com
CSeq: 2 SUBSCRIBE
Content-Type: text/lpidf
Content-Length: 131
To: sip:resource@example.com
Contact: <sip:resource@example.com;method=MESSAGE>
; description="hiding in storm shelter"
13.5 Delayed Subscription Approval
The call flow is similar to 13.4 with the difference being that the
client is currently offline.
A watcher subscribes to a resource for which the server but has not
been authorized and a PUA for that resource is not available. The
server queues the request until a PUA becomes available. The PUA
grants permission, but since the original subscription had expired,
the server does not generate a NOTIFY. The watcher subscribes again,
after the REGISTER has expired, and has its subscription approved.
Note that since there are no contacts registered for the resource at
that time, the presence document is vacuous.
watcher server PUA
| | |
| F1 SUBSCRIBE | |
|--------------------->| (PUA not "online") |
| F2 202 Accepted | |
|<---------------------| |
| (subscription expires) |
| | F3 REGISTER |
| |<--------------------|
| | F4 200 OK |
| |-------------------->|
| | F5 QAUTH |
| |-------------------->|
| | F6 200 OK |
| |<--------------------|
| (registration expires)|
| F7 SUBSCRIBE | |
|--------------------->| |
| F8 200 OK | |
|<---------------------| |
Message Details
F1 SUBSCRIBE watcher->server
SUBSCRIBE sip:resource@example.com SIP/2.0
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <sip:user@example.com>
To: Resource <sip:resource@example.com>
Call-ID: 3248543@watcherhost.example.com
CSeq: 1 SUBSCRIBE
Date: Mon, 12 Jun 2000 16:00:00 GMT
Expires: 600
Contact: sip:user@watcherhost.example.com
F2 202 Accepted server->watcher
SIP/2.0 202 Accepted
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <sip:user@example.com>
To: Resource <sip:resource@example.com>
Call-ID: 3248543@watcherhost.example.com
CSeq: 1 SUBSCRIBE
Expires: 600
F3 REGISTER PUA->server
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com:5060
To: <sip:resource@example.com>
From: <sip:resource@example.com>
Call-ID: 2001@pua.example.com
CSeq: 1 REGISTER
Date: Wed, 14 Jun 2000 09:57:16 GMT
Contact: <sip:id@pua.example.com;methods=MESSAGE;
description="open">
Contact: <sip:id@pua.example.com;methods=QAUTH>
Expires: 600
F4 200 OK server->PUA
SIP/2.0 200 OK
Via: SIP/2.0/UDP pua.example.com:5060
To: <sip:resource@example.com>
From: <sip:resource@example.com>
Call-ID: 2001@pua.example.com
CSeq: 1 REGISTER
Contact: <sip:id@pua.example.com;methods=MESSAGE;
description="open">
Contact: <sip:id@pua.example.com;methods=QAUTH>
Expires: 600
F5 QAUTH server->PUA
QAUTH sip:id@pua.example.com SIP/2.0
Via: SIP/2.0/UDP server.example.com:5060
From: User <sip:user@example.com>
To: Resource <sip:resource@example.com>
Call-ID: 47774@server.example.com
CSeq: 1 QAUTH
Expires: Sun, 14 Jun 2036 00:00:00 GMT
Contact: sip:server.example.com
F6 200 OK PUA->server
SIP/2.0 200 OK
Via: SIP/2.0/UDP server.example.com:5060
From: User <sip:user@example.com>
To: Resource <sip:resource@example.com>
Call-ID: 47774@server.example.com
CSeq: 1 QAUTH
Expires: Sun, 14 Jun 2036 00:00:00 GMT
F7 SUBSCRIBE watcher->server
SUBSCRIBE sip:resource@example.com SIP/2.0
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <sip:user@example.com>
To: Resource <sip:resource@example.com>
Call-ID: 3248544@watcherhost.example.com
CSeq: 1 SUBSCRIBE
Date: Thu, 15 Jun 2000 07:22:15 GMT
Expires: 600
Contact: sip:user@watcherhost.example.com
F8 200 OK server->watcher
SIP/2.0 200 OK The following is the list of known open issues:
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <sip:user@example.com>
To: Resource <sip:resource@example.com>
Call-ID: 3248544@watcherhost.example.com
CSeq: 1 SUBSCRIBE
Expires: 600
Content-Type: text/lpidf
Content-Length: 31
To: sip:resource@example.com o This draft recommends that the To and From field are populated
with presence URLs rather than sip URLs. Is that reasonable?
Will this lead to incompatibilities in proxies? Is there any
issues with CPIM if the SIP URL format is used? This depends
on what components of a message are signed in CPIM.
14 Checklist of requirements o Rate limitations on NOTIFY: do we want that? How do we pick a
value? 5 seconds is arbitrary.
This section examines the requirements for presence, as specified in o Merging of presence data from multiple PA has been removed. Is
RFC2779 [18], and indicates how each requirement is addressed by this that OK?
extension. Only the requirements related to presence are discussed
here. Requirements for instant messaging are discussed in [19] and
presence data formats in [10,11].
"Requirement 2.1.1. The protocols MUST allow a PRESENCE SERVICE o Placing IM URLs in the Contact header of a REGISTER: is that
to be available independent of whether an INSTANT MESSAGE OK? What does it mean?
SERVICE is available, and vice-versa." Presence and IM are
supported by completely separate protocols, and do not
depend on each other.
"Requirement 2.1.2. The protocols must not assume that an o The process of migrating subscriptions from a presence server
INSTANT INBOX is necessarily reached by the same IDENTIFIER to PUA is not likely to work in the case where subscription
as that of a PRESENTITY. Specifically, the protocols must refreshes use tags and Route headers. So, we have a choice.
assume that some INSTANT INBOXes may have no associated Either migration is disallowed, and we keep with leg oriented
PRESENTITIES, and vice versa." The complete separation of subscriptions, or migration is allowed, and there is no tags
IM and presence allows different identifiers to be used for or Route's associated with subscriptions.
each.
"Requirement 2.1.3. The protocols MUST also allow an INSTANT o Converting SIP URLs back to pres URLs.
INBOX to be reached via the same IDENTIFIER as the
IDENTIFIER of some PRESENTITY." The architecture provided
here allows for the IM and presence identifiers to be the
same, if so desired.
"Requirement 2.1.4. The administration and naming of ENTITIES o The SIP to CPIM and CPIM to SIP gateways are not stateless,
within a given DOMAIN MUST be able to operate independently because of the need to maintain Route, Call-ID, CSeq, and
of actions in any other DOMAIN." This requirement is met by other parameters. Perhaps we can ask CPIM to define a token
SIP. SIP uses email-like identifiers which consist of a value which is sent in a CPIM request and returned in a CPIM
user name at a domain. Administration of user names is done response. Would that help?
completely within the domain, and these user names have no
defined rules or organization that needs to be known
outside of the domain in order for SIP to operate.
"Requirement 2.1.5. The protocol MUST allow for an arbitrary o Need to specify how to take Contacts from REGISTER and build a
number of DOMAINS within the NAMESPACE." This requirement presence document. One obvious thing is that the contact
is met by SIP. SIP uses standard DNS domains, which are not addresses don't go in there directly; you probably want to put
restricted in number. the address of record, otherwise calls might not go through
the proxy.
"Requirement 2.2.1. It MUST be possible for ENTITIES in one 12 Changes from -00
DOMAIN to interoperate with ENTITIES in another DOMAIN,
without the DOMAINS having previously been aware of each
other." This requirement is met by SIP, as it is essential
for establishing sessions as well. DNS SRV [20] records are
used to discover servers for a particular service within a
domain. They are a generalization of MX records, used for
email routing. SIP defines procedures for usage of DNS
records to find servers in another domains, which include
SRV lookups. This allows domains to communication without
prior setup.
"Requirement 2.2.2: The protocol MUST be capable of meeting its The document has been completely rewritten, to reflect the change
other functional and performance requirements even when from a sales pitch and educational document, to a more formal
there are millions of ENTITIES within a single DOMAIN." protocol specification. It has also been changed to align with the
Whilst it is hard to judge whether this can be met by SIP event architecture and with CPIM. The specific protocol changes
examining the architecture of a protocol, SIP has numerous resulting from this rewrite are:
mechanisms for achieving large scales of users within a
domain. It allows hierarchies of servers, whereby the
namespace can be partitioned among servers. Servers near
the top of the hierarchy, used solely for routing, can be
stateless, providing excellent scale.
"Requirement 2.2.3: The protocol MUST be capable of meeting its o The Event header must now be used in the SUBSCRIBE and NOTIFY
other functional and performance requirements when there requests.
are millions of DOMAINS within the single NAMESPACE." The
usage of DNS for dividing the namespace into domains
provides the same scale as todays email systems, which
support millions of DOMAINS.
"Requirement 2.2.4: The protocol MUST be capable of meeting its o The SUBSCRIBE message can only have a single Contact header.
other functional and performance requirements when every -00 allowed for more than one.
single SUBSCRIBER has SUBSCRIPTIONS to hundreds of
PRESENTITIES." Section 9 discusses the means by which our
extension provides scale.
"Requirement 2.2.5: The protocol MUST be capable of meeting its o The From and To headers can contain presence URIs.
other functional and performance requirements when hundreds
of distinct SUBSCRIBERS have SUBSCRIPTIONS to a single
PRESENTITY." Section 9 discusses the means by which our
extension provides scale.
"Requirement 2.2.6: The protocol MUST be capable of meeting its o The Request-URI can contain a presence URI.
other functional and performance requirements when every
single SUBSCRIBER has SUBSCRIPTIONS to PRESENTITIES in
hundreds of distinct DOMAINS." Section 9 discusses the
means by which our extension provides scale.
"Requirement 2.4.1: The protocol MUST allow the creation of a o Subscriptions are responded to with a 202 if they are pending
SUBSCRIPTION both directly and via intermediaries, such as or accepted.
PROXIES." SIP supports proxies, but they are optional. User
agents can communicate directly. This feature is inherited
by this extension.
"Requirement 2.4.2: The protocol MUST allow the sending of a o Presence documents are not returned in the body of the
NOTIFICATION both directly and via intermediaries, such as SUBSCRIBE response. Rather, they are sent in a separate
PROXIES." The use of Record-Routing described here, and in NOTIFY. This more cleanly separates subscription and
RFC2543 [2] means that notifications can go directly from notification, and is mandated by alignment with CPIM.
presence agent to subscriber, or through proxies, as the
policy of each proxy dictates.
"Requirement 2.4.4: The protocol proxying facilities and o Authentication is now mandatory at the PA. Authorization is
transport practices MUST allow ADMINISTRATORS ways to now mandatory at the PA.
enable and disable protocol activity through existing and
commonly-deployed FIREWALLS. The protocol MUST specify how
it can be effectively filtered by such FIREWALLS." Although
SIP itself runs on port 5060 by default, any other port can
be used. It is simple to specify that presence should run
on a different port, if so desired.
"Requirement 2.5.1: The protocol MUST provide means to ensure o Fake NOTIFY is sent for pending or rejected subscriptions.
confidence that a received message (NOTIFICATION or INSTANT
MESSAGE) has not been corrupted or tampered with." SIP
provides end to end authentication and message integrity
using PGP; other mechanisms can be specified.
"Requirement 2.5.2. The protocol MUST provide means to ensure o A rate limit on notifications was introduced.
confidence that a received message (NOTIFICATION or INSTANT
MESSAGE) has not been recorded and played back by an
adversary." Replay attacks can be prevented through either
challenge-response authentication, timestamp based checks,
or storage of previously used sequence numbers and
transaction identifiers. See Section 10.4.
"Requirement 2.5.3: The protocol MUST provide means to ensure o Merging of presence data has been removed.
that a sent message (NOTIFICATION or INSTANT MESSAGE) is
only readable by ENTITIES that the sender allows." SIP
provides end-to-end encryption using PGP.
"Requirement 2.5.4: The protocol MUST allow any client to use o The subscriber rejects notifications received with tags that
the means to ensure non-corruption, non-playback, and don't match those in the 202 response to the SUBSCRIBE. This
privacy, but the protocol MUST NOT require that all clients means that only one PA will hold subscription state for a
use these means at all times." SIPs security mechanisms are particular subscriber for a particular presentity.
optional.
"Requirement 3.1.1: All ENTITIES MUST produce and consume at o IM URLs allowed in Contacts in register
least a common base format for PRESENCE INFORMATION." Here,
we mandate the Lightweight Presence Information Data Format
(LPIDF) [10].
"Requirement 3.2.1. A FETCHER MUST be able to fetch a o CPIM mappings defined.
PRESENTITY's PRESENCE INFORMATION even when the PRESENTITY
is OUT OF CONTACT." The extension described here defines a
fetch operation that can be made on a presence server; this
server handles subscriptions and fetches when a presence
client is not available.
"Requirement 3.2.2: A SUBSCRIBER MUST be able to request a o Persistent connections recommended for firewall traversal.
SUBSCRIPTION to a PRESENTITY's PRESENCE INFORMATION, even
when the PRESENTITY is OUT OF CONTACT." Subscriptions are
handled by a presence server when the presence client is
not available.
"Requirement 3.2.3: If the PRESENCE SERVICE has SUBSCRIPTIONS Obtaining Authorization
for a PRESENTITY's PRESENCE INFORMATION, and that PRESENCE
INFORMATION changes, the PRESENCE SERVICE MUST deliver a
NOTIFICATION to each SUBSCRIBER, unless prevented by the
PRESENTITY's ACCESS RULES." This is supported as described
in Section 7.
"Requirement 3.2.4. The protocol MUST provide a mechanism for When a subscription arrives at a PA, the subscription needs to be
detecting when a PRESENTITY or SUBSCRIBER has gone OUT OF authorized by the presentity. In some cases, the presentity may have
CONTACT." The SIP REGISTER method is used for this purpose. provided authorization ahead of time. However, in many cases, the
subscriber is not pre-authorized. In that case, the PA needs to query
the presentity for authorization.
"Requirement 3.2.5: The protocol MUST NOT depend on a PRESENTITY In order to do this, we define an implicit subscription at the PA.
or SUBSCRIBER gracefully telling the service that it will This subscription is for a virtual presentity, which is the "set of
no longer be in communication, since a PRESENTITY or subscriptions for presentity X", and the subscriber to that virtual
SUBSCRIBER may go OUT OF CONTACT due to unanticipated presentity is X itself. Whenever a subscription is received for X,
failures." Registrations are soft state, and will timeout the virtual presentity changes state to reflect the new subscription
if not refreshed. for X. This state changes for subscriptions that are approved and for
ones that are pending. As a result of this, when a subscription
arrives for which authorization is needed, the state of the virtual
presentity changes to indicate a pending subscription. The entire
state of the virtual presentity is then sent to the subscriber (the
presentity itself). This way, the user behind that presentity can see
that there are pending subscriptions. It can then use some non-SIP
means to install policy in the server regarding this new user. This
policy is then used to either accept or reject the subscription.
"Requirement 3.3.1: The protocol MUST include mechanisms to A call flow for this is shown in Figure 3.
allow PRESENCE INFORMATION to be cached." Although not
explicitly described here, this is easily supported as an
implementation improvement.
"Requirement 3.3.2: The protocol MUST include mechanisms to In the case where the presentity is not online, the problem is also
allow cached PRESENCE INFORMATION to be updated when the straightforward. When the user logs into their presence client, it
master copy changes." Presence data contains timestamps can fetch the state of the virtual presentity for X, check for
which indicate its expiration; this forces a fetch to go to pending subscriptions, and for each of them, upload a new policy
the PA after expiration. which indicates the appropriate action to take.
"Requirement 3.3.3: The protocol caching facilities MUST NOT A data format to represent the state of these virtual presentities
circumvent established ACCESS RULES or restrict choice of can be found in [14].
authentication/encryption mechanisms." The protocol does
not explicitly circumvent access rules when caching is
used; however, if the caching server does not choose to
authenticate or authorize subscribers, no protocol in the
world can prevent this.
"Requirement 3.4.1 When a PRESENTITY changes its PRESENCE A Acknowledgements
INFORMATION, any SUBSCRIBER to that information MUST be
notified of the changed information rapidly, except when
such notification is entirely prevented by ACCESS RULES.
This requirement is met if each SUBSCRIBER's NOTIFICATION
is transported as rapidly as an INSTANT MESSAGE would be
transported to an INSTANT INBOX." SIP is engineered for
rapid transfer of messages. In fact, SIP (and the presence
extension) allows notifications to go directly from
presence agent to subscriber.
15 Acknowledgements
We would like to thank the following people for their support and We would like to thank the following people for their support and
comments on this draft: comments on this draft:
Rick Workman Nortel Rick Workman Nortel
Adam Roach Ericsson Adam Roach Ericsson
Sean Olson Ericsson Sean Olson Ericsson
Billy Biggs University of Waterloo Billy Biggs University of Waterloo
Stuart Barkley UUNet Stuart Barkley UUNet
Mauricio Arango SUN Mauricio Arango SUN
Richard Shockey Shockey Consulting LLC Richard Shockey Shockey Consulting LLC
Jorgen Bjorkner Hotsip Jorgen Bjorkner Hotsip
Henry Sinnreich MCI Worldcom Henry Sinnreich MCI Worldcom
Ronald Akers Motorola Ronald Akers Motorola
16 Authors Addresses B Authors Addresses
Jonathan Rosenberg Jonathan Rosenberg
| SUBSCRIBE X | |
| -------------------> | |
| | |
| 202 Accepted | |
| <------------------- | NOTIFY X-subscriptions|
| |---------------------->|
| | |
| | 200 OK |
| |<----------------------|
| | |
| | |
| | HTTP POST w/ policy |
| |<----------------------|
| | |
| | 200 OK |
| |---------------------->|
| | |
| | |
| | |
Figure 3: Sequence diagram for online authorization
dynamicsoft dynamicsoft
200 Executive Drive 72 Eagle Rock Avenue
Suite 120 First Floor
West Orange, NJ 07052 East Hanover, NJ 07936
email: jdrosen@dynamicsoft.com email: jdrosen@dynamicsoft.com
Dean Willis Dean Willis
dynamicsoft dynamicsoft
200 Executive Drive 5100 Tennyson Parkway
Suite 120 Suite 1200
West Orange, NJ 07052 Plano, Texas 75024
email: dwillis@dynamicsoft.com email: dwillis@dynamicsoft.com
Robert Sparks Robert Sparks
dynamicsoft dynamicsoft
200 Executive Drive 5100 Tennyson Parkway
Suite 120 Suite 1200
West Orange, NJ 07052 Plano, Texas 75024
email: rsparks@dynamicsoft.com email: rsparks@dynamicsoft.com
Ben Campbell Ben Campbell
dynamicsoft 5100 Tennyson Parkway
200 Executive Drive Suite 1200
Suite 120 Plano, Texas 75024
West Orange, NJ 07052
email: bcampbell@dynamicsoft.com email: bcampbell@dynamicsoft.com
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
M/S 0401 M/S 0401
1214 Amsterdam Ave. 1214 Amsterdam Ave.
New York, NY 10027-7003 New York, NY 10027-7003
email: schulzrinne@cs.columbia.edu email: schulzrinne@cs.columbia.edu
Jonathan Lennox Jonathan Lennox
skipping to change at page 70, line 41 skipping to change at page 37, line 20
One Microsoft Way One Microsoft Way
Redmond, WA 98052-6399 Redmond, WA 98052-6399
email: dgurle@microsoft.com email: dgurle@microsoft.com
David Oran David Oran
Cisco Systems Cisco Systems
170 West Tasman Dr. 170 West Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
email: oran@cisco.com email: oran@cisco.com
17 Bibliography C Bibliography
[1] M. Day, J. Rosenberg, and H. Sugano, "A model for presence and [1] M. Day, J. Rosenberg, and H. Sugano, "A model for presence and
instant messaging," Request for Comments 2778, Internet Engineering instant messaging," Request for Comments 2778, Internet Engineering
Task Force, Feb. 2000. Task Force, Feb. 2000.
[2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
session initiation protocol," Request for Comments 2543, Internet session initiation protocol," Request for Comments 2543, Internet
Engineering Task Force, Mar. 1999. Engineering Task Force, Mar. 1999.
[3] H. Schulzrinne and J. Rosenberg, "SIP caller preferences and [3] A. Roach, "Event notification in SIP," Internet Draft, Internet
callee capabilities," Internet Draft, Internet Engineering Task Engineering Task Force, Oct. 2000. Work in progress.
Force, Mar. 2000. Work in progress.
[4] M. Handley and V. Jacobson, "SDP: session description protocol,"
Request for Comments 2327, Internet Engineering Task Force, Apr.
1998.
[5] R. Stewart et al. , "Simple control transmission protocol,"
Internet Draft, Internet Engineering Task Force, Apr. 2000. Work in
progress.
[6] J. Rosenberg and H. Schulzrinne, "SCTP as a transport for SIP,"
Internet Draft, Internet Engineering Task Force, June 2000. Work in
progress.
[7] S. Kent and R. Atkinson, "IP encapsulating security payload
(ESP)," Request for Comments 2406, Internet Engineering Task Force,
Nov. 1998.
[8] D. Harkins and D. Carrel, "The internet key exchange (IKE),"
Request for Comments 2409, Internet Engineering Task Force, Nov.
1998.
[9] J. Rosenberg, R. Sparks, D. Willis, B. Campbell, H. Schulzrinne, [4] D. Crocker et al. , "A common profile for instant messaging
J. Lennox, C. Huitema, B. Aboba, and D. Gurle, "SIP extensions for (CPIM)," Internet Draft, Internet Engineering Task Force, Nov. 2000.
presence authorization," Internet Draft, Internet Engineering Task Work in progress.
Force, June 2000. Work in progress.
[10] J. Rosenberg, R. Sparks, D. Willis, B. Campbell, H. Schulzrinne, [5] P. Calhoun, A. Rubens, H. Akhtar, and E. Guttman, "DIAMETER base
J. Lennox, C. Huitema, B. Aboba, and D. Gurle, "A lightweight protocol," Internet Draft, Internet Engineering Task Force, Sept.
presence information data format (LPIDF)," Internet Draft, Internet 2000. Work in progress.
Engineering Task Force, June 2000. Work in progress.
[11] J. Rosenberg, R. Sparks, D. Willis, B. Campbell, H. Schulzrinne, [6] C. Rigney, S. Willens, A. Rubens, and W. Simpson, "Remote
J. Lennox, C. Huitema, B. Aboba, and D. Gurle, "A data format for authentication dial in user service (RADIUS)," Request for Comments
presence using XML," Internet Draft, Internet Engineering Task Force, 2865, Internet Engineering Task Force, June 2000.
June 2000. Work in progress.
[12] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Rajan, and A. [7] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Rajan, and A.
Sastry, "The COPS (common open policy service) protocol," Request for Sastry, "The COPS (common open policy service) protocol," Request for
Comments 2748, Internet Engineering Task Force, Jan. 2000. Comments 2748, Internet Engineering Task Force, Jan. 2000.
[13] J. Lennox and H. Schulzrinne, "CPL: a language for user control [8] H. Schulzrinne and J. Rosenberg, "SIP caller preferences and
of internet telephony services," Internet Draft, Internet Engineering callee capabilities," Internet Draft, Internet Engineering Task
Task Force, Mar. 1999. Work in progress. Force, July 2000. Work in progress.
[14] J. Lennox and H. Schulzrinne, "Transporting user control [9] J. Rosenberg, D. Drew, and H. Schulzrinne, "Getting SIP through
information in sip register payloads," Internet Draft, Internet firewalls and NATs," Internet Draft, Internet Engineering Task Force,
Engineering Task Force, Mar. 2000. Work in progress. Feb. 2000. Work in progress.
[15] T. Dierks and C. Allen, "The TLS protocol version 1.0," Request [10] J. Rosenberg and H. Schulzrinne, "SIP traversal through
enterprise and residential NATs and firewalls," Internet Draft,
Internet Engineering Task Force, Nov. 2000. Work in progress.
[11] S. Kent and R. Atkinson, "IP encapsulating security payload
(ESP)," Request for Comments 2406, Internet Engineering Task Force,
Nov. 1998.
[12] T. Dierks and C. Allen, "The TLS protocol version 1.0," Request
for Comments 2246, Internet Engineering Task Force, Jan. 1999. for Comments 2246, Internet Engineering Task Force, Jan. 1999.
[16] B. Ramsdell and Ed, "S/MIME version 3 message specification," [13] B. Ramsdell and Ed, "S/MIME version 3 message specification,"
Request for Comments 2633, Internet Engineering Task Force, June Request for Comments 2633, Internet Engineering Task Force, June
1999. 1999.
[17] J. Rosenberg and H. Schulzrinne, "SIP extensions for managing [14] J. Rosenberg et al. , "An XML based format for watcher
persistent connections," Internet Draft, Internet Engineering Task information," Internet Draft, Internet Engineering Task Force, June
Force, June 2000. Work in progress. 2000. Work in progress.
[18] M. Day, S. Aggarwal, G. Mohr, and J. Vincent, "Instant messaging
/ presence protocol requirements," Request for Comments 2779,
Internet Engineering Task Force, Feb. 2000.
[19] J. Rosenberg, R. Sparks, D. Willis, B. Campbell, H. Schulzrinne,
J. Lennox, C. Huitema, B. Aboba, and D. Gurle, "SIP extensions for
instant messaging," Internet Draft, Internet Engineering Task Force,
June 2000. Work in progress.
[20] A. Gulbrandsen, P. Vixie, and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)," Request for Comments
2782, Internet Engineering Task Force, Feb. 2000.
Table of Contents Table of Contents
1 Introduction ........................................ 1 1 Introduction ........................................ 1
2 Why use SIP as a base protocol for presence? ....... 3 2 Definitions ......................................... 2
3 Definitions ......................................... 6 3 Overview of Operation ............................... 3
4 Overview of Operation ............................... 8 4 Naming .............................................. 4
4.1 Architecture ........................................ 8 5 Presence Event Package .............................. 5
4.2 Message Flow ........................................ 8 5.1 Package Name ........................................ 5
5 Subscriptions ....................................... 16 5.2 SUBSCRIBE bodies .................................... 5
5.1 Generating subscriptions ............................ 16 5.3 Expiration .......................................... 5
5.2 Sending subscriptions ............................... 19 5.4 NOTIFY Bodies ....................................... 6
5.3 Proxying subscriptions .............................. 20 5.5 Processing Requirements at the PA ................... 6
5.4 Presence server processing of SUBSCRIBE ............. 20 5.6 Generation of Notifications ......................... 7
5.5 Presence agent processing of SUBSCRIBE .............. 21 5.7 Rate Limitations on NOTIFY .......................... 8
5.5.1 Refreshes ........................................... 21 5.8 Refresh Behavior .................................... 9
5.5.2 New subscriptions ................................... 22 6 Publication ......................................... 9
5.6 Subscriber processing of SUBSCRIBE response ......... 23 6.1 Migrating the PA Function ........................... 10
5.7 Unsubscribing ....................................... 24 7 Mapping to CPIM ..................................... 11
5.8 Fetching ............................................ 24 7.1 SIP to CPIM ......................................... 11
6 Publication ......................................... 24 7.2 CPIM to SIP ......................................... 14
7 Notification ........................................ 26 8 Firewall and NAT Traversal .......................... 16
7.1 When to send ........................................ 26 9 Security considerations ............................. 17
7.2 Formatting of NOTIFY ................................ 27 9.1 Privacy ............................................. 17
7.3 Responding to NOTIFY ................................ 28 9.2 Message integrity and authenticity .................. 18
8 Access controls ..................................... 28 9.3 Outbound authentication ............................. 18
9 Providing scalability ............................... 29 9.4 Replay prevention ................................... 18
9.1 Partitioning of the namespace ....................... 30 9.5 Denial of service attacks ........................... 19
9.2 Client notifications ................................ 31 9.5.1 Smurf attacks through false contacts ................ 19
9.3 Distributed subscription state ...................... 31 10 Example message flows ............................... 19
10 Security considerations ............................. 34 10.1 Client to Client Subscription with Presentity
10.1 Privacy ............................................. 34 State Changes .................................................. 19
10.2 Message integrity and authenticity .................. 35 10.2 Presence Server with Client Notifications ........... 23
10.3 Outbound authentication ............................. 35 10.3 Presence Server Notifications ....................... 28
10.4 Replay prevention ................................... 36 11 Open Issues ......................................... 32
10.5 Denial of service attacks ........................... 36 12 Changes from -00 .................................... 32
10.5.1 Smurf attacks through false contacts ................ 36 A Acknowledgements .................................... 34
10.5.2 Annoyance subscriptions ............................. 37 B Authors Addresses ................................... 34
10.6 Firewall traversal .................................. 37 C Bibliography ........................................ 37
11 Addressing Transport ................................ 37
12 Required SIP features ............................... 39
12.1 Needed components ................................... 39
12.2 Components not needed ............................... 40
13 Example message flows ............................... 41
13.1 Client to Client Subscription with Presentity
State Changes .................................................. 41
13.2 Presence Server with Client Notifications ........... 45
13.3 Presence Server Notifications ....................... 51
13.4 Presence Server Notifications with Client
Authorization of Subscription .................................. 54
13.5 Delayed Subscription Approval ....................... 60
14 Checklist of requirements ........................... 64
15 Acknowledgements .................................... 68
16 Authors Addresses ................................... 69
17 Bibliography ........................................ 70
 End of changes. 292 change blocks. 
2412 lines changed or deleted 891 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/