Internet DRAFT - draft-jentz-subscribe-with-replaces
draft-jentz-subscribe-with-replaces
Network Working Group B. Jentz
Internet-Draft R. Horvath
Expires: December 21, 2006 M. Coulas
Motorola
June 19, 2006
Subscription Mobility for the Session Initiation Protocol (SIP) using
SUBSCRIBE with Replaces
draft-jentz-subscribe-with-replaces-01.txt
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 December 21, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
A device using the Session Initiation Protocol (SIP) may need to
perform a handover between networks that results in a corresponding
change to the mobile's SIP edge proxy. Alternatively, there may be
the need to transfer a SIP dialog from one device to another. In
both of these scenarios, the device needs a procedure to allow it to
take an existing SIP dialog and logically replace it with a new SIP
Jentz, et al. Expires December 21, 2006 [Page 1]
Internet-Draft SIP SUBSCRIBE with Replaces June 2006
dialog. An important subset of these dialogs consists of the
device's subscription dialogs. This document proposes to extend the
SIP SUBSCRIBE method to include the Replaces header field for the
purpose of enabling a more robust solution to SIP subscription
mobility.
Table of Contents
1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Mobile Subscriber Scenario . . . . . . . . . . . . . . . . . . 5
4.1. Baseline Example . . . . . . . . . . . . . . . . . . . . . 6
4.2. Example using SUBSCRIBE with Replaces Header . . . . . . . 7
5. Mobile Notifier Scenario . . . . . . . . . . . . . . . . . . . 9
5.1. Baseline Example . . . . . . . . . . . . . . . . . . . . . 10
5.2. Example using SUBSCRIBE with Replaces Header . . . . . . . 11
6. Notifier User Agent Behavior . . . . . . . . . . . . . . . . . 14
7. Use of GRUUs . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Header Field Definition . . . . . . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20
Jentz, et al. Expires December 21, 2006 [Page 2]
Internet-Draft SIP SUBSCRIBE with Replaces June 2006
1. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
This document refers frequently to the terms "subscription",
"subscriber" and "notifier". These are defined in Section 2 of RFC
3265 [2]. This document also uses the term "subscription dialog" to
refer to a dialog created by an authorized subscription. The term
"source network" refers to the network where the mobile device has
active SIP dialog(s) prior to handover. The term "target network"
refers to the network where the mobile device needs to create new SIP
dialog(s) that will logically replace its existing SIP dialog(s) as a
result of a handover procedure.
This document uses the scenario of a single mobile device performing
a handover procedure from the "source network" to the "target
network" to illustrate the functionality of this extension.
Alternatively, the scenario requiring the transfer of a "subscription
dialog" from one device to another would require the device on the
"source network" and "target network" to be different devices. The
behavior of the extension is the same in either scenario.
2. Introduction
In the context of seamless mobility solutions for mobile devices
managing SIP [3] sessions and dialogs, there are scenarios in which a
mobile device needs to perform a handover between networks that
results in a corresponding change to the mobile's SIP edge proxy.
Alternatively, there are scenarios requiring the transfer of a SIP
dialog from one device to another. In both the handover and device
transfer scenarios, the device needs a procedure to allow it to take
an existing SIP dialog and logically replace it with a new SIP
dialog.
The SIP "Replaces" Header specification [4] specifies that the
Replaces header is used to logically replace an existing SIP dialog
with a new SIP dialog. More specifically, the Replaces header
contains call-id, to-tag and from-tag information that is used to
match an existing SIP dialog. The Replaces header field indicates
that a single dialog identified by the header field is to be
terminated and logically replaced by the new SIP dialog in which it
is contained. It is a request header only, and defined only for
INVITE requests.
The device's INVITE dialogs and corresponding sessions are one set of
Jentz, et al. Expires December 21, 2006 [Page 3]
Internet-Draft SIP SUBSCRIBE with Replaces June 2006
SIP dialogs for which mobility needs to be enabled in the above
mentioned scenarios. The SIP Replaces header field as specified in
[4] provides a means to terminate and logically replace an existing
INVITE dialog with a new INVITE dialog, thereby enabling the desired
mobility of INVITE sessions and dialogs.
The device's subscription dialogs are another set of SIP dialogs for
which mobility needs to be enabled in the above mentioned scenarios.
Both the handover and device transfer scenarios include two separate
use cases where a User Agent (UA) on the device serves as either the
subscriber or the notifier for the subscription dialog. The SIP -
Specific Event Notification specification [2] can be used to provide
solutions to the subscription mobility problem, but not without the
risk of poor performance in the case of the handover scenario.
This document proposes to extend the SIP SUBSCRIBE method to include
the Replaces header field for the purpose of enabling a more robust
mobility procedure for subscription dialogs. The motivation for
proposing this extension is described in Section 3. Examples are
then presented in Section 4 and Section 5 that help to illustrate the
potential performance improvements that can be enabled with this
proposed extension using the specific case of the handover scenario.
3. Motivation
The primary motivation for extending the SIP SUBSCRIBE method to
include the Replaces header is to provide for improved handover
performance for SIP subscription dialogs that are associated with a
mobile device performing a handover that results in a corresponding
change to the mobile's SIP edge proxy. Although SIP subscription
dialogs can nominally tolerate greater handover latency than real-
time multimedia sessions, there are some significant handover
performance issues that need to be taken into consideration as
highlighted below.
Once the handover algorithm has generated a trigger indicating the
need for a handover, the mobile device will first need to obtain the
address of the new edge proxy server using methods such as those
described in [10] and [11]. Then the mobile device will typically
need to execute registration and authentication procedures with the
target network.
Using the methods available in [2] to enable subscription mobility,
the mobile device will need to perform additional SIP signaling over
the source network before the handover process can be completed.
This additional signaling on the source network becomes a significant
source of handover latency if the mobile device has multiple
Jentz, et al. Expires December 21, 2006 [Page 4]
Internet-Draft SIP SUBSCRIBE with Replaces June 2006
subscription dialogs associated with it.
Any need for additional SIP signaling over the source network
following the handover trigger results in the risk of losing
connectivity to the source network before the SIP signaling exchange
can be completed. With a handover triggering algorithm that includes
a predictor mechanism, it is possible to provide more margin for
executing the SIP signaling exchange. Even so, the rapid and
unpredictable variation of signal levels due to multipath fading and
shadowing conditions make it difficult to predict the signal quality
over a future time interval. A more robust solution would be one
that eliminates the need for additional SIP signaling on the source
network entirely. The SIP SUBSCRIBE with Replaces Header method
would enable this more robust solution.
Another important performance measurement is the ability to enable
SIP subscription mobility even if there is a break in connectivity
during handover. In the use case where the UA on the mobile device
serves as the subscriber, the notifier may be left with an invalid
subscription that can't be explicitly terminated by the subscriber.
Similarly, in the use case where the UA on the mobile device serves
as the notifier, the subscriber may be left with an invalid
subscription that can't be explicitly terminated by the notifier.
More importantly, the subscriber may be left without a valid
subscription for an extended period of time, something which may not
be acceptable. A more robust solution would be one that allows the
UA on the mobile device to explicitly terminate and replace an
invalid subscription dialog using SIP signaling over the target
network. The SIP SUBSCRIBE with Replaces Header method would enable
this more robust solution.
4. Mobile Subscriber Scenario
One mobility scenario of interest involves a mobile SIP subscriber
that is moving between networks with a corresponding change to the
SIP edge proxy. Due to the change in the SIP proxy, the original SIP
subscription dialog over the source network needs to be re-
established using a new dialog over the target network. The change
in SIP proxies may also result in the mobile device sending a SIP
REGISTER request through the outbound proxy in the target network to
update its bindings. This scenario is illustrated in Figure 1.
Jentz, et al. Expires December 21, 2006 [Page 5]
Internet-Draft SIP SUBSCRIBE with Replaces June 2006
+---------+
Original Dialog | Source |
+------------->| Network |<-----------+
| | Proxy | |
| | +---------+ |
| V V
| +------------+ +----------+
| | Mobile | | Notifier |
| | Subscriber | | |
| +------------+ +----------+
| ^ ^
V | +---------+ |
movement | | Target | |
+------------->| Network |<-----------+
New Dialog | Proxy |
+---------+
Figure 1: Mobile Subscriber Mobility Scenario
4.1. Baseline Example
RFC 3265 [2] enables a baseline solution to the mobile subscriber
scenario. The solution is to have the mobile unsubscribe an existing
subscription over the source network, then have the mobile re-
subscribe the same subscription over the target network. An
unsubscription is accomplished by having the subscriber send a
SUBSCRIBE request with the "Expires" header set to "0". The
subscription is not considered terminated until the notifier sends a
NOTIFY message with a "Subscription-State" of "terminated". An
example signaling sequence is illustrated in Figure 2.
The above message sequence will need to be repeated for every
subscription that the mobile has currently active at the time it
chooses to switch networks. This additional signaling over a network
that the mobile is trying to move away from, creates added handover
latency and increases the need for predictive handover algorithms so
that the signaling can be completed before the mobile loses coverage
on the source network.
In the event that connectivity to the source network is lost while
attempting to perform the unsubscribe message sequence, the notifier
is left with an invalid subscription that can't be explicitly
terminated by the subscriber. The subscription will remain in this
state until either the subscription expires, or the notifier tries to
send a NOTIFY message on the original dialog and it fails due to a
response timeout, resulting in the removal of the subscription. This
potential for invalid subscriptions is an undesirable condition.
Jentz, et al. Expires December 21, 2006 [Page 6]
Internet-Draft SIP SUBSCRIBE with Replaces June 2006
Source Target
Mobile Network Network
Subscriber Proxy Proxy Notifier
| Handover | | |
|<~~~~~Trigger | | |
| | SUBSCRIBE (Expires=0) |
|----------------->|---------------------------------->|
| | 200 OK | |
|<-----------------|<----------------------------------|
| | NOTIFY (terminated) |
|<-----------------|<----------------------------------|
| | 200 OK | |
|----------------->|---------------------------------->|
| | | |
|---------------------------------->|---->REGISTER/200 |
| | SUBSCRIBE | |
|---------------------------------->|----------------->|
| | 200 OK | |
|<----------------------------------|<-----------------|
| | NOTIFY | |
|<----------------------------------|<-----------------|
| | 200 OK | |
|---------------------------------->|----------------->|
| | | |
Figure 2: Mobile Subscriber Mobility using existing standards
4.2. Example using SUBSCRIBE with Replaces Header
A more efficient approach to the mobile subscriber scenario would be
to define a Replaces header for use with the SUBSCRIBE method. From
[4], the Replaces header contains call-id, to-tag and from-tag
information that is used to match an existing SIP dialog. By
extending the SUBSCRIBE method to include the option of a Replaces
header, the mobile can send a "SUBSCRIBE with Replaces" request to
create a new dialog on the target network that will effectively
terminate and replace a SUBSCRIBE dialog existing on the source
network.
In the case where multiple subscriptions are associated with the same
dialog, the dialog on the source network does not terminate until
after all the subscriptions in it have been replaced. A SUBSCRIBE
request MAY include an "id" parameter in its Event header to support
differentiation between multiple subscriptions in the same dialog
[2]. If the original SUBSCRIBE request for the subscription that is
being replaced contained an "id" parameter in the Event header, then
the "SUBSCRIBE with Replaces" request MUST also contain an identical
"id" parameter.
Jentz, et al. Expires December 21, 2006 [Page 7]
Internet-Draft SIP SUBSCRIBE with Replaces June 2006
This procedure creates the desired new SUBSCRIBE dialog(s) on the
target network without having to perform additional messaging on the
source network. Since the Replaces header enables the mobile
subscriber to use the target network to explicitly terminate existing
SUBSCRIBE dialogs on the source network, it greatly reduces the
potential for invalid subscriptions that is present using existing
standards. This improvement to the SIP subscription mobility problem
is illustrated in Figure 3.
Source Target
Mobile Network Network
Subscriber Proxy Proxy Notifier
| Handover | | |
|<~~~~~Trigger | | |
| | | |
|---------------------------------->|---->REGISTER/200 |
| | SUBSCRIBE w/Replaces |
|---------------------------------->|----------------->|
| | 200 OK | |
|<----------------------------------|<-----------------|
| | NOTIFY | |
|<----------------------------------|<-----------------|
| | 200 OK | |
|---------------------------------->|----------------->|
| | NOTIFY (terminated) |
| X<--------|<----------------------------------|
Figure 3: Mobile Subscriber Mobility using SUBSCRIBE with Replaces
For illustrative purposes, assume that an initial SUBSCRIBE request
was sent by a mobile subscriber on the source network with the
following message parameters:
SUBSCRIBE sip:notifier1@example.net SIP/2.0
To: <sip:notifier1@example.net>
From: <sip:subscriber2@example.net>;tag=1234
Call-ID: 0987a@mn.example.net
CSeq: 1 SUBSCRIBE
Contact: <sip:subscriber2@address1.example.net>
Event: pkg10;id=42
The corresponding 200 OK response might look as follows:
SIP/2.0 200 OK
To: <sip:notifier1@example.net>;tag=5678
From: <sip:subscriber2@example.net>;tag=1234
Call-ID: 0987a@mn.example.net
CSeq: 1 SUBSCRIBE
Jentz, et al. Expires December 21, 2006 [Page 8]
Internet-Draft SIP SUBSCRIBE with Replaces June 2006
Contact: <sip:notifier1@address2.example.net>
Later on, a handover takes place whereby the mobile needs to create a
re-subscription dialog on the target network using the SUBSCRIBE with
Replaces method. This message might look as follows:
SUBSCRIBE <sip:notifier1@example.net SIP/2.0
To: <sip:notifier1@example.net>
From: <sip:subscriber2@example.net>;tag=2468
Call-ID: 7531b@mn.example.net
CSeq: 1 SUBSCRIBE
Contact: <sip:subscriber2@address3.example.net>
Event: pkg10;id=42
Require: replaces
Replaces: 0987a@mn.example.net;to-tag=5678;from-tag=1234
5. Mobile Notifier Scenario
A second mobility scenario of interest involves a mobile SIP notifier
that is moving between networks with a corresponding change to the
SIP edge proxy. Due to the change in the SIP proxy, the original SIP
subscription dialog over the source network needs to be re-
established using a new dialog over the target network. The change
in SIP proxies will also result in the mobile device sending a SIP
REGISTER request through the outbound proxy in the target network to
update its bindings. This scenario is illustrated in Figure 4.
+---------+
Original Dialog | Source |
+------------->| Network |<-----------+
| | Proxy | |
| | +---------+ |
| V V
| +-----------+ +------------+
| | Mobile | | Subscriber |
| | Notifier | | |
| +-----------+ +------------+
| ^ ^
V | +---------+ |
movement | | Target | |
+------------->| Network |<-----------+
New Dialog | Proxy |
+---------+
Figure 4: Mobile Notifier Mobility Scenario
Jentz, et al. Expires December 21, 2006 [Page 9]
Internet-Draft SIP SUBSCRIBE with Replaces June 2006
5.1. Baseline Example
RFC 3265 [2] enables a baseline solution to the mobile notifier
scenario. The solution is to have the mobile send a NOTIFY message
with a "Subscription-State" header of "terminated", a reason
parameter of "probation" and a "retry-after" parameter with a
sufficient time period to account for the signaling latency required
to terminate all the dialogs in the source network and re-register
the mobile in the target network. Upon receipt of this NOTIFY
message, the subscriber will attempt to re-subscribe after the time
period specified by the "retry-after" parameter. This subscription
is established on a new dialog and does not re-use the route set from
the previous subscription dialog. If the mobile notifier has
successfully re-registered itself to the target network, a new
subscription dialog will be established in the target network,
completing notifier handover. An example signaling sequence is
illustrated in Figure 5.
NOTIFY messages will need to be sent for every active subscription
that the mobile acts as a notifier for at the time it chooses to
switch networks. This additional signaling over a network that the
mobile is trying to move away from, creates added handover latency
and increases the need for predictive handover algorithms so that the
signaling can be completed before the mobile loses coverage on the
source network.
In the event that connectivity to the source network is lost while
attempting to perform the NOTIFY with probation messaging, the
subscriber is left with an invalid subscription that can't be
explicitly terminated by the notifier. The subscriber may attempt to
refresh the subscription, but it will not be successful due to the
fact that the original dialog on the source network is now invalid.
The subscription will therefore remain invalid until it expires, at
which point the subscriber may or may not attempt to re-subscribe.
In addition, once connectivity to the source network is lost, the
mobile notifier can't send event notification messages to the
subscriber until after the subscriber re-subscribes and establishes a
new dialog on the target network. This potential for invalid
subscriptions is an undesirable condition.
More importantly, either the delay associated with the "retry-after"
parameter in a successful notifier handover, or the delay associated
with waiting for an invalid subscription to expire before a re-
subscription is attempted in an unsuccessful notifier handover, may
result in both the subscriber and the notifier being left without a
valid subscription for an extended period of time. This extended
delay may not be acceptable.
Jentz, et al. Expires December 21, 2006 [Page 10]
Internet-Draft SIP SUBSCRIBE with Replaces June 2006
Source Target
Mobile Network Network
Notifier Proxy Proxy Subscriber
| Handover | | |
|<~~~~~Trigger | | |
| | | |
| NOTIFY (terminated, retry-after=delta-seconds) |
|----------------->|---------------------------------->|
| | 200 OK | |
|<-----------------|<----------------------------------| ----
| | | | ^
| | | | |
|---------------------------------->|---->REGISTER/200 | delta
| | | | seconds
| | | | |
| | SUBSCRIBE | | V
|<----------------------------------|<-----------------| ----
| | 200 OK | |
|---------------------------------->|----------------->|
| | NOTIFY | |
|---------------------------------->|----------------->|
| | 200 OK | |
|<----------------------------------|<-----------------|
| | | |
Figure 5: Mobile Notifier Mobility using existing standards
5.2. Example using SUBSCRIBE with Replaces Header
By defining a Replaces header for use with the SUBSCRIBE method, a
more robust solution to the mobile notifier scenario can be enabled.
Once the mobile is registered in the target network, the notifier can
send a REFER request [5] to the subscriber requesting that it re-
subscribe to the same event package while replacing the existing
subscription (i.e. replacing the original dialog). The Contact
header will supply the updated contact parameter for the mobile
notifier in the target network. The Refer-To header will utilize the
SUBSCRIBE with Replaces method to reference the original dialog
associated with the source network that needs to be terminated and
replaced by a new dialog in the target network. The Referred-By [8]
header is used to provide the mobile notifier's identity. It is sent
back to the mobile notifier as part of the SUBSCRIBE with Replaces
request for use in authorization.
A Target-Dialog header [6] with Call-ID, local-tag and remote-tag
parameters that match the original dialog is also included in the
REFER request to allow the subscriber to identify the targeted dialog
and authorize the request. In order for the notifier to use the
Jentz, et al. Expires December 21, 2006 [Page 11]
Internet-Draft SIP SUBSCRIBE with Replaces June 2006
Target-Dialog header, the original SUBSCRIBE request SHOULD include
support for the "tdialog" option tag.
Since the SUBSCRIBE target identified by the Refer-To header is also
the REFER-Issuer, it is already aware of the progress of the
requested REFER request. If the original subscription supports the
"norefersub" option tag defined in [7], it is RECOMMENDED that the
REFER request include the Refer-Sub header field set to "false" to
request that the REFER-Recipient (i.e. the subscriber) accept the
REFER request without establishing an implicit subscription and the
resulting NOTIFY message. This helps to reduce both latency and
unnecessary networking overhead.
In the case where multiple subscriptions are associated with the same
dialog, the dialog on the source network does not terminate until
after all the subscriptions in it have been replaced. A SUBSCRIBE
request MAY include an "id" parameter in its Event header to support
differentiation between multiple subscriptions in the same dialog
[2]. If the original SUBSCRIBE request for the subscription that is
being replaced contained an "id" parameter in the Event header, then
the "SUBSCRIBE with Replaces" request, specified in the Refer-To
header, MUST also contain an identical "id" parameter.
This procedure creates the desired new subscription dialog(s) on the
target network without having to perform additional messaging on the
source network. Since the Replaces header enables the mobile
notifier to use the target network to explicitly terminate existing
subscription dialogs on the source network, it greatly reduces the
potential for invalid subscriptions that is present using existing
standards. This improvement to the SIP subscription mobility problem
is illustrated in Figure 6.
Jentz, et al. Expires December 21, 2006 [Page 12]
Internet-Draft SIP SUBSCRIBE with Replaces June 2006
Source Target
Mobile Network Network
Notifier Proxy Proxy Subscriber
| Handover | | |
|<~~~~~Trigger | | |
| | | |
|---------------------------------->|---->REGISTER/200 |
| REFER (method=SUBSCRIBE w/Replaces) |
|---------------------------------->|----------------->|
| | 202 Accepted | |
|<----------------------------------|<-----------------|
| | SUBSCRIBE w/Replaces |
|<----------------------------------|<-----------------|
| | 200 OK | |
|---------------------------------->|----------------->|
| | NOTIFY | |
|---------------------------------->|----------------->|
| | 200 OK | |
|<----------------------------------|<-----------------|
| NOTIFY (terminated) | |
|----------------->|------>X | |
Figure 6: Mobile Notifier Mobility using SUBSCRIBE with Replaces
For illustrative purposes, assume that an initial SUBSCRIBE request
was created by a subscriber and sent on the source network with the
following message parameters:
SUBSCRIBE sip:notifier2@example.net SIP/2.0
To: <sip:notifier2@example.net>
From: <sip:subscriber1@example.net>;tag=1234
Call-ID: 0987a@host.example.net
CSeq: 1 SUBSCRIBE
Contact: <sip:subscriber1@address1.example.net>
Event: pkg10;id=42
Supported: tdialog, norefersub, replaces
The corresponding 200 OK response might look as follows:
SIP/2.0 200 OK
To: <sip:notifier2@example.net>;tag=5678
From: <sip:subscriber1@example.net>;tag=1234
Call-ID: 0987a@host.example.net
CSeq: 1 SUBSCRIBE
Contact: <sip:notifier2@address2.example.net>
Later on, a handover takes place whereby the mobile needs to perform
notifier handover on the target network using REFER and making use of
Jentz, et al. Expires December 21, 2006 [Page 13]
Internet-Draft SIP SUBSCRIBE with Replaces June 2006
the SUBSCRIBE with Replaces method. This message might look as
follows:
REFER sip:subscriber1@example.net SIP/2.0
To: <sip:subscriber1@example.net>
From: <sip:notifier2@example.net>;tag=2468
Call-ID: 7531b@mn.example.net
CSeq: 1 REFER
Contact: <sip:notifier2@address3.example.net>
Require: replaces, tdialog
Refer-To: <sip:notifier2@example.net;method=SUBSCRIBE?Replaces=
0987a%40host.example.net%3Bto-tag%3D5678%3Bfrom-tag%3D1234&
Event=pkg10%3Bid%3D42>
Referred-By: <sip:notifier2@example.net>
Target-Dialog: 0987a@host.example.net;remote-tag=1234;local-tag=5678
Refer-Sub: false
Since the Refer-To URI is a SIP URI indicating SUBSCRIBE with
Replaces, the subscriber user agent will request a new subscription
on the target network using the SUBSCRIBE with Replaces method. This
message might look as follows:
SUBSCRIBE sip:notifier2@example.net SIP/2.0
To: <sip:notifier2@example.net>
From: <sip:subscriber1@example.net>;tag=1357
Call-ID: 9742c@host.example.net
CSeq: 1 SUBSCRIBE
Contact <sip:subscriber1@address1.example.net>
Event: pkg10;id=42
Supported: tdialog, norefersub, replaces
Require: replaces
Replaces: 0987a@host.example.net;to-tag=5678;from-tag=1234
Referred-By: <sip:notifier2@example.net>
6. Notifier User Agent Behavior
Upon receiving a SUBSCRIBE with Replaces header, the user agent for
the notifier attempts to match the call-id, to-tag and from-tag
parameters with an active dialog. If the Replaces header field
matches an active dialog, the notifier MUST verify that the initiator
of the new SUBSCRIBE dialog is authorized to replace the matched
dialog. If the initiator of the new SUBSCRIBE dialog has been
successfully authenticated as being equivalent to the user who
initiated the original SUBSCRIBE dialog, then the replacement is
authorized. SIP authentication mechanisms are discussed in [3].
If the authorization is successful, the notifier user agent attempts
Jentz, et al. Expires December 21, 2006 [Page 14]
Internet-Draft SIP SUBSCRIBE with Replaces June 2006
to accept the new SUBSCRIBE dialog, reassign the event package and
other resources of the matched dialog to the new SUBSCRIBE dialog,
and remove the original subscription. It creates the new
subscription and new dialog, and returns a "200 OK" response. Upon
successfully accepting the subscription, the notifier MUST send a
NOTIFY message immediately to communicate the resource state to the
subscriber. To remain backward compatible with RFC 3265 [2], the
Notifier MUST also send a final NOTIFY message for the original
SUBSCRIBE dialog that is being replaced. This NOTIFY message is sent
with a "Subscription-State" of "terminated".
If the Replaces header field does not match an active dialog, the
notifier rejects the SUBSCRIBE request and returns a 481 response.
The subscriber can still re-subscribe by creating an unrelated
initial SUBSCRIBE request with a freshly generated Call-ID and a new,
unique "From" tag. If the Replaces header field matches a dialog
which was not created with a SUBSCRIBE, the notifier MUST reject the
request with a 481 response.
Some additional User Agent Server (UAS) behavior is documented in
Section 3 of RFC 3891 [4]. This additional UAS behavior applies to
the Notifier user agent as well, with the term SUBSCRIBE substituted
for the term INVITE.
7. Use of GRUUs
In order for the subscriber and notifier migration procedures
described in this specification to work properly, it is important
that the required SIP requests be routed to the correct endpoint
destination. For example, in the subscriber migration scenario, the
SUBSCRIBE with Replaces request needs to be routed to the specific UA
instance that is performing the notifier function for the original
subscription. Similarly, in the notifier migration scenario, the
REFER request needs to be routed to the specific UA instance that
initiated the subscription.
As explained in [9], "When a request is sent to a URI with the AOR
property, routing logic is applied in proxies to deliver the request
to one or more UAs. That logic can result in a different routing
decision based on the time of day, or the identity of the caller.
However, when a request is made to a URI with the Globally Routable
User Agent URI (GRUU) property, the routing logic is dictated by the
GRUU property. The request has to be delivered to a very specific UA
instance. That UA instance has to be the same UA instance for all
requests sent to that URI". Consequently, the subscription migration
procedures described in this specification cannot be guaranteed to
work properly if the required SIP requests are addressed to AORs.
Jentz, et al. Expires December 21, 2006 [Page 15]
Internet-Draft SIP SUBSCRIBE with Replaces June 2006
The subscription migration procedures described in this
specification, however, will work properly if the SIP requests are
addressed to GRUUs identifying the specific UA instances implementing
the subscriber and notifier functions of the subscription.
Consequently, it is strongly RECOMMENDED that GRUUs be used as the
remote targets of subscription dialogs and that these GRUUs be used
as the destination address of SIP requests used to migrate
subscriptions. Specifically, GRUUs SHOULD be used in specific SIP
requests as follows:
o Contact header of all SUBSCRIBE requests
o Contact header of 200 responses to SUBSCRIBE requests
o Contact header of all NOTIFY requests
o Request-URI of SUBSCRIBE with Replaces requests used in subscriber
migration procedure
o Request-URI of REFER requests used in notifier migration procedure
o Refer-To header of REFER requests used in notifier migration
procedure
o Request-URI of SUBSCRIBE with Replaces requests used in notifier
migration procedure
8. Header Field Definition
This document extends the Replaces Header definition from [4] to
include the SUBSCRIBE method. This document adds the following
modified entry to Table 2 in [3]. Additions to this table are also
provided for extension methods defined at the time of publication of
this document. This is provided as a courtesy to the reader and is
not normative in any way.
Header field where proxy ACK BYE CAN INV OPT REG MSG
------------ ----- ----- --- --- --- --- --- --- ---
Replaces R - - - o - - -
SUB NOT REF INF UPD PRA PUB
--- --- --- --- --- --- ---
o - - - - - -
The syntax of the Replaces header field is defined in [4] and is not
Jentz, et al. Expires December 21, 2006 [Page 16]
Internet-Draft SIP SUBSCRIBE with Replaces June 2006
modified by this document. It is included below as a courtesy to the
reader.
Replaces = "Replaces" HCOLON callid *(SEMI replaces-param)
replaces-param = to-tag / from-tag / early-flag / generic-param
to-tag = "to-tag" EQUAL token
from-tag = "from-tag" EQUAL token
early-flag = "early-only"
A Replaces header field MUST contain exactly one to-tag and exactly
one from-tag, as they are required for unique dialog matching. A
Replaces header field MAY contain the early flag [4].
9. Security Considerations
The security considerations in RFC 3265 [2], RFC 3261 [3] and RFC
3891 [4] apply. The extension specified in this document can be used
to replace a subscription dialog associated with a specific edge
proxy with a new subscription dialog associated with a different edge
proxy. As such, subscriptions with the Replaces header MUST only be
accepted if the subscriber requesting replacement has been properly
authenticated using standard SIP authentication methods, and
authorized to request a replacement of the subscription dialog.
10. IANA Considerations
This document creates no new registration considerations for IANA.
It makes use of existing SIP methods, header fields, and option tags.
11. References
11.1. Normative References
[1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[3] 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.
[4] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
Jentz, et al. Expires December 21, 2006 [Page 17]
Internet-Draft SIP SUBSCRIBE with Replaces June 2006
Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[5] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[6] Rosenberg, J., "Request Authorization through Dialog
Identification in the Session Initiation Protocol (SIP)",
RFC 4538, June 2006.
[7] Levin, O., "Suppression of Session Initiation Protocol (SIP)
REFER Method Implicit Subscription", RFC 4488, May 2006.
[8] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By
Mechanism", RFC 3892, September 2004.
[9] Rosenberg, J., "Obtaining and Using Globally Routable User Agent
(UA) URIs (GRUU) in the Session Initiation Protocol (SIP)",
draft-ietf-sip-gruu-09 (work in progress), June 2006.
11.2. Informative References
[10] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCP-
for-IPv4) Option for Session Initiation Protocol (SIP)
Servers", RFC 3361, August 2002.
[11] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration
Protocol (DHCPv6) Options for Session Initiation Protocol (SIP)
Servers", RFC 3319, July 2003.
Jentz, et al. Expires December 21, 2006 [Page 18]
Internet-Draft SIP SUBSCRIBE with Replaces June 2006
Authors' Addresses
Bradley F. Jentz
Motorola
1301 E. Algonquin Road
Room 2246
Schaumburg, IL 60196
US
Phone: +1 847-576-5946
Email: cbj002@motorola.com
URI: http://www.motorola.com/
Robert Horvath
Motorola
1501 W. Shure Drive
Arlington Heights, IL 60004
US
Phone: +1 847-632-4760
Email: bob.horvath@motorola.com
URI: http://www.motorola.com/
Michael F. Coulas
Motorola
600 N. US Highway 45
Room E1/50N
Libertyville, IL 60048
US
Phone: +1 847-523-1827
Email: mcoulas1@motorola.com
URI: http://www.motorola.com/
Jentz, et al. Expires December 21, 2006 [Page 19]
Internet-Draft SIP SUBSCRIBE with Replaces June 2006
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 (2006). 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.
Jentz, et al. Expires December 21, 2006 [Page 20]
