Request for Comments: 3680 dynamicsoft
Category: Standards Track March 2004
A Session Initiation Protocol (SIP) Event Package for Registrations
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). All Rights Reserved.
Abstract
This document defines a Session Initiation Protocol (SIP) event
package for registrations. Through its REGISTER method, SIP allows a
user agent to create, modify, and delete registrations.
Registrations can also be altered by administrators in order to
enforce policy. As a result, these registrations represent a piece
of state in the network that can change dynamically. There are many
cases where a user agent would like to be notified of changes in this
state. This event package defines a mechanism by which those user
agents can request and obtain such notifications.
Table of Contents
1. Introduction ................................................. 2
2. Terminology .................................................. 3
3. Usage Scenarios .............................................. 3
3.1. Forcing Re-Authentication .............................. 3
3.2. Composing Presence ..................................... 3
3.3. Welcome Notices ........................................ 4
4. Package Definition ........................................... 4
4.1. Event Package Name ..................................... 4
4.2. Event Package Parameters ............................... 5
4.3. SUBSCRIBE Bodies ....................................... 5
4.4. Subscription Duration .................................. 5
4.5. NOTIFY Bodies .......................................... 6
4.6. Notifier Processing of SUBSCRIBE Requests .............. 6
4.7. Notifier Generation of NOTIFY Requests ................. 7
4.7.1. The Registration State Machine ................. 7
4.7.2. Applying the state machine ..................... 9
4.8. Subscriber Processing of NOTIFY Requests ............... 9
4.9. Handling of Forked Requests ............................ 9
4.10. Rate of Notifications .................................. 10
4.11. State Agents ........................................... 10
5. Registration Information ..................................... 10
5.1. Structure of Registration Information .................. 10
5.2. Computing Registrations from the Document .............. 14
5.3. Example ................................................ 15
5.4. XML Schema ............................................. 16
6. Example Call Flow ............................................ 18
7. Security Considerations ...................................... 21
8. IANA Considerations .......................................... 21
8.1. SIP Event Package Registration ......................... 21
8.2. application/reginfo+xml MIME Registration .............. 22
8.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:reginfo ......................... 23
9. References ................................................... 23
9.1. Normative References ................................... 23
9.2. Informative References ................................. 24
10. Contributors ................................................. 25
11. Acknowledgements ............................................. 25
12. Author’s Address ............................................. 25
13. Full Copyright Statement ..................................... 26
1. Introduction
The Session Initiation Protocol (SIP) [1] provides all of the
functions needed for the establishment and maintenance of
communications sessions between users. One of the functions it
provides is a registration operation. A registration is a binding
between a SIP URI, called an address-of-record, and one or more
contact URIs. These contact URIs represent additional resources that
can be contacted in order to reach the user identified by the
address-of-record. When a proxy receives a request within its domain
of administration, it uses the Request-URI as an address-of-record,
and uses the contacts bound to the address-of-record to forward (or
redirect) the request.
The SIP REGISTER method provides a way for a user agent to manipulate
registrations. Contacts can be added or removed, and the current set
of contacts can be queried. Registrations can also change as a
result of administrator policy. For example, if a user is suspected
of fraud, their registration can be deleted so that they cannot
receive any requests. Registrations also expire after some time if
not refreshed.
Registrations represent a dynamic piece of state maintained by the
network. There are many cases in which user agents would like to
know about changes to the state of registrations. The SIP Events
Framework [2] defines a generic framework for subscription to, and
notification of, events related to SIP systems. The framework
defines the methods SUBSCRIBE and NOTIFY, and introduces the notion
of a package. A package is a concrete application of the event
framework to a particular class of events. Packages have been
defined for user presence [9], for example. This specification
defines a package for registration state.
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 BCP 14, RFC 2119
[3] and indicate requirement levels for compliant implementations.
3. Usage Scenarios
There are many applications of this event package. A few are
documented here for illustrative purposes.
3.1. Forcing Re-Authentication
It is anticipated that many SIP devices will be wireless devices that
will be always-on, and therefore, continually registered to the
network. Unfortunately, history has shown that these devices can be
compromised. To deal with this, an administrator will want to
terminate or shorten a registration, and ask the device to
re-register so it can be re-authenticated. To do this, the device
subscribes to the registration event package for the
address-of-record that it is registering contacts against. When the
administrator shortens registration (for example, when fraud is
suspected) the registration server sends a notification to the
device. It can then re-register and re-authenticate itself. If it
cannot re-authenticate, the expiration will terminate shortly
thereafter.
3.2. Composing Presence
An important concept to understand is the relationship between this
event package and the event package for user presence [9]. User
presence represents the willingness and ability of a user to
communicate with other users on the network. It is composed of a set
of contact addresses that represent the various means for contacting
the user. Those contact addresses might represent the contact
address for voice, for example. Typically, the contact address
listed for voice will be an address-of-record. The status of that
contact (whether its open or closed) may depend on any number of
factors, including the state of any registrations against that
address-of-record. As a result, registration state can be viewed as
an input to the process which determines the presence state of a
user. Effectively, registration state is "raw" data, which is
combined with other information about a user to generate a document
that describes the user’s presence.
In fact, this event package allows for a presence server to be
separated from a SIP registration server, yet still use registration
information to construct a presence document. When a presence server
receives a presence subscription for some user, the presence server
itself would generate a subscription to the registration server for
the registration event package. As a result, the presence server
would learn about the registration state for that user, and it could
use that information to generate presence documents.
3.3. Welcome Notices
A common service in current mobile networks are "welcome notices".
When the user turns on their phone in a foreign country, they receive
a message that welcomes them to the country, and provides information
on transportation services, for example.
In order to implement this service in a SIP system, an application
server can subscribe to the registration state of the user. When the
user turns on their phone, the phone will generate a registration.
This will result in a notification being sent to the application that
the user has registered. The application can then send a SIP MESSAGE
request [10] to the device, welcoming the user and providing any
necessary information.
4. Package Definition
This section fills in the details needed to specify an event package
as defined in Section 4.4 of [2].
4.1. Event Package Name
The SIP Events specification requires package definitions to specify
the name of their package or template-package.
The name of this package is "reg". As specified in [2], this value
appears in the Event header present in SUBSCRIBE and NOTIFY requests.
Example:
Event: reg
4.2. Event Package Parameters
The SIP Events specification requires package and template-package
definitions to specify any package specific parameters of the Event
header that are used by it.
No package specific Event header parameters are defined for this
event package.
4.3. SUBSCRIBE Bodies
The SIP Events specification requires package or template-package
definitions to define the usage, if any, of bodies in SUBSCRIBE
requests.
A SUBSCRIBE for registration events MAY contain a body. This body
would serve the purpose of filtering the subscription. The
definition of such a body is outside the scope of this specification.
A SUBSCRIBE for the registration package MAY be sent without a body.
This implies that the default registration filtering policy has been
requested. The default policy is:
o Notifications are generated every time there is any change in
the state of any of the registered contacts for the resource
being subscribed to. Those notifications only contain
information on the contacts whose state has changed.
o Notifications triggered from a SUBSCRIBE contain full state
(the list of all contacts bound to the address-of-record).
Of course, the server can apply any policy it likes to the
subscription.
4.4. Subscription Duration
The SIP Events specification requires package definitions to define a
default value for subscription durations, and to discuss reasonable
choices for durations when they are explicitly specified.
Registration state changes as contacts are created through REGISTER
requests, and then time out due to lack of refresh. Their rate of
change is therefore related to the typical registration expiration.
Since the default expiration for registrations is 3600 seconds, the
default duration of subscriptions to registration state is slightly
longer, 3761 seconds. This helps avoid any potential problems with
coupling of subscription and registration refreshes. Of course,
clients MAY include an Expires header in the SUBSCRIBE request asking
for a different duration.
4.5. NOTIFY Bodies
The SIP Events specification requires package definitions to describe
the allowed set of body types in NOTIFY requests, and to specify the
default value to be used when there is no Accept header in the
SUBSCRIBE request.
The body of a notification of a change in registration state contains
a registration information document. This document describes some or
all of the contacts associated with a particular address-of-record.
All subscribers and notifiers MUST support the
"application/reginfo+xml" format described in Section 5. The
subscribe request MAY contain an Accept header field. If no such
header field is present, it has a default value of
"application/reginfo+xml". If the header field is present, it MUST
include "application/reginfo+xml", and MAY include any other types
capable of representing registration information.
Of course, the notifications generated by the server MUST be in one
of the formats specified in the Accept header field in the SUBSCRIBE
request.
4.6. Notifier Processing of SUBSCRIBE Requests
The SIP Events framework specifies that packages should define any
package-specific processing of SUBSCRIBE requests at a notifier,
specifically with regards to authentication and authorization.
Registration state can be sensitive information. Therefore, all
subscriptions to it SHOULD be authenticated and authorized before
approval. Authentication MAY be performed using any of the
techniques available through SIP, including digest, S/MIME, TLS or
other transport specific mechanisms [1]. Authorization policy is at
the discretion of the administrator, as always. However, a few
recommendations can be made.
It is RECOMMENDED that a user be allowed to subscribe to their own
registration state. Such subscriptions are useful when there are
many devices that represent a user, each of which needs to learn the
registration state of the other devices. We also anticipate that
applications and automata will frequently be subscribers to the
registration state. In those cases, authorization policy will
typically be provided ahead of time.
4.7. Notifier Generation of NOTIFY Requests
The SIP Event framework requests that packages specify the conditions
under which notifications are sent for that package, and how such
notifications are constructed.
To determine when a notifier should send notifications of changes in
registration state, we define a finite state machine (FSM) that
represents the state of a contact for a particular address-of-record.
Transitions in this state machine MAY result in the generation of
notifications. These notifications will carry information on the new
state and the event which triggered the state change. It is
important to note that this FSM is just a model of the registration
state machinery maintained by a server. An implementation would map
its own state machines to this one in an implementation-specific
manner.
4.7.1. The Registration State Machine
The underlying state machine for a registration is shown in Figure 1.
The machine is very simple. An instance of this machine is
associated with each address-of-record. When there are no contacts
registered to the address-of-record, the state machine is in the init
state. It is important to note that this state machine exists, and
is well-defined, for each address-of-record in the domain, even if
there are no contacts registered to it. This allows a user agent to
subscribe to an address-of-record, and learn that there are no
contacts registered to it. When the first contact is registered to
that address-of-record, the state machine moves from init to active.
+------------+
| |
| Init |
| |
+------------+
|
V
+------------+
| |
| Active |
| |
+------------+
|
V
+------------+
| |
| Terminated |
| |
+------------+
Figure 1: Registration State Machine
As long as there is at least one contact bound to the address-of-
record, the state machine remains in the active state. When the last
contact expires or is removed, the registration transitions to
terminated. From there, it immediately transitions back to the init
state. This transition is invisible, in that it MUST NOT ever be
reported to a subscriber in a NOTIFY request.
This allows for an implementation optimization whereby the
registrar can destroy the objects associated with the registration
state machine once it enters the terminated state and a NOTIFY has
been sent. Instead, the registrar can assume that, if the objects
for that state machine no longer exist, the state machine is in
the init state.
In addition to this state machine, each registration is associated
with a set of contacts, each of which is modeled with its own state
machine. Unlike the FSM for the address-of-record, which exists even
when no contacts are registered, the per-contact FSM is instantiated
when the contact is registered, and deleted when it is removed. The
diagram for the per-contact state machine is shown in Figure 2. This
FSM is identical to the registration state machine in terms of its
states, but has many more transition events.
When a new contact is added, the FSM for it is instantiated, and it
moves into the active state. Because of that, the init state here is
transient. There are two ways in which it can become active. One is
through an actual SIP REGISTER request (corresponding to the
registered event), and the other is when the contact is created
administratively, or through some non-SIP means (the created event).
+------+
| | refreshed
| | shortened
V |
+------------+ +------------+ +------------+
| | | | | |
| Init |----------->| Active |----------->| Terminated |
| | | | | |
+------------+ registered +------------+ expired +------------+
created deactivated
probation
unregistered
rejected
Figure 2: Contact State Machine
The FSM remains in the active state so long as the contact is bound
to the address-of-record. When a contact is refreshed through a
REGISTER request, the FSM stays in the same state, but a refreshed
event is generated. Likewise, when an administrator modifies the
expiration time of a binding (without deleting the binding) to
trigger the contact to re-register and possibly re-authenticate, the
FSM stays in the active state, but a shortened event is generated.
When the contact is no longer bound to the address-of-record, the FSM
moves to the terminated state, and once a NOTIFY is sent, the state
machine is destroyed. As a result, the terminated state is
effectively transient. There are several reasons this can happen.
The first is an expiration, which occurs when the contact was not
refreshed by a REGISTER request. The second reason is deactivated.
This occurs when the administrator has removed the contact as a valid
binding, but still wishes the client to attempt to re-register the
contact. In contrast, the rejected event occurs when an active
contact is removed by the administrator, but
re-registrations will not help to re-establish it. This might occur
if a user does not pay their bills, for example. The probation event
occurs when an active contact is removed by the administrator, and
the administrator wants the client to re-register, but to do so at a
later time. The unregistered event occurs when a REGISTER request
sets the expiration time of that contact to zero.
4.7.2. Applying the state machine
The server MAY generate a notification to subscribers when any event
occurs in either the address-of-record or per-contact state machines,
except for the transition from terminated to init in the address-of-
record state machine. As noted above, a notification MUST NOT be sent
in this case. For other transitions, whether the server sends a
notification or not is policy dependent. However, several guidelines
are defined.
As a general rule, when a subscriber is authorized to receive
notifications about a set of registrations, it is RECOMMENDED that
notifications contain information about those contacts which have
changed state (and thus triggered a notification), instead of
delivering the current state of every contact in all registrations.
However, notifications triggered as a result of a fetch operation (a
SUBSCRIBE with Expires of 0) SHOULD result in the full state of all
contacts for all registrations to be present in the NOTIFY.
4.8. Subscriber Processing of NOTIFY Requests
The SIP Events framework expects packages to specify how a subscriber
processes NOTIFY requests in any package specific ways, and in
particular, how it uses the NOTIFY requests to construct a coherent
view of the state of the subscribed resource. Typically, the NOTIFY
will only contain information for contacts whose state has changed.
To construct a coherent view of the total state of all registrations,
the subscriber will need to combine NOTIFYs received over time. The
details of this process depend on the document format used to convey
registration state. Section 5 outlines the process for the
application/reginfo+xml format.
4.9. Handling of Forked Requests
The SIP Events framework mandates that packages indicate whether or
not forked SUBSCRIBE requests can install multiple subscriptions.
Registration state is normally stored in some repository (whether it
be co-located with a proxy/registrar or in a separate database). As
such, there is usually a single place where the contact information
for a particular address-of-record is resident. This implies that a
subscription for this information is readily handled by a single
element with access to this repository. There is, therefore, no