📄 rfc3856 a presence event package for the session initiation protocol.txt
字号:
Network Working Group J. Rosenberg
Request for Comments: 3856 dynamicsoft
Category: Standards Track August 2004
A Presence Event Package for the Session Initiation Protocol (SIP)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document describes the usage of the Session Initiation Protocol
(SIP) for subscriptions and notifications of presence. Presence is
defined as the willingness and ability of a user to communicate with
other users on the network. Historically, presence has been limited
to "on-line" and "off-line" indicators; the notion of presence here
is broader. Subscriptions and notifications of presence are
supported by defining an event package within the general SIP event
notification framework. This protocol is also compliant with the
Common Presence Profile (CPP) framework.
Table of Contents
1. Introduction ................................................ 2
2. Terminology ................................................. 3
3. Definitions ................................................. 3
4. Overview of Operation ....................................... 4
5. Usage of Presence URIs ...................................... 6
6. Presence Event Package ...................................... 7
6.1. Package Name .......................................... 8
6.2. Event Package Parameters .............................. 8
6.3. SUBSCRIBE Bodies ...................................... 8
6.4. Subscription Duration ................................. 9
6.5. NOTIFY Bodies ......................................... 9
6.6. Notifier Processing of SUBSCRIBE Requests ............. 9
6.6.1. Authentication ................................. 10
6.6.2. Authorization .................................. 10
6.7. Notifier Generation of NOTIFY Requests ................ 11
Rosenberg Standards Track [Page 1]
RFC 3856 SIP Presence August 2004
6.8. Subscriber Processing of NOTIFY Requests .............. 13
6.9. Handling of Forked Requests ........................... 13
6.10. Rate of Notifications ................................. 14
6.11. State Agents .......................................... 14
6.11.1. Aggregation, Authentication, and Authorization. 14
6.11.2. Migration ..................................... 15
7. Learning Presence State ..................................... 16
7.1. Co-location ........................................... 16
7.2. REGISTER .............................................. 16
7.3. Uploading Presence Documents .......................... 17
8. Example Message Flow ........................................ 17
9. Security Considerations ..................................... 20
9.1. Confidentiality ....................................... 20
9.2. Message Integrity and Authenticity .................... 21
9.3. Outbound Authentication ............................... 22
9.4. Replay Prevention ..................................... 22
9.5. Denial of Service Attacks Against Third Parties ....... 22
9.6. Denial Of Service Attacks Against Servers ............. 23
10. IANA Considerations ......................................... 23
11. Contributors ................................................ 24
12. Acknowledgements ............................................ 25
13. Normative References ........................................ 25
14. Informative References ...................................... 26
15. Author's Address ............................................ 26
16. Full Copyright Statement .................................... 27
1. Introduction
Presence, also known as presence information, conveys the ability and
willingness of a user to communicate across a set of devices. RFC
2778 [10] defines a model and terminology for describing systems that
provide presence information. In that model, a presence service is a
system that accepts, stores, and distributes presence information to
interested parties, called watchers. A presence protocol is a
protocol for providing a presence service over the Internet or any IP
network.
This document proposes the usage of the Session Initiation Protocol
(SIP) [1] as a presence protocol. This is accomplished through a
concrete instantiation of the general event notification framework
defined for SIP [2], and as such, makes use of the SUBSCRIBE and
NOTIFY methods defined there. Specifically, this document defines an
event package, as described in RFC 3265 [2]. SIP is particularly
well suited as a presence protocol. SIP location services already
contain presence information, in the form of registrations.
Furthermore, SIP networks are capable of routing requests from any
user on the network to the server that holds the registration state
for a user. As this state is a key component of user presence, those
Rosenberg Standards Track [Page 2]
RFC 3856 SIP Presence August 2004
SIP networks can allow SUBSCRIBE requests to be routed to the same
server. This means that SIP networks can be reused to establish
global connectivity for presence subscriptions and notifications.
This event package is based on the concept of a presence agent, which
is a new logical entity that is capable of accepting subscriptions,
storing subscription state, and generating notifications when there
are changes in presence. The entity is defined as a logical one,
since it is generally co-resident with another entity.
This event package is also compliant with the Common Presence Profile
(CPP) framework that has been defined in [3]. This allows SIP for
presence to easily interwork with other presence systems compliant to
CPP.
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [4] and
indicate requirement levels for compliant implementations.
3. Definitions
This document uses the terms as defined in RFC 2778 [10].
Additionally, the following terms are defined and/or additionally
clarified:
Presence User Agent (PUA): A Presence User Agent manipulates
presence information for a presentity. This manipulation can
be the side effect of some other action (such as sending a SIP
REGISTER request to add a new Contact) or can be done
explicitly through the publication of presence documents. We
explicitly allow multiple PUAs per presentity. This means that
a user can have many devices (such as a cell phone and Personal
Digital Assistant (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 messages.
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 knowledge of the presence state of a
presentity. This means that it must have access to presence
data manipulated by PUAs for the presentity. One way to do
this is by co-locating the PA with the proxy/registrar.
Rosenberg Standards Track [Page 3]
RFC 3856 SIP Presence August 2004
Another way is to co-locate it with the presence user agent of
the presentity. However, these are not the only ways, and this
specification makes no recommendations about where the PA
function should be located. A PA is always addressable with a
SIP URI that uniquely identifies the presentity (i.e.,
sip:joe@example.com). There can be multiple PAs for a
particular presentity, each of which handles some subset of the
total subscriptions currently active for the presentity. A PA
is also a notifier (defined in RFC 3265 [2]) that supports the
presence event package.
Presence Server: A presence server is a physical entity that can
act as either a presence agent or as a proxy server for
SUBSCRIBE requests. When acting as a PA, it is aware of the
presence information of the presentity through some protocol
means. When acting as a proxy, the SUBSCRIBE requests are
proxied to another entity that may act as a PA.
Edge Presence Server: An edge presence server is a presence agent
that is co-located 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
event package. The overview describes behavior that is documented in
part here, in part within the SIP event framework [2], and in part in
the SIP specification [1], in order to provide clarity on this
package for readers only casually familiar with those specifications.
However, the detailed semantics of this package require the reader to
be familiar with SIP events and the SIP specification itself.
When an entity, the subscriber, wishes to learn about presence
information from some user, it creates a SUBSCRIBE request. This
request identifies the desired presentity in the Request-URI, using a
SIP URI, SIPS URI [1] or a presence (pres) URI [3]. The SUBSCRIBE
request is carried along SIP proxies as any other SIP request would
be. In most cases, it eventually arrives at a presence server, which
can either generate a response to the request (in which case it acts
as the presence agent for the presentity), or proxy it on to an edge
presence server. If the edge presence server handles the
subscription, it is acting as the presence agent for the presentity.
The decision at a presence server about whether to proxy or terminate
the SUBSCRIBE is a local matter; however, we describe one way to
effect such a configuration, using REGISTER.
Rosenberg Standards Track [Page 4]
RFC 3856 SIP Presence August 2004
The presence agent (whether in the presence server or edge presence
server) first authenticates the subscription, then authorizes it.
The means for authorization are outside the scope of this protocol,
and we expect that many mechanisms will be used. If authorized, a
200 OK response is returned. If authorization could not be obtained
at this time, the subscription is considered "pending", and a 202
response is returned. In both cases, the PA sends an immediate
NOTIFY message containing the state of the presentity and of the
subscription. The presentity state may be bogus in the case of a
pending subscription, indicating offline no matter what the actual
state of the presentity, for example. This is to protect the privacy
of the presentity, who may not want to reveal that they have not
provided authorization for the subscriber. As the state of the
presentity changes, the PA generates NOTIFYs containing those state
changes to all subscribers with authorized subscriptions. Changes in
the state of the subscription itself can also trigger NOTIFY
requests; that state is carried in the Subscription-State header
field of the NOTIFY, and would typically indicate whether the
subscription is active or pending.
The SUBSCRIBE message establishes a "dialog" with the presence agent.
A dialog is defined in RFC 3261 [1], and it represents the SIP state
between a pair of entities to facilitate peer-to-peer message
exchanges. This state includes the sequence numbers for messages in
both directions (SUBSCRIBE from the subscriber, NOTIFY from the
presence agent), in addition to a route set and remote target URI.
The route set is a list of SIP (or SIPS) URIs which identify SIP
proxy servers that are to be visited along the path of SUBSCRIBE
refreshes or NOTIFY requests. The remote target URI is the SIP or
SIPS URI that identifies the target of the message - the subscriber,
in the case of NOTIFY, or the presence agent, in the case of a
SUBSCRIBE refresh.
SIP provides a procedure called record-routing that allows for proxy
servers to request to be on the path of NOTIFY messages and SUBSCRIBE
refreshes. This is accomplished by inserting a URI into the
Record-Route header field in the initial SUBSCRIBE request.
The subscription persists for a duration that is negotiated as part
of the initial SUBSCRIBE. The subscriber will need to refresh the
subscription before its expiration, if they wish to retain the
subscription. This is accomplished by sending a SUBSCRIBE refresh
within the same dialog established by the initial SUBSCRIBE. This
SUBSCRIBE is nearly identical to the initial one, but contains a tag
in the To header field, a higher CSeq header field value, and
possibly a set of Route header field values that identify the path of
proxies the request is to take.
Rosenberg Standards Track [Page 5]
RFC 3856 SIP Presence August 2004
The subscriber can terminate the subscription by sending a SUBSCRIBE,
within the dialog, with an Expires header field (which indicates
duration of the subscription) value of zero. This causes an
immediate termination of the subscription. A NOTIFY request is then
generated by the presence agent with the most recent state. In fact,
behavior of the presence agent for handling a SUBSCRIBE request with
Expires of zero is no different than for any other expiration value;
pending or authorized SUBSCRIBE requests result in a triggered NOTIFY
with the current presentity and subscription state.
The presence agent can terminate the subscription at any time. To do
so, it sends a NOTIFY request with a Subscription-State header field
indicating that the subscription has been terminated. A reason
parameter can be supplied which provides the reason.
It is also possible to fetch the current presence state, resulting in
a one-time notification containing the current state. This is
accomplished by sending a SUBSCRIBE request with an immediate
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -