Internet DRAFT - draft-rosenberg-sipping-reg-sub
draft-rosenberg-sipping-reg-sub
SIPPING J. Rosenberg
Internet-Draft Cisco Systems
Expires: January 14, 2006 July 13, 2005
Registration Coupled Subscriptions in the Session Initiation Protocol
(SIP)
draft-rosenberg-sipping-reg-sub-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on January 14, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
When a Session Initiation Protocol (SIP) user agent starts up, it
registers to the network and initiates numerous subscriptions in
order to learn about various network events. This results in a
chatty startup procedure which substantially impacts recovery times
under avalanche restart. This specification proposes a mechanism
whereby the subscriptions can be established as a side effect of the
registration, alleviating this problem.
Rosenberg Expires January 14, 2006 [Page 1]
Internet-Draft Registration Coupled Subscriptions July 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Overview of Operation . . . . . . . . . . . . . . . . . . 5
3.2 User Agent Behavior . . . . . . . . . . . . . . . . . . . 8
3.3 Registrar Behavior . . . . . . . . . . . . . . . . . . . . 9
3.3.1 REGISTER Processing . . . . . . . . . . . . . . . . . 9
3.3.2 PUBLISH Processing . . . . . . . . . . . . . . . . . . 10
3.4 Event Server Behavior . . . . . . . . . . . . . . . . . . 11
3.5 Subscription Header Field . . . . . . . . . . . . . . . . 13
3.6 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.6.1 Registrar has Dialog Ownership . . . . . . . . . . . . 14
3.6.2 Event Server Owned Dialog . . . . . . . . . . . . . . 16
3.6.3 Hybrid Model . . . . . . . . . . . . . . . . . . . . . 17
4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1 Normative References . . . . . . . . . . . . . . . . . . . 18
4.2 Informative References . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . 20
Rosenberg Expires January 14, 2006 [Page 2]
Internet-Draft Registration Coupled Subscriptions July 2005
1. Introduction
When a Session Initiation Protocol (SIP) [1] user agent starts up, it
typically follows a series of message exchanges with servers in the
network. At a minimum, this startup procedure involves a SIP
registration that allows the user agent to receive incoming requests.
However, over time, numerous event packages [2] have been defined
that provide a user agent with useful information through the
duration of its connection to the network. These packages include:
Message Waiting: RFC 3842 [11] provides a message waiting indication
event package. Typically, a user agent would subscribe to its own
Address-of-Record (AOR) for this event package, in order to find
out about messages that have been left for that user. This
provides the familiar "message waiting lamp" on many business
telephones. It is valuable for a user agent to subscribe to this
package through the duration of its registration, in the event
that messages are explicitly directed to a user's voicemail and do
not ring their phone (this can happen, for example, if the caller
utilizes the caller preferences specification [12] to direct a
call to voicemail).
Registration Event: RFC 3680 [13] allows a user agent to learn about
the status of its registration. Typically, a user agent would
subscribe to its own AOR for this event package, in order to find
out if the network has removed its registration. Such removals
happen in cases of graceful network shutdown, or when a user needs
to re-register and re-authenticate due to concerns on validity of
credentials.
Presence List: A user may have a "buddy list", which contains a list
of users whose presence is desired. A user will subscribe to
their buddy list using an event list subscription [14] to the
presence event package [15]. This is done by subscribing to a
resource that is synonomous with the user's own buddy list.
Watcher Info: In order to find out about attempts that have been made
to subscribe to a users presence, that user makes use of the
watcher info event template package [16]. They would do this by
subscribing to their own AOR with the presence.winfo event
package. Subscription attempts that are unauthorized will result
in a notification, informing the user of this fact and allowing
them to approve or deny the subscription.
Dialog Events: Certain features, such as single line extension,
require a user agent to find out about calls in progress on other
user agents associated with the same AOR. This is done through
subscriptions to the dialog event package [17]. The user agent
Rosenberg Expires January 14, 2006 [Page 3]
Internet-Draft Registration Coupled Subscriptions July 2005
would typically subscribe to their own AOR, and learn about calls
in progress to other user agents.
Configuration Events: The configuration event package [18] allows a
UA to learn about changes in its configuration. This is done by
having the UA subscribe to its own identity (which may be the AOR)
for the config event package.
As a consequence of this, each time a user agent starts up, they will
generate a REGISTER transaction, plus a SUBSCRIBE and a NOTIFY
transaction for each event package the user agent is interested in.
Based on the above discussion, this could be upwards of six event
packages, resulting in a total of fourteen transactions that take
place on startup. Furthermore, each of these subscriptions needs to
be periodically refreshed (as does the registration), resulting in
ongoing messaging.
This overhead is particularly problematic during an avalanche
restart. This occurs when a failure event of some sort causes all
user agents to simultaneously re-register. This is most common when
recovering after a power outage. When the power returns, all the
user agents will start booting simultaneously, and at the same time,
each will execute their startup sequence. The more complex this
sequence, the longer it takes for the system to return to service,
and the more robust the network has to be. Another cause of
avalanche restart is recovery after a catastrophic network failure,
such as a network partition. If a network partition should last
longer than the subscription lifetime, once the partition heals, each
client will discover this and attempt to re-register and re-subscribe
to each event package.
The overhead is also problematic on wireless links and other
interfaces where bandwidth is at a premium.
2. Requirements
A solution to this problem should meet the following requirements:
1. The solution must substantially reduce the amount of SIP
messaging traffic that takes place when a user agent starts up.
2. The solution must substantially reduce the amount of network
processing that needs to take place when a user agent starts up.
3. The solution must not fundamentally alter the event model of
RFC3265.
Rosenberg Expires January 14, 2006 [Page 4]
Internet-Draft Registration Coupled Subscriptions July 2005
3. Proposed Solution
This document proposes a solution to this problem, based on the
following observations:
1. In all of the above cases, the subscription is desired for the
duration of the registration of the UA.
2. In all of the above cases, the user agent is subscribing to a
resource which it owns; either its AOR or a related resource,
like a buddy list. As a consequence, the authorization policies
for the subscriptions always allow that user to subscribe. A
policy in which a user can subscribe to their own events are
called "self authorization".
3.1 Overview of Operation
Based on these observations, the approach proposed here is to
strongly couple subscriptions with registrations, and to actually use
the registration to create the subscriptions. A subscription that is
created as a result of a successful registration is called a
registration-coupled subscription. The basic approach is shown in
Rosenberg Expires January 14, 2006 [Page 5]
Internet-Draft Registration Coupled Subscriptions July 2005
+-----------+ +-----------+ +-----------+
| | | | | |
| Event | | Event | | Event |
| Server | | Server | | Server |
| | | | | |
+-----------+ +-----------+ +-----------+
\ | /
\ | /
\ | /
\ | /
\ | / PUBLISH
\ | /
V V /
+-----------+ V
| |
| Registrar |
| |
| |
+-----------+
|
|
|
| REGISTER+
| NOTIFY
|
+--------+
| |
| UA |
| |
+--------+
Figure 1
To create a registration-coupled subscription, a UA includes a
Subscription header field in its REGISTER message. This header field
includes a list of the desired event packages, and for each, the
resource to which a subscription is desired and any event header
field parameters. There is no need for a Require header field. The
registrar looks for the Subscription header field. For each value,
it examines the event package and target resource. If the resource
is in the domain of the registrar, and the resource has an
authorization policy of "self", and the registrar allows registration
coupled subscriptions for that event package, the registrar creates
the dialog and a subscription. The 200 OK to the REGISTER contains
an indication of whether the subscription was created, and if so, the
remote tag needed to complete the dialog identifier.
The UAC will create a dialog and a subscription for each value of the
Rosenberg Expires January 14, 2006 [Page 6]
Internet-Draft Registration Coupled Subscriptions July 2005
Subscription header field in the response. As there will be one of
these per event package, the end result is a single dialog for each
event package that the client wants to subscribe to. Dialogs are not
shared across event packages. The dialog identifiers are obtained by
copying the Call-ID and local tag from the REGISTER, with the remote
tag from the Subscription header field value. Similarly, the
registrar will create a subscription. The dialog identifiers and
local sequence number are set in the same way. Its route set is
taken from the Path header field from the registration [4].
At this point, a proper subscription is established at the UA and the
registrar. The registrar can send a NOTIFY at any time. The initial
NOTIFY normally sent upon receipt of a SUBSCRIBE is not required, as
the REGISTER response serves that purpose. The subscriptions are all
refreshed through registration refreshes. If the UAC omits an event
and resource from a Subscription header field in its REGISTER, it
means that the client wishes to unsubscribe. Similarly, if the 200
OK to the REGISTER omits that event package and resource, it means
that the subscription was terminated. However, the client cannot
ever send a SUBSCRIBE to refresh the subscription. Any such request
is rejected with a 403.
It is important to note that there is a dialog properly established
as part of this mechanism. The dialog is established by providing
the dialog parameters through the registration, and then to make the
dialog state part of the registration state. The dialog is then
refreshed and maintained just like registration state. If a user has
multiple user agents registered to the same AOR, multiple dialogs
would be created. This means that the dialogs terminate on the
registrar as well. In order for events to be delivered to the
clients in NOTIFY messages, an event server generates a PUBLISH
message when it wants to send an event to a user agent. The PUBLISH
is routed to the registrar, where it examines the URI in the request
URI. If the user is registered, it goes through each registered
contact. If the registration of that contact had created a coupled
subscription, the registrar checks if the registration-coupled
subscriptions include the event package in the PUBLISH. If they do,
the registrar copies the event data in the body of the PUBLISH into a
NOTIFY, and sends it to the user agent.
As an additional mechanism, the event servers themselves can
subscribe to the registration event package for all subscribers.
WHenever a user registers, a notification would get delivered to the
event server. It can then check which users are registered or not,
and use this information to determine whether or not it wishes to
send a PUBLISH. Alternatively, the reg-event notifications can
contian all of the information on the registration-coupled
subscriptions - their dialog identifiers, event packages, and so on.
Rosenberg Expires January 14, 2006 [Page 7]
Internet-Draft Registration Coupled Subscriptions July 2005
This would allow the event server itself to "take over" the
subscription, and take ownership of the dialog. In that case, it can
send the NOTIFY directly, instead of sending a PUBLISH to the
registrar. Indeed, the event server can make a decision on a
subscriber-by-subscriber basis as to whether it wishes to own the
dialogs or not.
3.2 User Agent Behavior
A user agent SHOULD be configured with a set of event packages that
it wishes to couple with its registrations. For each such package,
when the client performs its initial registration, it includes a
Subscription header field value into its request. That value
contains the address-of-record for the target of the subscription.
This AOR MUST be one within the same domain as the domain of
registration. Typically, it will be the same as the AOR for the user
themselves. The UA includes any parameters it would otherwise
include in the Event header field into the Subscription header field.
The UA SHOULD include an Accept header field in the request, and
include the content types the client supports for that event package.
Otherwise, the registration is generated identically to a normal
registration.
If the response to the REGISTER is a 200 OK, the client looks for the
Subscription header field. If the header field is not present, the
user agent knows that either this mechanism is not supported in the
registar, or is supported, but not in use for any of the event
packages requested by the client. In that case, the user agent
SHOULD proceed with a normal subscription according to the specifics
of the event packages the client is interested in.
If the 200 OK response to the REGISTER did contain a Subscription
header field, the user agent goes through each value. It constructs
a dialog by setting the Call-ID to the value in the REGISTER
response, the local tag to the From tag the client placed in the
REGISTER request, and the remote tag from the value of the
Subscription header field. The local URI is set to the value in the
From header field of the REGISTER request, and the remote URI to the
value in the To header field of the REGISTER request. The local and
remote CSeq are initially empty. Since the client never sends a
request within the dialog, the local CSeq never needs to be
populated. Similarly, the route set is empty. If the REGISTER
request was sent over TLS, and the Request-URI was a sips URI, the
"secure" flag for the dialog is set.
The dialog state persists for the duration of the registration of
that contact. When the UA determines that the contact expires, the
dialog state is destroyed. A UA can determine that a contact has
Rosenberg Expires January 14, 2006 [Page 8]
Internet-Draft Registration Coupled Subscriptions July 2005
expired because it times out and is not refreshed, or because the
client receives a registration event notification informing it that
the contact has been terminated.
If the client had included a Subscription header field in the request
for a particular event package, and the REGISTER response contained a
Subscrption header field, but that package was not listed, it means
that the registrar is either refusing a subscription-coupled
registration for that event package, or that subscription failed for
some reason. To determine the exact problem, the client SHOULD
perform a regular, separate subscription to that event package.
At any point during the lifetime of the registration, the client may
receive a NOTIFY on the dialog created by the registration.
Processing of that NOTIFY happens as described in the relevant event
package and according to the details of RFC 3265.
A registration refresh occurs identically to an initial registration.
A client MUST include a Subscription header field value for each
dialog it wishes to retain. If a client omits a Subscription header
field value for a particular event package, the dialog associated
with that event package is terminated upon receipt of a 200 OK to the
REGISTER request.
If a client wishes to perform a subscription with event filters that
need to be placed in the body of a request, the mechanism here cannot
be used. Rather, the client should perform a normal subscription
using SUBSCRIBE. An alternative would be to include the event
filters as a body of the REGISTER request. Header field parameters
could associated each MIME body with a particular event package.
However, this introduces a lot of complexity for a corner case. As
such, this document recommends just performing a regular subscription
to handle these cases.
3.3 Registrar Behavior
3.3.1 REGISTER Processing
When a registrar receives a REGISTER request, it processes the
registration normally per RFC 3261. If the result would otherwise
have been a successful registration resulting in a 200 OK, the
procedures defined here are followed.
The registrar checks for the presence of the Subscription header
field in the REGISTER request. The processing that follows is
performed for each value of this header field. Firstly, the
registrar checks to see if it supports registration-coupled
subscriptions for that particular event package. Performing them for
Rosenberg Expires January 14, 2006 [Page 9]
Internet-Draft Registration Coupled Subscriptions July 2005
any particular event package is a matter of local policy. Typically,
it would be allowed when an event server is present in the network
which supports the capabilities defined here. If the registrar
doesn't support registration-coupled subscriptions for that event
package, it goes on to the next value of the Subscription header
field. Otherwise, processing continues.
Next, the registrar validates that the resource in the header field
value is a valid resource within the domain of the registrar. If it
is, processing continues. Otherwise, the registrar goes on to the
next value of the Subscription header field. Next, it checks whether
or not the UAC is authorized to subscribe to the resource. The means
by which authorization occurs is outside the scope of this
specification. Typically, registration-coupled subscriptions are
performed with subscriptions where the authorization policy is such
that a user is allowed to subscribe to themselves, and no others.
This authorization policy, called "self", is readily provisioned on
the registrar, and would not require complex interactions with other
event servers. If the registrar cannot determine authorization, or
if the subscription is not authorized, the registrar goes on to the
next value of the Subscription header field. Otherwise, processing
continues.
At this point, the subscription has been authorized. The registrar
stores the event header field parameters in the Subscription header
field value as part of the state associated with the registered
contact. These parameters are carried as a quoted string in the
Subscription header field, so that they are readily separable from
the Subscription header field parameters. It also stores the event
package. The registrar chooses a tag that will serve as the remote
tag of the dialog, according to the procedures of RFC 3261. This tag
is also stored as part of the state associated with the registered
contact. The Call-ID and From tag from the REGISTER request would
have already been stored as part of normal registration processing,
as would the Path header field value. The registrar also stores the
From header field of the REGISTER message.
In the 200 OK to the REGISTER request, the registrar includes the
Subscription header field. Each value contains the event package
name for each registration-coupled subscription that was created,
along with the tag that completes the dialog. The AOR SHOULD NOT be
included.
3.3.2 PUBLISH Processing
This specification allows a registrar to act as an event server for
registration-coupled subscriptions. When the registrar receives a
PUBLISH message for a particular address-of-record, it checks that
Rosenberg Expires January 14, 2006 [Page 10]
Internet-Draft Registration Coupled Subscriptions July 2005
the PUBLISH has arrived from an event server that is authorized to
publish events for the subscriber. Typically, this is done based on
the maintentance of a TLS connection between the registrar and the
event server, used to identify the source of the messages to the
registrar. The registrar would typically authorize PUBLISH messages
for a specific event package only if they came from a specific event
server.
Once the sender of the PUBLISH is authorized, the registrar performs
a registration query for the AOR in the Request-URI of the PUBLISH
message. It checks to see if there are any contacts registered for
that AOR that have registration-coupled subscriptions for that event
package. For each contact it finds, the registrar constructs a
NOTIFY message. The Call-ID of this NOTIFY is taken from the stored
state associated with the registration. The From header field URI is
set to the AOR of the user. The To header field URI is set to the
value in the From header field of the most recent REGISTER message.
The tag in the From header field is populated with the tag associated
with the registration. The tag in the To header field is populated
with the tag stored with the Contact. The Event header field of the
NOTIFY is set to the event header field stored with the Contact. The
body of the NOTIFY is taken from the body of the PUBLISH. The
remainder of the NOTIFY is consructed as per RFC 3261, and then sent
as a mid-dialog request.
The registrar then generates a 200 OK to the PUBLISH request. If the
registrar found no matching registration-coupled subscriptions for
the PUBLISH, it generates a 403 response to the PUBLISH request.
This informs the event server that its event was not delivered.
3.4 Event Server Behavior
It is assumed that event servers learn about events for a particular
package for a particular subscriber through any number of means.
These can include non-SIP mechanisms, SIP subscriptions to a
resource, and so on. However, they cannot include a SIP PUBLISH
message sent to the AOR of the subscriber; those PUBLISH messages are
routed to the registrar according to this specification.
An event server MAY act as the dialog owner, or MAY leave that
responsibility to the registrar. However, it MUST NOT do both for
the same subscriber within the duration of a registration from that
subscriber. To act as a dialog owner, the event server subscribes to
the registration event package. It MAY subscribe to this event
package for each subcscriber individually, or it MAY subscribe to a
resource that represents all subscribers or a group of users at the
registrar (for example, sip:all-users@example.com). The latter is
preferable since it avoids the need for per-user subscription
Rosenberg Expires January 14, 2006 [Page 11]
Internet-Draft Registration Coupled Subscriptions July 2005
maintenance at the event server.
The notifications of the dialog event package will contain
information on each registration-coupled subscripton for a
subscriber. If the event server is acting as a dialog owner, it MUST
store this information. Effectively, the reg-event notification
creates the dialog state and the event subscription at the event
server. When the event server wishes to send an event, it creates a
NOTIFY using the dialog state and sends it, per RFC 3265 and RFC 3261
procedures. These NOTIFY messages won't even traverse the registrar.
If the event server is not acting as a dialog owner, when it wishes
to send a notification, it sends a PUBLISH message. The request-URI
of the PUBLISH is set to the AOR of the subscriber for whom a
notification is to be delivered. The content of the PUBLISH contains
the event state that is to be delivered to the watcher. The Event
header field is populated with the value of the event package for
which the notifications are intended. This PUBLISH message is sent,
and will be routed to the registrar. The processing above will
result in a NOTIFY being sent to each registered contact for that
AOR.
The choice of whether to act as dialog owner or not depends on
several factors. When the event server leaves dialog ownership to
the registrar, it alleviates the need for the event server to
maintain any kind of per-subscriber state. However, it imposes
additional work on the registrar to perform the registration queries
and construction of NOTIFY messages. Thus, this mode is useful for
very infrequent events, such as a request to update a configuration
profile in the configuration event package. Dialog ownership makes
more sense for more frequent events. Also, since the registrar
doesnt know the actual event state, it cannot send an initial NOTIFY
with the current state when the dialog is first created. It relies
on the event server to do that. As a result, if an event package
requires state to be delivered as part of a NOTIFY generated when the
subscription is created, the event server needs to maintain ownership
of the dialog, or the hybrid model below needs to be used.
A hybrid model is also possible. An event server can receive reg-
event notifications, but not store dialog state. When it sees that
the user has registerd or unregistered, it can send a PUBLISH
message. This is useful for infrequent notifications that need to be
triggered on registration. The hybrid model also allows the event
server to generate a PUBLISH when a client first registers, that
contains the current value of the event state. This will cause the
registrar to send a NOTIFY message with the current state. This is
useful for event packages where it is desireable to send event state
as part of the initial NOTIFY.
Rosenberg Expires January 14, 2006 [Page 12]
Internet-Draft Registration Coupled Subscriptions July 2005
The hybrid model is particularly attractive, since it alleviates the
need for the event server to maintain any kind of dialog state or
per-subscriber subscription state, and yet it allows for the full
features of a traditional event subscription.
3.5 Subscription Header Field
The grammar for the Subscription header field is:
Subscription = "Subscription" HCOLON (sub-param *(COMMA
sub-param))
sub-param = event-type *(SEMI sub-param)
sub-event-param = sub-aor / sub-event-param / tag-param / generic-param
sub-aor = "aor" EQUAL (SIP-URI / SIPS-URI)
sub-event-param = "e-param" EQUAL quoted-string
Figure 3 and Figure 4 are an extension of Tables 2 and 3 in RFC 3261
[1] for the Subscription header field. The column "INF" is for the
INFO method [5], "PRA" is for the PRACK method [6], "UPD" is for the
UPDATE method [7], "SUB" is for the SUBSCRIBE method [2], "NOT" is
for the NOTIFY method [2], "MSG" is for the MESSAGE method [8], "PUB"
is for the PUBLISH method [9], and "REF" is for the REFER method
[10].
Header field where proxy ACK BYE CAN INV OPT REG REF
Subscription R - - - - - - o -
Subscription 2xx - - - - - - o -
Figure 3: Subscription header field
Header field where proxy PRA UPD SUB NOT INF MSG PUB
Subscription R - - - - - - - -
Subscription 2xx - - - - - - - -
Figure 4: Subscription header field
3.6 Examples
Rosenberg Expires January 14, 2006 [Page 13]
Internet-Draft Registration Coupled Subscriptions July 2005
3.6.1 Registrar has Dialog Ownership
In this example, the registrar holds ownership of the dialog. The
event server is a message waiting indicator server that publishes MWI
events.
UA Registrar MWI Server
|(1) REGISTER | |
|------------->| |
|(2) 200 OK | |
|<-------------| |
| |(3) PUBLISH |
| |<-------------|
| |(4) 200 OK |
| |------------->|
|(5) NOTIFY | |
|<-------------| |
|(6) 200 OK | |
|------------->| |
Figure 5: Registrar Owned Dialogs
The REGISTER message (1) would look like:
REGISTER sip:example.com SIP/2.0
To: sip:joe@example.com
From: sip:joe@example.com;tag=asd9887g
Subscription: message-summary;aor=sip:joe@example.com
Expires: 3600
Via: SIP/2.0/UDP client.biloxi.example.com;branch=z9hG4bKnashds7
Max-Forwards: 70
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
CSeq: 1 REGISTER
Content-Length: 0
Contact: sip:client.biloxi.example.com
The 200 OK to the REGISTER indicates successful creation of the
dialog:
Rosenberg Expires January 14, 2006 [Page 14]
Internet-Draft Registration Coupled Subscriptions July 2005
SIP/2.0 200 OK
To: sip:joe@example.com;tag=99j9jj
From: sip:joe@example.com;tag=asd9887g
Subscription: message-summary;tag=ghghghg
Expires: 3600
Via: SIP/2.0/UDP client.biloxi.example.com;branch=z9hG4bKnashds7
Max-Forwards: 70
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
CSeq: 1 REGISTER
Content-Length: 0
The PUBLISH from the event server comes when a new message arrives:
PUBLISH sip:joe@example.com SIP/2.0
To: sip:joe@example.com
From: sip:mwi-server@example.com
Event: message-summary
Via: SIP/2.0/UDP mwi.example.com;branch=z9hG4bKnashas--d9
Call-ID: 3k9FpLxhg88asd7m8tn@mwi.example.com
CSeq: 1 PUBLISH
Content-Type: application/simple-message-summary
Content-Length: ---
Messages-Waiting: yes
Message-Account: sip:joe@mwi.example.com
Voice-Message: 2/8 (0/2)
This results in a notification from the registrar:
NOTIFY sip:client.biloxi.example.com SIP/2.0
To: sip:joe@example.com;tag=asd9887g
From: sip:joe@example.com;tag=ghghghg
Event: message-summary
Via: SIP/2.0/UDP reg.example.com;branch=z9hG4bKnashas--d10
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
CSeq: 1 NOTIFY
Content-Type: application/simple-message-summary
Content-Length: ---
Messages-Waiting: yes
Message-Account: sip:joe@mwi.example.com
Voice-Message: 2/8 (0/2)
Rosenberg Expires January 14, 2006 [Page 15]
Internet-Draft Registration Coupled Subscriptions July 2005
3.6.2 Event Server Owned Dialog
UA Registrar MWI Server
| |(1) SUBSCRIBE |
| |<-------------|
| |(2) 200 OK |
| |------------->|
| |(3) NOTIFY |
| |------------->|
| |(4) 200 OK |
| |<-------------|
|(5) REGISTER | |
|------------->| |
|(6) 200 OK | |
|<-------------| |
| |(7) NOTIFY |
| |------------->|
| |(8) 200 OK |
| |<-------------|
|(9) NOTIFY | |
|<----------------------------|
|(10) 200 OK | |
|---------------------------->|
When the message waiting server starts up, it subscribes to the
registration event package at the registrar (message 1). The request
URI identifies all users in the domain. This generates a 200 OK
(message 2), followed by a NOTIFY (message 3). This NOTIFY doesn't
contain any event state (there is too much), but it confirms the
subscription.
At some point later, the UA in question registers. The registration
sequence (messages 5/6) are as above. This causes a reg-event NOTIFY
to be sent to the mwi server (message 7). This tells the server
about the creation of a new contact, and also tells it that a MWI
registration-coupled subscription was created. It provides the
dialog identifiers to the MWI server. Next, the MWI server generates
a NOTIFY to tell the client about the event state (9).
Rosenberg Expires January 14, 2006 [Page 16]
Internet-Draft Registration Coupled Subscriptions July 2005
3.6.3 Hybrid Model
UA Registrar MWI Server
| |(1) SUBSCRIBE |
| |<-------------|
| |(2) 200 OK |
| |------------->|
| |(3) NOTIFY |
| |------------->|
| |(4) 200 OK |
| |<-------------|
|(5) REGISTER | |
|------------->| |
|(6) 200 OK | |
|<-------------| |
| |(7) NOTIFY |
| |------------->|
| |(8) 200 OK |
| |<-------------|
| |(9) PUBLISH |
| |<-------------|
| |(10) 200 OK |
| |------------->|
|(11) NOTIFY | |
|<-------------| |
|(12) 200 OK | |
|------------->| |
When the message waiting server starts up, it subscribes to the
registration event package at the registrar (message 1). The request
URI identifies all users in the domain. This generates a 200 OK
(message 2), followed by a NOTIFY (message 3). This NOTIFY doesn't
contain any event state (there is too much), but it confirms the
subscription.
At some point later, the UA in question registers. The registration
sequence (messages 5/6) are as above. This causes a reg-event NOTIFY
to be sent to the mwi server (message 7). This tells the server
about the creation of a new contact, and also tells it that a MWI
registration-coupled subscription was created. It provides the
dialog identifiers to the MWI server. However, instead of sending
the NOTIFY, the MWI server discards the dialog information. It sends
a PUBLISH request (message 9) identically to the case where the
registrar owns the dialog. This causes the registrar to send the
notification (message 11).
4. References
Rosenberg Expires January 14, 2006 [Page 17]
Internet-Draft Registration Coupled Subscriptions July 2005
4.1 Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[3] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP)
Extension Header Field for Service Route Discovery During
Registration", RFC 3608, October 2003.
[4] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP)
Extension Header Field for Registering Non-Adjacent Contacts",
RFC 3327, December 2002.
[5] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[6] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in Session Initiation Protocol (SIP)", RFC 3262,
June 2002.
[7] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002.
[8] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging", RFC 3428, December 2002.
[9] Niemi, A., "Session Initiation Protocol (SIP) Extension for
Event State Publication", RFC 3903, October 2004.
[10] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
4.2 Informative References
[11] Mahy, R., "A Message Summary and Message Waiting Indication
Event Package for the Session Initiation Protocol (SIP)",
RFC 3842, August 2004.
[12] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004.
[13] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Registrations", RFC 3680, March 2004.
Rosenberg Expires January 14, 2006 [Page 18]
Internet-Draft Registration Coupled Subscriptions July 2005
[14] Roach, A., Rosenberg, J., and B. Campbell, "A Session
Initiation Protocol (SIP) Event Notification Extension for
Resource Lists", draft-ietf-simple-event-list-07 (work in
progress), January 2005.
[15] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004.
[16] Rosenberg, J., "A Watcher Information Event Template-Package
for the Session Initiation Protocol (SIP)", RFC 3857,
August 2004.
[17] Rosenberg, J., "An INVITE Inititiated Dialog Event Package for
the Session Initiation Protocol (SIP)",
draft-ietf-sipping-dialog-package-06 (work in progress),
April 2005.
[18] Petrie, D., "A Framework for Session Initiation Protocol User
Agent Profile Delivery", draft-ietf-sipping-config-framework-06
(work in progress), February 2005.
Author's Address
Jonathan Rosenberg
Cisco Systems
600 Lanidex Plaza
Parsippany, NJ 07054
US
Phone: +1 973 952-5000
Email: jdrosen@cisco.com
URI: http://www.jdrosen.net
Rosenberg Expires January 14, 2006 [Page 19]
Internet-Draft Registration Coupled Subscriptions July 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Rosenberg Expires January 14, 2006 [Page 20]
