📄 rfc 3856 a presence event package for the session initiation protocol (sip).htm
字号:
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
<A href="http://tools.ietf.org/html/rfc3856#section-1">1</A>. Introduction ................................................ <A href="http://tools.ietf.org/html/rfc3856#page-2">2</A>
<A href="http://tools.ietf.org/html/rfc3856#section-2">2</A>. Terminology ................................................. <A href="http://tools.ietf.org/html/rfc3856#page-3">3</A>
<A href="http://tools.ietf.org/html/rfc3856#section-3">3</A>. Definitions ................................................. <A href="http://tools.ietf.org/html/rfc3856#page-3">3</A>
<A href="http://tools.ietf.org/html/rfc3856#section-4">4</A>. Overview of Operation ....................................... <A href="http://tools.ietf.org/html/rfc3856#page-4">4</A>
<A href="http://tools.ietf.org/html/rfc3856#section-5">5</A>. Usage of Presence URIs ...................................... <A href="http://tools.ietf.org/html/rfc3856#page-6">6</A>
<A href="http://tools.ietf.org/html/rfc3856#section-6">6</A>. Presence Event Package ...................................... <A href="http://tools.ietf.org/html/rfc3856#page-7">7</A>
<A href="http://tools.ietf.org/html/rfc3856#section-6.1">6.1</A>. Package Name .......................................... <A href="http://tools.ietf.org/html/rfc3856#page-8">8</A>
<A href="http://tools.ietf.org/html/rfc3856#section-6.2">6.2</A>. Event Package Parameters .............................. <A href="http://tools.ietf.org/html/rfc3856#page-8">8</A>
<A href="http://tools.ietf.org/html/rfc3856#section-6.3">6.3</A>. SUBSCRIBE Bodies ...................................... <A href="http://tools.ietf.org/html/rfc3856#page-8">8</A>
<A href="http://tools.ietf.org/html/rfc3856#section-6.4">6.4</A>. Subscription Duration ................................. <A href="http://tools.ietf.org/html/rfc3856#page-9">9</A>
<A href="http://tools.ietf.org/html/rfc3856#section-6.5">6.5</A>. NOTIFY Bodies ......................................... <A href="http://tools.ietf.org/html/rfc3856#page-9">9</A>
<A href="http://tools.ietf.org/html/rfc3856#section-6.6">6.6</A>. Notifier Processing of SUBSCRIBE Requests ............. <A href="http://tools.ietf.org/html/rfc3856#page-9">9</A>
<A href="http://tools.ietf.org/html/rfc3856#section-6.6.1">6.6.1</A>. Authentication ................................. <A href="http://tools.ietf.org/html/rfc3856#page-10">10</A>
<A href="http://tools.ietf.org/html/rfc3856#section-6.6.2">6.6.2</A>. Authorization .................................. <A href="http://tools.ietf.org/html/rfc3856#page-10">10</A>
<A href="http://tools.ietf.org/html/rfc3856#section-6.7">6.7</A>. Notifier Generation of NOTIFY Requests ................ <A href="http://tools.ietf.org/html/rfc3856#page-11">11</A>
<SPAN class=grey>Rosenberg Standards Track [Page 1]</SPAN>
<A id=page-2 href="http://tools.ietf.org/html/rfc3856#page-2" name=page-2><SPAN class=break> </SPAN></A>
<SPAN class=grey><A href="http://tools.ietf.org/html/rfc3856">RFC 3856</A> SIP Presence August 2004</SPAN>
<A href="http://tools.ietf.org/html/rfc3856#section-6.8">6.8</A>. Subscriber Processing of NOTIFY Requests .............. <A href="http://tools.ietf.org/html/rfc3856#page-13">13</A>
<A href="http://tools.ietf.org/html/rfc3856#section-6.9">6.9</A>. Handling of Forked Requests ........................... <A href="http://tools.ietf.org/html/rfc3856#page-13">13</A>
<A href="http://tools.ietf.org/html/rfc3856#section-6.10">6.10</A>. Rate of Notifications ................................. <A href="http://tools.ietf.org/html/rfc3856#page-14">14</A>
<A href="http://tools.ietf.org/html/rfc3856#section-6.11">6.11</A>. State Agents .......................................... <A href="http://tools.ietf.org/html/rfc3856#page-14">14</A>
6.11.1. Aggregation, Authentication, and Authorization. 14
<A href="http://tools.ietf.org/html/rfc3856#section-6.11.2">6.11.2</A>. Migration ..................................... <A href="http://tools.ietf.org/html/rfc3856#page-15">15</A>
<A href="http://tools.ietf.org/html/rfc3856#section-7">7</A>. Learning Presence State ..................................... <A href="http://tools.ietf.org/html/rfc3856#page-16">16</A>
<A href="http://tools.ietf.org/html/rfc3856#section-7.1">7.1</A>. Co-location ........................................... <A href="http://tools.ietf.org/html/rfc3856#page-16">16</A>
<A href="http://tools.ietf.org/html/rfc3856#section-7.2">7.2</A>. REGISTER .............................................. <A href="http://tools.ietf.org/html/rfc3856#page-16">16</A>
<A href="http://tools.ietf.org/html/rfc3856#section-7.3">7.3</A>. Uploading Presence Documents .......................... <A href="http://tools.ietf.org/html/rfc3856#page-17">17</A>
<A href="http://tools.ietf.org/html/rfc3856#section-8">8</A>. Example Message Flow ........................................ <A href="http://tools.ietf.org/html/rfc3856#page-17">17</A>
<A href="http://tools.ietf.org/html/rfc3856#section-9">9</A>. Security Considerations ..................................... <A href="http://tools.ietf.org/html/rfc3856#page-20">20</A>
<A href="http://tools.ietf.org/html/rfc3856#section-9.1">9.1</A>. Confidentiality ....................................... <A href="http://tools.ietf.org/html/rfc3856#page-20">20</A>
<A href="http://tools.ietf.org/html/rfc3856#section-9.2">9.2</A>. Message Integrity and Authenticity .................... <A href="http://tools.ietf.org/html/rfc3856#page-21">21</A>
<A href="http://tools.ietf.org/html/rfc3856#section-9.3">9.3</A>. Outbound Authentication ............................... <A href="http://tools.ietf.org/html/rfc3856#page-22">22</A>
<A href="http://tools.ietf.org/html/rfc3856#section-9.4">9.4</A>. Replay Prevention ..................................... <A href="http://tools.ietf.org/html/rfc3856#page-22">22</A>
<A href="http://tools.ietf.org/html/rfc3856#section-9.5">9.5</A>. Denial of Service Attacks Against Third Parties ....... <A href="http://tools.ietf.org/html/rfc3856#page-22">22</A>
<A href="http://tools.ietf.org/html/rfc3856#section-9.6">9.6</A>. Denial Of Service Attacks Against Servers ............. <A href="http://tools.ietf.org/html/rfc3856#page-23">23</A>
<A href="http://tools.ietf.org/html/rfc3856#section-10">10</A>. IANA Considerations ......................................... <A href="http://tools.ietf.org/html/rfc3856#page-23">23</A>
<A href="http://tools.ietf.org/html/rfc3856#section-11">11</A>. Contributors ................................................ <A href="http://tools.ietf.org/html/rfc3856#page-24">24</A>
<A href="http://tools.ietf.org/html/rfc3856#section-12">12</A>. Acknowledgements ............................................ <A href="http://tools.ietf.org/html/rfc3856#page-25">25</A>
<A href="http://tools.ietf.org/html/rfc3856#section-13">13</A>. Normative References ........................................ <A href="http://tools.ietf.org/html/rfc3856#page-25">25</A>
<A href="http://tools.ietf.org/html/rfc3856#section-14">14</A>. Informative References ...................................... <A href="http://tools.ietf.org/html/rfc3856#page-26">26</A>
<A href="http://tools.ietf.org/html/rfc3856#section-15">15</A>. Author's Address ............................................ <A href="http://tools.ietf.org/html/rfc3856#page-26">26</A>
<A href="http://tools.ietf.org/html/rfc3856#section-16">16</A>. Full Copyright Statement .................................... <A href="http://tools.ietf.org/html/rfc3856#page-27">27</A>
<SPAN class=h2><A name=section-1>1</A>. Introduction</SPAN>
Presence, also known as presence information, conveys the ability and
willingness of a user to communicate across a set of devices. <A href="http://tools.ietf.org/html/rfc2778">RFC</A>
<A href="http://tools.ietf.org/html/rfc2778">2778</A> [<A title='"A Model for Presence and Instant Messaging"' href="http://tools.ietf.org/html/rfc3856#ref-10">10</A>] 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) [<A title='"SIP: Session Initiation Protocol"' href="http://tools.ietf.org/html/rfc3856#ref-1">1</A>] as a presence protocol. This is accomplished through a
concrete instantiation of the general event notification framework
defined for SIP [<A title='"Session Initiation Protocol (SIP)-Specific Event Notification"' href="http://tools.ietf.org/html/rfc3856#ref-2">2</A>], and as such, makes use of the SUBSCRIBE and
NOTIFY methods defined there. Specifically, this document defines an
event package, as described in <A href="http://tools.ietf.org/html/rfc3265">RFC 3265</A> [<A title='"Session Initiation Protocol (SIP)-Specific Event Notification"' href="http://tools.ietf.org/html/rfc3856#ref-2">2</A>]. 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
<SPAN class=grey>Rosenberg Standards Track [Page 2]</SPAN>
<A id=page-3 href="http://tools.ietf.org/html/rfc3856#page-3" name=page-3><SPAN class=break> </SPAN></A>
<SPAN class=grey><A href="http://tools.ietf.org/html/rfc3856">RFC 3856</A> SIP Presence August 2004</SPAN>
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 [<A title='"Common Profile for Presence (CPP)"' href="http://tools.ietf.org/html/rfc3856#ref-3">3</A>]. This allows SIP for
presence to easily interwork with other presence systems compliant to
CPP.
<SPAN class=h2><A name=section-2>2</A>. Terminology</SPAN>
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 <A href="http://tools.ietf.org/html/rfc2119">RFC 2119</A> [<A title='"Key Words for Use in RFCs to Indicate Requirement Levels"' href="http://tools.ietf.org/html/rfc3856#ref-4">4</A>] and
indicate requirement levels for compliant implementations.
<SPAN class=h2><A name=section-3>3</A>. Definitions</SPAN>
This document uses the terms as defined in <A href="http://tools.ietf.org/html/rfc2778">RFC 2778</A> [<A title='"A Model for Presence and Instant Messaging"' href="http://tools.ietf.org/html/rfc3856#ref-10">10</A>].
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.
<SPAN class=grey>Rosenberg Standards Track [Page 3]</SPAN>
<A id=page-4 href="http://tools.ietf.org/html/rfc3856#page-4" name=page-4><SPAN class=break> </SPAN></A>
<SPAN class=grey><A href="http://tools.ietf.org/html/rfc3856">RFC 3856</A> SIP Presence August 2004</SPAN>
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 <A href="http://tools.ietf.org/html/rfc3265">RFC 3265</A> [<A title='"Session Initiation Protocol (SIP)-Specific Event Notification"' href="http://tools.ietf.org/html/rfc3856#ref-2">2</A>]) 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.
<SPAN class=h2><A name=section-4>4</A>. Overview of Operation</SPAN>
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 [<A title='"Session Initiation Protocol (SIP)-Specific Event Notification"' href="http://tools.ietf.org/html/rfc3856#ref-2">2</A>], and in part in
the SIP specification [<A title='"SIP: Session Initiation Protocol"' href="http://tools.ietf.org/html/rfc3856#ref-1">1</A>], 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 [<A title='"SIP: Session Initiation Protocol"' href="http://tools.ietf.org/html/rfc3856#ref-1">1</A>] or a presence (pres) URI [<A title='"Common Profile for Presence (CPP)"' href="http://tools.ietf.org/html/rfc3856#ref-3">3</A>]. 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.
<SPAN class=grey>Rosenberg Standards Track [Page 4]</SPAN>
<A id=page-5 href="http://tools.ietf.org/html/rfc3856#page-5" name=page-5><SPAN class=break> </SPAN></A>
<SPAN class=grey><A href="http://tools.ietf.org/html/rfc3856">RFC 3856</A> SIP Presence August 2004</SPAN>
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
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -