Internet Draft
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
Christian Huitema
David Gurle
Microsoft
Dave Oran
Cisco
draft-rosenberg-impp-presence-00.txt
June 15, 2000
Expires: December, 2000
SIP Extensions for Presence
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as work in progress.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document proposes an extension to SIP for subscriptions and
notifications of user presence. Traditional SIP clients already make
use of the REGISTER method to upload presence state to network
servers, in order to enable call establishment. This extension allows
that data to be published to subscribers. This is accomplished by
defining two new SIP methods - SUBSCRIBE and NOTIFY, and by defining
a new logical entity, the presence agent (PA), which handles
subscriptions and notifications.
1 Introduction
Presence is (indirectly) defined in RFC2778 [1] as subscription to
and notification of changes in the communications state of a user.
This communications state consists of the set of communications
Rosenberg et al. [Page 1]
Internet Draft presence June 15, 2000
means, communications address, and status of that user. A presence
protocol is a protocol for providing such a service over the Internet
or any IP network.
This document proposes an extension to the Session Initiation
Protocol (SIP) [2] for presence. Baseline SIP is used primarily for
initiation of interactive sessions, such as voice, video, and games.
The process of session initiation requires a system which uses the
communications means, communications addresses, and communications
status of a user in order to determine the host where initiation
requests can be delivered. A presence system is one where this
information is pushed to subscribers through notification requests,
as opposed to being pulled by proxy and redirect servers when session
establishment is desired. In a sense, this makes presence and session
initiation "duals" - one is synchronous (presence systems push data
the instant it changes) and the other is asynchronous (servers access
presence data for a user at the point where a call is initiated to
that user). The similarities between presence and communications
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
Rosenberg et al. [Page 2]
Internet Draft presence June 15, 2000
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
Rosenberg et al. [Page 3]
Internet Draft presence June 15, 2000
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
Rosenberg et al. [Page 4]
Internet Draft presence June 15, 2000
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.
Rosenberg et al. [Page 5]
Internet Draft presence June 15, 2000
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
sessions. A widely varying set of devices is likely to make
use of such services, including PCs, wireless PDAs (in
fact, the 3GPP wireless standards body has already chosen
SIP as the signaling platform for third generation wireless
devices), standalone phones, cell phones, laptops, and even
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
network must be periodically refreshed in order for it to
remain present. This soft state mechanism provides
robustness against system crashes. The period of refresh
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
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
Rosenberg et al. [Page 6]
Internet Draft presence June 15, 2000
This document uses the terms as defined in [1]. Additionally, the
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 information for a presentity. In SIP terms, this
means that a PUA generates REGISTER requests, conveying
some kind of information about the presentity. We
explicitly allow multiple PUAs per presentity. This means
that a user can have many devices (such as a cell phone and
PDA), each of which is independently generating a component
of the overall presence information for a presentity. PUAs
push data into the presence system, but are outside of it,
in that they do not receive SUBSCRIBE messages, or send
NOTIFY.
Presence Agent (PA): A presence agent is a SIP user agent which
is capable of receiving SUBSCRIBE requests, responding to
them, and generating notifications of changes in presence
state. A presence agent must have complete knowledge of the
presence state of a presentity. Typically, this is
accomplished by co-locating the PA with the
proxy/registrar, or the presence user agent of the
presentity. A PA is always addressable with a SIP URL.
Presence Server: A presence server is a presence agent that is
colocated with a proxy/registrar. It is aware of the
presence information of the presentity through some
protocol means. This protocol means can be SIP REGISTER
requests, but other mechanisms are allowed.
Rosenberg et al. [Page 7]
Internet Draft presence June 15, 2000
Presence Client: A presence client is a presence agent that is
colocated with a PUA. It is aware of the presence
information of the presentity because it is co-located with
the entity that manipulates this presence information.
4 Overview of Operation
In this section, we present an overview of the operation of this
extension. It defines two new methods, SUBSCRIBE (for subscribing to
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
Rosenberg et al. [Page 8]
Internet Draft presence June 15, 2000
+-------+
| |
/\| 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
Rosenberg et al. [Page 9]
Internet Draft presence June 15, 2000
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
Rosenberg et al. [Page 10]
Internet Draft presence June 15, 2000
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.
Rosenberg et al. [Page 11]
Internet Draft presence June 15, 2000
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
Rosenberg et al. [Page 12]
Internet Draft presence June 15, 2000
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
Rosenberg et al. [Page 13]
Internet Draft presence June 15, 2000
CSeq: 1 SUBSCRIBE
Content-Type: application/xpidf+xml
Content-Length: 287
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:
Rosenberg et al. [Page 14]
Internet Draft presence June 15, 2000
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
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.
Rosenberg et al. [Page 15]
Internet Draft presence June 15, 2000
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
Rosenberg et al. [Page 16]
Internet Draft presence June 15, 2000
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.
Rosenberg et al. [Page 17]
Internet Draft presence June 15, 2000
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
addition of tag; (2): UAS removes first Via header field
A subscription is uniquely identified by the combination of the To,
Call-ID and the From field in the SUBSCRIBE request. Refreshes of
subscriptions SHOULD reuse the same Call-ID if possible, since
subscriptions are uniquely identified at presence servers using the
Call-ID. Two subscriptions from the same user, for the same user, but
with different Call-IDs, are considered different subscriptions. We
anticipate that reuse of the same Call-ID will not be possible
through reboot cycles. This is acceptable, however. The soft-state
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 CSeq header MUST increment for each subsequent request for the
same To, From, and Call-ID field (thus, the CSeq in each refresh MUST
increase). The CSeq header uniquely identifies and orders each
refresh of a particular subscription.
Rosenberg et al. [Page 18]
Internet Draft presence June 15, 2000
A SUBSCRIBE request MUST contain a Via header, formatted as defined
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
address(es) (as a SIP URL) to which the client would like to receive
notifications. This MUST be be one or more SIP addresses, containing
the fully qualified domain names for the host generating the
subscription, or the IP address of the host generating the
subscription. Other addresses are possible, supporting third party
subscriptions. If it contains multiple addresses, notifications will
be sent to each address. If no Contact header is present, no
notifications will be sent.
The SUBSCRIBE request MAY contain a body, and when present, the
Content-Length, Content-Type, and Content-Encoding are used as
specified in [2]. There are many applications for bodies within a
SUBSCRIBE request - for example, providing more detailed information
about what the subscription is for. Derivation of semantics of the
purpose of the body is based on the Content-Type and Content-
Disposition headers.
A SUBSCRIBE request MAY contain an Accept header, indicating the
allowed presence description formats which may be returned in a
notification. When not present, the server assumes only the
lightweight presence format [10] is supported.
This extension does NOT neccessitate the use of either Require or
Proxy-Require. These headers SHOULD NOT be present unless some other
extensions are needed beyond this one.
Usage of the other headers specified as optional in Tables 1 and 2 is
defined in [2].
5.2 Sending subscriptions
The SUBSCRIBE request MAY be sent directly to the server identified
in the Request URI. Alternatively, it can be sent to a local outbound
proxy server. Usage of local outbound proxies is RECOMMENDED with
presence in order to provide security features.
An example subscription message looks like:
SUBSCRIBE sip:user@example.com SIP/2.0
Via: SIP/2.0/UDP myhost.example.com
From: Professor Smith
To: Joe User
Rosenberg et al. [Page 19]
Internet Draft presence June 15, 2000
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
Proxies forward SUBSCRIBE requests as they would any other request.
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
This section outlines the processing of a new subscription request
for a presentity served by a presence server.
When a SUBSCRIBE request arrives, the presence server SHOULD send a
100 Trying response.
The next job of the presence server is to determine if it will act as
a proxy for this subscription, or as a PA. Once this determination is
made, processing follows Section 5.3 in the case of a proxy, and
Section 5.5 in the case of a PA.
If the presentity identified in the request URI has at least one
registered Contact that indicates support of the SUBSCRIBE method,
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
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
Rosenberg et al. [Page 20]
Internet Draft presence June 15, 2000
(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
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
the presence client goes offline (by unregistering the Contact
address with the methods="SUBSCRIBE" tag), subscription refreshes
will now terminate at the presence server, causing the presence
server to act as a PA for those subscriptions. This will cause the
subscriptions to gradually become active at the presence server.
As an optimization, the presence server can cache the active
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 presence agent MAY authenticate the request (using a 401
response, NOT 407, since the PA is a user agent in SIP terminology).
Once authenticated, the PA determines if this is a subscription
refresh, or a new subscription. If the Call-ID, To, and From field
match that of an existing subscription, the subscription is a
refresh. Otherwise, it is a new subscription.
5.5.1 Refreshes
Rosenberg et al. [Page 21]
Internet Draft presence June 15, 2000
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
subscription is still acceptable.
Each notification address (as indicated in the Contact header), is
independently refreshed. This allows different expiration times for
different notification addresses. Differing expiration times can be
indicated using the expires parameter of the Contact header, just as
is done for registrations [2].
When a presence agent receives a subscription refresh, it updates the
expiration time of each notification address in the subscription. As
with the initial subscription, the server MAY lower the amount of
time until expiration, but MUST NOT increase it. The final expiration
time is placed in the Expires header in the response, or into the
expires parameters of the Contact headers in the response. The 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.
If no refresh for a notification address is received before its
expiration time, that address is removed from the list of addresses.
If all notification addresses are removed, the entire subscription is
deleted.
5.5.2 New subscriptions
The presence server first determines if the subscriber is authorized.
How such authorization is determined is outside the scope of this
document. Authorizations may have been pre-granted by the presentity
or the system administrator. Alternatively, when the subscription
arrives, the PA may query the user to determine if authorization is
permitted. Such querying is straightforward in the case of a PA co-
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
600 class response. If authorization could not be obtained (for
Rosenberg et al. [Page 22]
Internet Draft presence June 15, 2000
example, because the principal was offline or not available), the PA
SHOULD generate a 202 response. This response tells the subscriber
that the subscription is pending. The PA may reattempt authorization
at a later time, possibly when the principal comes back online. See
[9], which describes a SIP extension that can be used for
authorization of users. The subscriber SHOULD refresh the
subscription as per a 200 response. The subscriber knows the
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
with a 200 OK response. The response MUST contain an indication of
expiration time for each notification address in the SUBSCRIBE. The
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.
The PA also instantiates a subscription for the subscriber. The
subscription is indexed by the Call-ID in the SUBSCRIBE and the URI
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
The subscriber will receive a single final response to the SUBSCRIBE
request. If this response is a 600 class response, the subscription
request has been denied. If the response is a 200 class response, the
subscription has been accepted. The response may contain the current
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.
Rosenberg et al. [Page 23]
Internet Draft presence June 15, 2000
SUBSCRIBE is like REGISTER, in that the Contact headers
don't refer to signaling addresses, but rather notification
addresses. Unlike REGISTER, a Route needs to be built for
SUBSCRIBE, and this Route should not include the Contact
headers.
To refresh the subscription, the subscriber contructs a new SUBSCRIBE
request. The Call-ID, To, and From in this request MUST match those
of the previous SUBSCRIBE request. The CSeq header MUST be higher
than that of the previous SUBSCRIBE request. The Via header is
constructed as described in 5.2. The request MUST contain the Route
header constructed from the response to the initial SUBSCRIBE. The
request MAY contain Accept, Content-Length, Content-Type, and
Content-Encoding headers as described in Section 5.2. The request URI
is constructed from the Route headers, as defined in RFC2543 [2]. The
request is then sent to the server in the request URI.
As long as the subscription remains active, the subscriber will
receive notifications of presence state from the PA.
5.7 Unsubscribing
A subscriber may unsubscribe by sending a SUBSCRIBE request with an
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
Fetching is similar to a subscribing, in that it returns the current
presence state. However, no notifications are sent for future changes
in the presence state. Rather than inventing a new method for this,
it is readily accomplished with a SUBSCRIBE along with an Expires: 0
header and no Contact header. The absence of any Contact header is
what distinguishes it from the similar operation of unsubscribing.
The advantage of using SUBSCRIBE is that the server can simply
process the request independently of whether its a fetch or longer
lived subscription; the authorization and processing steps are
identical. The only difference is whether an actual subscription is
instantiated for the user or not.
This parallels how fetching of registrations is done in SIP. Note
that fetching has no effect on existing subscriptions.
6 Publication
Rosenberg et al. [Page 24]
Internet Draft presence June 15, 2000
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
important features:
o It supports communications means represented by any URL
scheme, including HTTP and SMTP.
o It supports distributed presence information, whereby multiple
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
arbitrary text that can be used for notes.
We also allow REGISTER requests to contain presence documents, so
that the PUAs can publish more complex information.
Note that we do not provide for locking mechanisms, which would allow
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,
and introduces substantial complexity. Most presence operations do
not require get-before-set, since the SIP register mechanism works in
Rosenberg et al. [Page 25]
Internet Draft presence June 15, 2000
such a way that data can be updated without a get.
The application of registered contacts to presence increases the
requirements for authenticity. Therefore, REGISTER requests used by
presence user agents SHOULD be authenticated using either SIP
authentication mechanisms, or a hop by hop mechanism.
7 Notification
Notification is the process of transmitting presence state to
subscribers. It is done by a PA.
7.1 When to send
Notifications are sent when the state of the presentity changes, and
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
a subscriber if it knows that the subscriber is not available to
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
Via: SIP/2.0/UDP userApc.example.com
To: sip:userA@example.com
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
Rosenberg et al. [Page 26]
Internet Draft presence June 15, 2000
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
subscribes to B and B subscribes to A. In this case, no extra
subscriptions are required for this optimization.
Note that this optimization is likely to work only when notifications
are sent by clients. This is because presence servers are not likely
to be privy to presence state of the subscribers.
7.2 Formatting of NOTIFY
The generation of notifications is relatively straightforward. The
presence data is constructed based on rules outside of the scope of
this document. Note that the entity generating a notification MUST
use a presence format listed among those in the Accept header in the
SUBSCRIBE request. If not present, the Lightweight Presence
Information Data Format (LPIDF) [10] type is assumed.
The NOTIFY MUST contain the same Call-ID as the SUBSCRIBE for which
it is acting as a notification. The From field MUST match the To
field in the SUBSCRIBE, and the To field MUST match the From field in
the SUBSCRIBE. The From field MUST contain a tag, which allows for
notifications from presence server and PUA to be distinguished, as
far as SIP transaction processing are concerned.
For SIP experts - this represents a slightly different
operation than for INVITE. When a user sends an INVITE,
they will receive a 200 OK with a tag. Requests in the
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,
note that the CSeq space is different in the direction of notifier to
subscriber and subscriber to notifier, and is from a different space
for presence clients and presence servers. NOTIFY SHOULD NOT contain
Rosenberg et al. [Page 27]
Internet Draft presence June 15, 2000
a Contact header.
If the SUBSCRIBE request contained Record-Route and/or Contact
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
SIP authentication mechanisms. Note that the shared secret mechanisms
are likely to only work for presence client generated notifications,
since shared secrets will exist only between end users, not between
servers and end users. When presence servers are generating the
notifications, public key based authentication is RECOMMENDED.
7.3 Responding to NOTIFY
The subscriber SHOULD be prepared to receive notifications from
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
exist, the UA SHOULD respond with a 481 (Unknown Call Leg). It is
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
acceptable bodies in the response.
If the notification generates no final response at all, and times
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
Access controls are mechanisms which allow the user controlling a
Rosenberg et al. [Page 28]
Internet Draft presence June 15, 2000
presentity to define rules about who is allowed to subscribe, what
data they see, and when. Access controls are a critical component of
a presence solution, but are ideally separated from the underlying
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:
Web Based: A user can go to a secure web page, enter in access
controls, and have the data pushed to the presence server
through proprietary means (the presence server itself may
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
define call processing rules (i.e., policy) for call setup
requests. We observe that the same policies will likely
make sense for subscriptions as well. Therefore, CPL,
possibly with some extensions, can be used for access
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
for general purpose outsourced policy decisions. It could
easily be used by presence servers to define processing of
subscriptions.
Some of the things access controls can be used for are:
o Pre-authorizing subscribers, so that their subscriptions are
automatically accepted.
o Blocking subscribers, so that their subscription requests are
automatically rejected
o Specifying that only subsets of presence information are
reported to selected subscribers
o Specifying that false presence information can be given to
selected subscribers
9 Providing scalability
This section briefly overviews the mechanisms in this extension which
Rosenberg et al. [Page 29]
Internet Draft presence June 15, 2000
provide scalability, a critical goal for any presence protocol.
We have observed that scalability is limited by the messaging and
processing load at presence servers. As the processing load is
proportional to the message load, we can consider just the message
load to determine the scale bottlenecks at a presence server. This
load is equal to:
load = (presentities *
subscribers per presentity *
notifications per presentity) +
(presentities *
subscribers per presentity)
The first term represents the notification load, and the second, the
subscription load. The dominant factor is the notification load. We
address this load by providing three mechanisms - one for the
reduction of each of these terms.
9.1 Partitioning of the namespace
The load on an individual server can be reduced by partitioning the
namespace, so that a single presence server handles only a small
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
the main proxy server for example.com. This server does nothing but
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
Rosenberg et al. [Page 30]
Internet Draft presence June 15, 2000
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
first SUBSCRIBE request; refreshes can bypass the proxies to improve
scale.
9.2 Client notifications
The load can also be reduced by completely eliminating notifications
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
All the subscriptions from one domain to another can be aggregated by
co-locating a PA with a local outbound proxy. This is shown in Figure
2.
In the figure, domain X has two subscribers for a single presentity
in domain Y. Both subscribers use a local outbound proxy, so that the
SUBSCRIBE messages pass through a single proxy. When the proxy sees a
subscription for a user in an outside domain, it acts as a PA, and
accepts the subscription itself. Since a PA must be aware of the
complete presence state of the presentity, the presence server itself
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
look like:
SUBSCRIBE sip:presentity@domainy.com SIP/2.0
Via: SIP/2.0/UDP subscriberA-pc.domainx.com
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
Rosenberg et al. [Page 31]
Internet Draft presence June 15, 2000
++++++++++
++++++++ +++++
+++ +++
++ ++++++++++++
+ ++
+ ++
+---------+ + + +---------+
| +----+ | +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
When this is received at the outbound proxy/PA for domain X, the PA
itself generates a subscription for presentity, SUBSCRIBE 3:
Rosenberg et al. [Page 32]
Internet Draft presence June 15, 2000
Via: SIP/2.0/UDP outboundproxy.domainx.com
From: sip:domainx.com
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
originating host (in the Via and Contact fields), and sip:domainx.com
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:
SUBSCRIBE sip:presentity@domainy.com SIP/2.0
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
subscriptions are generated or forwarded to domain Y.
This process results in the subscription state being distributed
throughout the network, with each domain holding the subscriptions
from users within its own domain. In fact, the process can take place
recursively, resulting in distribution of presence state over a tree
of domains. That achieves scale; a presentity that might get millions
of subscribers would be readily served by such an architecture.
The important concept to note here is that this aggregation process
is a matter of local optimization in domain X; as far as domain Y is
concerned, there is a single subscription, and processing that
subscription is no different than processing any other subscription.
This is possible because we have defined presence operations to be
Rosenberg et al. [Page 33]
Internet Draft presence June 15, 2000
invoked on logical entities, PAs, which can dynamically be
instantiated on a subscription by subscription basis in any device
which can somehow determine the complete presence state of a
presentity. In the case here, the outbound proxy is instantiating the
PA, and it is allowing the PA to know the presence state of a
presentity through another subscription.
The drawback of this optimization is that it introduces security
issues. The subscription from domainX is now domain wide; the
presentity cannot authenticate the identity of every subscriber
within the domain. It is forced into a trust relationship with that
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
There are numerous security considerations for presence. Many are
outlined above; this section considers them issue by issue.
10.1 Privacy
Privacy encompasses many aspects of a presence system:
o Subscribers may not want to reveal the fact that they have
subscribed to certain users
o Users may not want to reveal that they have accepted
subscriptions from certain users
o Notifications (and fetch results) may contain sensitive data
which should not be revealed to anyone but the subscriber
Privacy is provided through a combination of hop by hop encryption
and end to end encryption. The hop by hop mechanisms provide scalable
privacy services, disable attacks involving traffic analysis, and
hide all aspects of presence messages. However, they operate based on
transitivity of trust, and they cause message content to be revealed
to proxies. The end to end mechanisms do not require transitivity of
trust, and reveal information only to the desired recipient. However,
end to end encryption cannot hide all information, and is susceptible
to traffic analysis. Strong end to end authentication and encryption
also requires that both participants have public keys, which is not
Rosenberg et al. [Page 34]
Internet Draft presence June 15, 2000
generally the case. Thus, both mechanisms combined are needed for
complete privacy services.
SIP allows any hop by hop encryption scheme. It is RECOMMENDED that
between network servers (proxies to proxies, proxies to redirect
servers), transport mode ESP [7] is used to encrypt the entire
message. Between a UAC and its local proxy, TLS [15] is RECOMMENDED.
Similarly, TLS SHOULD be used between a presence server and the PUA.
The presence server can determine whether TLS is supported by the
receiving client based on the transport parameter in the Contact
header of its registration. If that registration contains the token
"tls" as transport, it implies that the PUA supports TLS.
Furthermore, we allow for the Contact header in the SUBSCRIBE request
to contain TLS as a transport. The Contact header is used to route
subsequent messages between a pair of entities. It defines the
address and transport used to communicate with the user agent. Even
though TLS might be used between the subscriber and its local proxy,
placing this parameter in the Contact header means that TLS can also
be used end to end for generation of notifications after the initial
SUBSCRIBE message has been successfully routed. This would provide
end to end privacy and authentication services with low proxy
overheads.
SIP encryption MAY be used end to end for the transmission of both
SUBSCRIBE and NOTIFY requests. SIP supports PGP based encryption,
which does not require the establishment of a session key for
encryption of messages within a given subscription (basically, a new
session key is established for each message as part of the PGP
encryption). Work has recently begun on the application of S/MIME
[16] for SIP. Tunneling of TLS over SIP, for the purposes of
establishment of an end to end private key for encryption, is also
under investigation.
10.2 Message integrity and authenticity
It is important for the message recipient to ensure that the message
contents are actually what was sent by the originator, and that the
recipient of the message be able to determine who the originator
really is. This applies to both requests and responses of SUBSCRIBE
and NOTIFY. This is supported in SIP through end to end
authentication and message integrity. SIP provides PGP based
authentication and integrity (both challenge-response and public key
signatures), and http basic and digest authentication.
10.3 Outbound authentication
When local proxies are used for transmission of outbound messages,
Rosenberg et al. [Page 35]
Internet Draft presence June 15, 2000
proxy authentication is RECOMMENDED. This is useful to verify the
identity of the originator, and prevent spoofing and spamming at the
originating network.
10.4 Replay prevention
To prevent the replay of old subscriptions and notifications, all
signed SUBSCRIBE and NOTIFY requests and responses MUST contain a
Date header covered by the message signature. Any message with a date
older than several minutes in the past, or more than several minutes
into the future, SHOULD be discarded.
Furthermore, all signed SUBSCRIBE and NOTIFY requests MUST contain a
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
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
highest seen so far, is discarded.
Finally, challenge-response authentication (http basic, digest, of
PGP) MAY be used to prevent replay attacks.
10.5 Denial of service attacks
Denial of service attacks are a critical problem for an open, inter-
domain, presence protocol. Here, we discuss several possible attacks,
and the steps we have taken to prevent them.
10.5.1 Smurf attacks through false contacts
Unfortunately, presence is a good candidate for smurfing attacks
because of its amplification properties. A single SUBSCRIBE message
could generate a nearly unending stream of notifications, so long as
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
number of users, and in the Contact header (which is where
notifications are sent), place the address of the target.
The only reliable way to prevent these attacks is through
authentication and authorization. End users will hopefully not accept
subscriptions from random unrecognized users. Also, the presence
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
the From field (which identifies the subscriber).
Also, note that as described in Section 7.3, if a notify is not
acknowledged or was not wanted, the subscription that generated it is
removed. This eliminates some of the amplification properties of
Rosenberg et al. [Page 36]
Internet Draft presence June 15, 2000
providing false 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
Rosenberg et al. [Page 37]
Internet Draft presence June 15, 2000
|
|
|
|
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
Rosenberg et al. [Page 38]
Internet Draft presence June 15, 2000
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].
Rosenberg et al. [Page 39]
Internet Draft presence June 15, 2000
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
Rosenberg et al. [Page 40]
Internet Draft presence June 15, 2000
o SDP processing
o re-INVITEs
Elimination of INVITE processing alone results in a substantial
reduction in required features.
13 Example message flows
THe following subsections exhibit example message flows, to further
clarify behavior of the protocol.
13.1 Client to Client Subscription with Presentity State Changes
This call flow illustrates subscriptions and notifications that do
not involve a presence server.
The watcher subscribes to the presentity and the presentity includes
its current state in the 200 OK response message. The presentity
subsequently changes state (is on the phone), resulting in a new
notification. The flow finishes with the watcher canceling the
subscription.
Watcher Presentity
------- -----------
| F1 SUBSCRIBE |
| ----------------------------->|
| F2 200 OK |
|<------------------------------|
| F3 NOTIFY |
|<------------------------------|
| F4 200 OK |
|------------------------------>|
| F5 NOTIFY |
|<------------------------------|
| F6 200 OK |
|------------------------------>|
| F7 SUBSCRIBE (unsub) |
|------------------------------>|
| F8 200 OK |
|<------------------------------|
Message Details
Rosenberg et al. [Page 41]
Internet Draft presence June 15, 2000
F1 SUBSCRIBE watcher -> presentity
SUBSCRIBE sip:presentity@pres.example.com SIP/2.0
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User
To: Resource
Call-ID: 3248543@watcherhost.example.com
CSeq : 1 SUBSCRIBE
Expires: 600
Accept: application/xpidf+xml, text/lpidf
Contact: sip:user@watcherhost.example.com
F2 200 OK presentity->watcher
SIP/2.0 200 OK
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User
To: Resource
Call-ID: 3248543@watcherhost.example.com
Cseq: 1 SUBSCRIBE
Expires: 600
Content-Type: application/xpidf+xml
Content-Length: 351
F3 NOTIFY Presentity->watcher
NOTIFY sip:user@watcherhost.example.com SIP/2.0
Via: SIP/2.0/UDP pres.example.com:5060
From: Resource
Rosenberg et al. [Page 42]
Internet Draft presence June 15, 2000
To: User
Call-ID: 3248543@watcherhost.example.com
CSeq: 1 NOTIFY
Content-Type: application/xpidf+xml
Content-Length: 352
F4 200 OK watcher->presentity
SIP/2.0 200 OK
Via: SIP/2.0/UDP pres.example.com:5060
From: Resource
To: User
Call-ID: 3248543@watcherhost.example.com
CSeq: 1 NOTIFY
F5 NOTIFY Presentity->watcher
NOTIFY sip:user@watcherhost.example.com SIP/2.0
Via: SIP/2.0/UDP pres.example.com:5060
From: Resource
To: User
Call-ID: 3248543@watcherhost.example.com
CSeq: 2 NOTIFY
Content-Type: application/xpidf+xml
Content-Length: 351
Rosenberg et al. [Page 43]
Internet Draft presence June 15, 2000
F6 200 OK watcher->presentity
SIP/2.0 200 OK
Via: SIP/2.0/UDP pres.example.com:5060
From: Resource
To: User
Call-ID: 3248543@watcherhost.example.com
CSeq: 2 NOTIFY
F7 SUBSCRIBE watcher -> presentity
SUBSCRIBE sip:presentity@pres.example.com SIP/2.0
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User
To: Resource
Call-ID: 3248543@watcherhost.example.com
CSeq : 2 SUBSCRIBE
Expires: 0
Accept: application/xpidf+xml, text/lpidf
Contact: sip:user@watcherhost.example.com
F8 200 OK presentity->watcher
SIP/2.0 200 OK
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User
To: Resource
Call-ID: 3248543@watcherhost.example.com
Cseq: 2 SUBSCRIBE
Expires:0
Content-Type: text/lpidf
Rosenberg et al. [Page 44]
Internet Draft presence June 15, 2000
Content-Length: 113
To: sip:presentity@pres.example.com
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
handling of subscriptions. In this scenario, the client has indicated
that it will handle subscriptions and thus notifications. The message
flow shows a change of presence state by the client and a
cancellation of the subscription by the watcher.
Presence
Watcher Server PUA
| | F1 REGISTER |
| |<---------------------|
| | F2 200 OK |
| |--------------------->|
| F3 SUBSCRIBE | |
|--------------------->| |
| | F4 SUBSCRIBE |
| |--------------------->|
| | F5 200 OK |
| |<---------------------|
| F6 200 OK | |
|<---------------------| |
| | F7 REGISTER |
| |<---------------------|
| | F8 200 OK |
| |--------------------->|
| F9 NOTIFY | |
|<--------------------------------------------+
| F10 200 OK | |
|-------------------------------------------->|
| F11 SUBSCRIBE | |
|--------------------->| |
| | F12 SUBSCRIBE |
| |--------------------->|
| | F13 200 OK |
| |<---------------------|
| F14 200 OK | |
Rosenberg et al. [Page 45]
Internet Draft presence June 15, 2000
|<---------------------| |
Message Details
F1 REGISTER PUA->server
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com:5060
To:
From:
Call-ID: 2818@pua.example.com
CSeq: 1 REGISTER
Contact:
;description="open"
Contact:
Expires: 600
F2 200 OK server->PUA
SIP/2.0 200 OK
Via: SIP/2.0/UDP pua.example.com:5060
To:
From:
Call-ID: 2818@pua.example.com
CSeq: 1 REGISTER
Contact:
;description="open"
Contact:
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
To: Resource
Rosenberg et al. [Page 46]
Internet Draft presence June 15, 2000
Call-ID: 32485@watcherhost.example.com
CSeq : 1 SUBSCRIBE
Expires: 600
Contact: sip:user@watcherhost.example.com
F4 SUBSCRIBE server->PUA
SUBSCRIBE sip:id@pua.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
To: Resource
Call-ID: 32485@watcherhost.example.com
CSeq : 1 SUBSCRIBE
Expires: 600
Contact: sip:user@watcherhost.example.com
F5 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
To: Resource
Call-ID: 32485@watcherhost.example.com
CSeq : 1 SUBSCRIBE
Expires: 600
Content-Type: text/lpidf
Content-Length: 115
To: sip:resource@example.com
Contact:
;description="open"
F6 200 OK server->watcher
Rosenberg et al. [Page 47]
Internet Draft presence June 15, 2000
SIP/2.0 200 OK
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User
To: Resource
Call-ID: 32485@watcherhost.example.com
CSeq : 1 SUBSCRIBE
Expires: 600
Content-Type: text/lpidf
Content-Length: 115
To: sip:resource@example.com
Contact:
;description="open"
F7 REGISTER PUA->server
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com:5060
To:
From:
Call-ID: 2818@pua.example.com
CSeq: 2 REGISTER
Contact:
;description="inuse"
Expires: 600
F8 200 OK server->PUA
SIP/2.0 200 OK
Via: SIP/2.0/UDP pua.example.com:5060
To:
From:
Call-ID: 2818@pua.example.com
CSeq: 2 REGISTER
Contact:
;description="inuse"; expires=600
Contact:
; expires=210
Rosenberg et al. [Page 48]
Internet Draft presence June 15, 2000
F9 NOTIFY PUA->watcher
NOTIFY sip:user@watcherhost.example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com:5060
To: User
From: Resource
Call-ID: 32485@watcherhost.example.com
CSeq : 1 NOTIFY
Content-Type: text/lpidf
Content-Length: 116
To: sip:resource@example.com
Contact:
;description="inuse"
F10 200 OK watcher->PUA
SIP/2.0 200 OK
Via: SIP/2.0/UDP pua.example.com:5060
To: User
From: Resource
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
To: Resource
Call-ID: 32485@watcherhost.example.com
CSeq : 2 SUBSCRIBE
Expires: 0
Contact: sip:user@watcherhost.example.com
F12 SUBSCRIBE server->PUA
Rosenberg et al. [Page 49]
Internet Draft presence June 15, 2000
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
To: Resource
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
To: Resource
Call-ID: 32485@watcherhost.example.com
CSeq : 2 SUBSCRIBE
Content-Type: text/lpidf
Content-Length: 115
To: sip:resource@example.com
Contact:
; description="open"
F14 200 OK server->watcher
SIP/2.0 200 OK
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User
To: Resource
Call-ID: 32485@watcherhost.example.com
CSeq : 2 SUBSCRIBE
Content-Type: text/lpidf
Content-Length: 115
To: sip:resource@example.com
Contact:
; description="open"
Rosenberg et al. [Page 50]
Internet Draft presence June 15, 2000
13.3 Presence Server Notifications
This message flow illustrates how the presence server can be the
responsible for sending notifications for a presentity. The presence
server will do this if the presentity has not sent a registration
indicating an interest in handling subscriptions. This flow assumes
that the watcher has previously been authorized to subscribe to this
resource at the server.
Watcher Server PUA
| F1 SUBSCRIBE | |
|------------------>| |
| F2 200 OK | |
|<------------------| |
| | F3 REGISTER |
| |<-------------------|
| | F4 200 OK |
| |------------------->|
| F5 NOTIFY | |
|<------------------| |
| F6 200 OK | |
|------------------>| |
| | F7 REGISTER |
| |<-------------------|
| | F8 200 OK |
| |------------------->|
| F9 NOTIFY | |
|<------------------| |
| F10 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
To:
From:
Call-ID: 2010@watcherhost.example.com
CSeq: 1 SUBSCRIBE
Contact:
Expires: 600
Rosenberg et al. [Page 51]
Internet Draft presence June 15, 2000
F2 200 OK server->watcher
SIP/2.0 200 OK
Via: SIP/2.0/UDP watcherhost.example.com:5060
To:
From:
Call-ID: 2010@watcherhost.example.com
CSeq: 1 SUBSCRIBE
Expires: 600
Content-Type: text/lpidf
Content-Length: 114
To: sip:resource@example.com
Contact:
;description="closed"
F3 REGISTER PUA->server
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com:5060
To:
From:
Call-ID: 110@pua.example.com
CSeq: 1 REGISTER
Contact:
;description="open"
Expires: 600
F4 200 OK server->PUA
SIP/2.0 200 OK
Via: SIP/2.0/UDP pua.example.com:5060
To:
From:
Call-ID: 110@pua.example.com
CSeq: 1 REGISTER
Contact:
; description="open"; expires=600
Rosenberg et al. [Page 52]
Internet Draft presence June 15, 2000
F5 NOTIFY server-> watcher
NOTIFY sip:user@watcherhost.example.com SIP/2.0
Via: SIP/2.0/UDP server.example.com:5060
From:
To:
Call-ID: 2010@watcherhost.example.com
CSeq: 1 NOTIFY
Content-Type: text/lpidf
Content-Length: 111
To: sip:resource@example.com
Contact:
; description="open"
F6 200 OK
SIP/2.0 200 OK
Via: SIP/2.0/UDP server.example.com:5060
From:
To:
Call-ID: 2010@watcherhost.example.com
CSeq: 1 NOTIFY
F7 REGISTER
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com:5060
To:
From:
Call-ID: 110@pua.example.com
CSeq: 2 REGISTER
Contact:
;description="Away from keyboard"
Expires: 600
F8 200 OK
Rosenberg et al. [Page 53]
Internet Draft presence June 15, 2000
Via: SIP/2.0/UDP pua.example.com:5060
To:
From:
Call-ID: 110@pua.example.com
CSeq: 2 REGISTER
Contact:
; description="Away from keyboard"
; expires=600
F9 NOTIFY
NOTIFY sip:user@watcherhost.example.com SIP/2.0
Via: SIP/2.0/UDP server.example.com:5060
From:
To:
Call-ID: 2010@watcherhost.example.com
CSeq: 2 NOTIFY
Content-Type: text/lpidf
Content-Length: 125
To: sip:resource@example.com
Contact:
; description="Away from keyboard"
F10 200 OK
SIP/2.0 200 OK
Via: SIP/2.0/UDP server.example.com:5060
From:
To:
Call-ID: 2010@watcherhost.example.com
CSeq: 2 NOTIFY
13.4 Presence Server Notifications with Client Authorization of
Subscription
This call flow expands on the call flow in 13.3 by showing how the
Rosenberg et al. [Page 54]
Internet Draft presence June 15, 2000
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:
From:
Rosenberg et al. [Page 55]
Internet Draft presence June 15, 2000
Call-ID: 12@pua.example.com
CSeq: 1 REGISTER
Contact:
;description="open"
Contact:
Expires: 600
F2 200 OK server->PUA
SIP/2.0 200 OK
Via: SIP/2.0/UDP pua.example.com:5060
To:
From:
Call-ID: 12@pua.example.com
CSeq: 1 REGISTER
Contact:
;description="open"
Contact:
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
To: Resource
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
Rosenberg et al. [Page 56]
Internet Draft presence June 15, 2000
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User
To: Resource
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
To: Resource
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
To: Resource
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:
To:
Call-ID: 3248546@watcherhost.example.com
CSeq: 1 NOTIFY
Rosenberg et al. [Page 57]
Internet Draft presence June 15, 2000
Content-Type: text/lpidf
Content-Length: 111
To: sip:resource@example.com
Contact:
; description="open"
F8 200 OK
SIP/2.0 200 OK
Via: SIP/2.0/UDP server.example.com:5060
From:
To:
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:
From:
Call-ID: 12@pua.example.com
CSeq: 2 REGISTER
Contact:
;description="hiding in storm shelter"
Contact:
Expires: 600
F10 200 OK server->PUA
SIP/2.0 200 OK
Via: SIP/2.0/UDP pua.example.com:5060
To:
Rosenberg et al. [Page 58]
Internet Draft presence June 15, 2000
From:
Call-ID: 12@pua.example.com
CSeq: 2 REGISTER
Contact:
;description="hiding in storm shelter"
Contact:
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:
To:
Call-ID: 3248546@watcherhost.example.com
CSeq: 2 NOTIFY
Content-Type: text/lpidf
Content-Length: 131
To: sip:resource@example.com
Contact:
; 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:
To:
Call-ID: 3248546@watcherhost.example.com
CSeq: 2 NOTIFY
F13 SUBSCRIBE watcher->server
Rosenberg et al. [Page 59]
Internet Draft presence June 15, 2000
SUBSCRIBE sip:resource@example.com SIP/2.0
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User
To: Resource
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
To: Resource
Call-ID: 3248546@watcherhost.example.com
CSeq: 2 SUBSCRIBE
Content-Type: text/lpidf
Content-Length: 131
To: sip:resource@example.com
Contact:
; 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.
Rosenberg et al. [Page 60]
Internet Draft presence June 15, 2000
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
To: Resource
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
Rosenberg et al. [Page 61]
Internet Draft presence June 15, 2000
To: Resource
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:
From:
Call-ID: 2001@pua.example.com
CSeq: 1 REGISTER
Date: Wed, 14 Jun 2000 09:57:16 GMT
Contact:
Contact:
Expires: 600
F4 200 OK server->PUA
SIP/2.0 200 OK
Via: SIP/2.0/UDP pua.example.com:5060
To:
From:
Call-ID: 2001@pua.example.com
CSeq: 1 REGISTER
Contact:
Contact:
Expires: 600
F5 QAUTH server->PUA
QAUTH sip:id@pua.example.com SIP/2.0
Rosenberg et al. [Page 62]
Internet Draft presence June 15, 2000
Via: SIP/2.0/UDP server.example.com:5060
From: User
To: Resource
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
To: Resource
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
To: Resource
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
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User
To: Resource
Rosenberg et al. [Page 63]
Internet Draft presence June 15, 2000
Call-ID: 3248544@watcherhost.example.com
CSeq: 1 SUBSCRIBE
Expires: 600
Content-Type: text/lpidf
Content-Length: 31
To: sip:resource@example.com
14 Checklist of requirements
This section examines the requirements for presence, as specified in
RFC2779 [18], and indicates how each requirement is addressed by this
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
to be available independent of whether an INSTANT MESSAGE
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
INSTANT INBOX is necessarily reached by the same IDENTIFIER
as that of a PRESENTITY. Specifically, the protocols must
assume that some INSTANT INBOXes may have no associated
PRESENTITIES, and vice versa." The complete separation of
IM and presence allows different identifiers to be used for
each.
"Requirement 2.1.3. The protocols MUST also allow an INSTANT
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
within a given DOMAIN MUST be able to operate independently
of actions in any other DOMAIN." This requirement is met by
SIP. SIP uses email-like identifiers which consist of a
user name at a domain. Administration of user names is done
completely within the domain, and these user names have no
Rosenberg et al. [Page 64]
Internet Draft presence June 15, 2000
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
number of DOMAINS within the NAMESPACE." This requirement
is met by SIP. SIP uses standard DNS domains, which are not
restricted in number.
"Requirement 2.2.1. It MUST be possible for ENTITIES in one
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
other functional and performance requirements even when
there are millions of ENTITIES within a single DOMAIN."
Whilst it is hard to judge whether this can be met by
examining the architecture of a protocol, SIP has numerous
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
other functional and performance requirements when there
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
other functional and performance requirements when every
single SUBSCRIBER has SUBSCRIPTIONS to hundreds of
PRESENTITIES." Section 9 discusses the means by which our
extension provides scale.
Rosenberg et al. [Page 65]
Internet Draft presence June 15, 2000
"Requirement 2.2.5: The protocol MUST be capable of meeting its
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
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
SUBSCRIPTION both directly and via intermediaries, such as
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
NOTIFICATION both directly and via intermediaries, such as
PROXIES." The use of Record-Routing described here, and in
RFC2543 [2] means that notifications can go directly from
presence agent to subscriber, or through proxies, as the
policy of each proxy dictates.
"Requirement 2.4.4: The protocol proxying facilities and
transport practices MUST allow ADMINISTRATORS ways to
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
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
confidence that a received message (NOTIFICATION or INSTANT
Rosenberg et al. [Page 66]
Internet Draft presence June 15, 2000
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
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
the means to ensure non-corruption, non-playback, and
privacy, but the protocol MUST NOT require that all clients
use these means at all times." SIPs security mechanisms are
optional.
"Requirement 3.1.1: All ENTITIES MUST produce and consume at
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
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
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
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.
Rosenberg et al. [Page 67]
Internet Draft presence June 15, 2000
"Requirement 3.2.4. The protocol MUST provide a mechanism for
detecting when a PRESENTITY or SUBSCRIBER has gone OUT OF
CONTACT." The SIP REGISTER method is used for this purpose.
"Requirement 3.2.5: The protocol MUST NOT depend on a PRESENTITY
or SUBSCRIBER gracefully telling the service that it will
no longer be in communication, since a PRESENTITY or
SUBSCRIBER may go OUT OF CONTACT due to unanticipated
failures." Registrations are soft state, and will timeout
if not refreshed.
"Requirement 3.3.1: The protocol MUST include mechanisms to
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
allow cached PRESENCE INFORMATION to be updated when the
master copy changes." Presence data contains timestamps
which indicate its expiration; this forces a fetch to go to
the PA after expiration.
"Requirement 3.3.3: The protocol caching facilities MUST NOT
circumvent established ACCESS RULES or restrict choice of
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
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
Rosenberg et al. [Page 68]
Internet Draft presence June 15, 2000
We would like to thank the following people for their support and
comments on this draft:
Rick Workman Nortel
Adam Roach Ericsson
Sean Olson Ericsson
Billy Biggs University of Waterloo
Stuart Barkley UUNet
Mauricio Arango SUN
Richard Shockey Shockey Consulting LLC
Jorgen Bjorkner Hotsip
Henry Sinnreich MCI Worldcom
Ronald Akers Motorola
16 Authors Addresses
Jonathan Rosenberg
dynamicsoft
200 Executive Drive
Suite 120
West Orange, NJ 07052
email: jdrosen@dynamicsoft.com
Dean Willis
dynamicsoft
200 Executive Drive
Suite 120
West Orange, NJ 07052
email: dwillis@dynamicsoft.com
Robert Sparks
dynamicsoft
200 Executive Drive
Suite 120
West Orange, NJ 07052
email: rsparks@dynamicsoft.com
Ben Campbell
dynamicsoft
200 Executive Drive
Suite 120
West Orange, NJ 07052
email: bcampbell@dynamicsoft.com
Henning Schulzrinne
Rosenberg et al. [Page 69]
Internet Draft presence June 15, 2000
Columbia University
M/S 0401
1214 Amsterdam Ave.
New York, NY 10027-7003
email: schulzrinne@cs.columbia.edu
Jonathan Lennox
Columbia University
M/S 0401
1214 Amsterdam Ave.
New York, NY 10027-7003
email: lennox@cs.columbia.edu
Christian Huitema
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
email: huitema@microsoft.com
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
email: bernarda@microsoft.com
David Gurle
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
email: dgurle@microsoft.com
David Oran
Cisco Systems
170 West Tasman Dr.
San Jose, CA 95134
email: oran@cisco.com
17 Bibliography
[1] M. Day, J. Rosenberg, and H. Sugano, "A model for presence and
instant messaging," Request for Comments 2778, Internet Engineering
Task Force, Feb. 2000.
[2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
session initiation protocol," Request for Comments 2543, Internet
Rosenberg et al. [Page 70]
Internet Draft presence June 15, 2000
Engineering Task Force, Mar. 1999.
[3] H. Schulzrinne and J. Rosenberg, "SIP caller preferences and
callee capabilities," Internet Draft, Internet Engineering Task
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,
J. Lennox, C. Huitema, B. Aboba, and D. Gurle, "SIP extensions for
presence authorization," Internet Draft, Internet Engineering Task
Force, June 2000. Work in progress.
[10] J. Rosenberg, R. Sparks, D. Willis, B. Campbell, H. Schulzrinne,
J. Lennox, C. Huitema, B. Aboba, and D. Gurle, "A lightweight
presence information data format (LPIDF)," Internet Draft, Internet
Engineering Task Force, June 2000. Work in progress.
[11] J. Rosenberg, R. Sparks, D. Willis, B. Campbell, H. Schulzrinne,
J. Lennox, C. Huitema, B. Aboba, and D. Gurle, "A data format for
presence using XML," Internet Draft, Internet Engineering Task Force,
June 2000. Work in progress.
[12] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Rajan, and A.
Sastry, "The COPS (common open policy service) protocol," Request for
Comments 2748, Internet Engineering Task Force, Jan. 2000.
[13] J. Lennox and H. Schulzrinne, "CPL: a language for user control
of internet telephony services," Internet Draft, Internet Engineering
Task Force, Mar. 1999. Work in progress.
Rosenberg et al. [Page 71]
Internet Draft presence June 15, 2000
[14] J. Lennox and H. Schulzrinne, "Transporting user control
information in sip register payloads," Internet Draft, Internet
Engineering Task Force, Mar. 2000. Work in progress.
[15] T. Dierks and C. Allen, "The TLS protocol version 1.0," Request
for Comments 2246, Internet Engineering Task Force, Jan. 1999.
[16] B. Ramsdell and Ed, "S/MIME version 3 message specification,"
Request for Comments 2633, Internet Engineering Task Force, June
1999.
[17] J. Rosenberg and H. Schulzrinne, "SIP extensions for managing
persistent connections," Internet Draft, Internet Engineering Task
Force, June 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
1 Introduction ........................................ 1
2 Why use SIP as a base protocol for presence? ....... 3
3 Definitions ......................................... 6
4 Overview of Operation ............................... 8
4.1 Architecture ........................................ 8
4.2 Message Flow ........................................ 8
5 Subscriptions ....................................... 16
5.1 Generating subscriptions ............................ 16
5.2 Sending subscriptions ............................... 19
5.3 Proxying subscriptions .............................. 20
5.4 Presence server processing of SUBSCRIBE ............. 20
5.5 Presence agent processing of SUBSCRIBE .............. 21
Rosenberg et al. [Page 72]
Internet Draft presence June 15, 2000
5.5.1 Refreshes ........................................... 21
5.5.2 New subscriptions ................................... 22
5.6 Subscriber processing of SUBSCRIBE response ......... 23
5.7 Unsubscribing ....................................... 24
5.8 Fetching ............................................ 24
6 Publication ......................................... 24
7 Notification ........................................ 26
7.1 When to send ........................................ 26
7.2 Formatting of NOTIFY ................................ 27
7.3 Responding to NOTIFY ................................ 28
8 Access controls ..................................... 28
9 Providing scalability ............................... 29
9.1 Partitioning of the namespace ....................... 30
9.2 Client notifications ................................ 31
9.3 Distributed subscription state ...................... 31
10 Security considerations ............................. 34
10.1 Privacy ............................................. 34
10.2 Message integrity and authenticity .................. 35
10.3 Outbound authentication ............................. 35
10.4 Replay prevention ................................... 36
10.5 Denial of service attacks ........................... 36
10.5.1 Smurf attacks through false contacts ................ 36
10.5.2 Annoyance subscriptions ............................. 37
10.6 Firewall traversal .................................. 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
Rosenberg et al. [Page 73]