Network Working Group B. Jentz Internet-Draft R. Horvath Expires: July 29, 2006 M. Coulas Motorola January 25, 2006 SIP Subscription Mobility using SUBSCRIBE with Replaces Header draft-jentz-subscribe-with-replaces-00.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 July 29, 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 dialog. An important subset of these dialogs consists of the Jentz, et al. Expires July 29, 2006 [Page 1] Internet-Draft SIP SUBSCRIBE with Replaces Header January 2006 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. Example using Existing Standards . . . . . . . . . . . . . 6 4.2. Example using SUBSCRIBE with Replaces Header . . . . . . . 7 5. Mobile Notifier Scenario . . . . . . . . . . . . . . . . . . . 9 5.1. Baseline Example . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . 16 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 July 29, 2006 [Page 2] Internet-Draft SIP SUBSCRIBE with Replaces Header January 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 July 29, 2006 [Page 3] Internet-Draft SIP SUBSCRIBE with Replaces Header January 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 July 29, 2006 [Page 4] Internet-Draft SIP SUBSCRIBE with Replaces Header January 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 July 29, 2006 [Page 5] Internet-Draft SIP SUBSCRIBE with Replaces Header January 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. Example using Existing Standards 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 July 29, 2006 [Page 6] Internet-Draft SIP SUBSCRIBE with Replaces Header January 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 that several 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.) 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 Jentz, et al. Expires July 29, 2006 [Page 7] Internet-Draft SIP SUBSCRIBE with Replaces Header January 2006 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 | | |---------------------------------->|----------------->| | | | | 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: From: ;tag=1234 Call-ID: 0987a@mn.example.net CSeq: 1 SUBSCRIBE Contact: Event: pkg10 The corresponding 200 OK response might look as follows: SIP/2.0 200 OK To: ;tag=5678 From: ;tag=1234 Call-ID: 0987a@mn.example.net CSeq: 1 SUBSCRIBE Contact: 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: Jentz, et al. Expires July 29, 2006 [Page 8] Internet-Draft SIP SUBSCRIBE with Replaces Header January 2006 SUBSCRIBE From: ;tag=2468 Call-ID: 7531b@mn.example.net CSeq: 1 SUBSCRIBE Contact: Event: pkg10 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 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 Jentz, et al. Expires July 29, 2006 [Page 9] Internet-Draft SIP SUBSCRIBE with Replaces Header January 2006 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 July 29, 2006 [Page 10] Internet-Draft SIP SUBSCRIBE with Replaces Header January 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 July 29, 2006 [Page 11] Internet-Draft SIP SUBSCRIBE with Replaces Header January 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. 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. 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 | | |<----------------------------------|<-----------------| | | | | 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: Jentz, et al. Expires July 29, 2006 [Page 12] Internet-Draft SIP SUBSCRIBE with Replaces Header January 2006 SUBSCRIBE sip:notifier2@example.net SIP/2.0 To: From: ;tag=1234 Call-ID: 0987a@host.example.net CSeq: 1 SUBSCRIBE Contact: Event: pkg10 Supported: tdialog, norefersub, replaces The corresponding 200 OK response might look as follows: SIP/2.0 200 OK To: ;tag=5678 From: ;tag=1234 Call-ID: 0987a@host.example.net CSeq: 1 SUBSCRIBE Contact: Later on, a handover takes place whereby the mobile needs to perform notifier handover on the target network using REFER and making use of the SUBSCRIBE with Replaces method. This message might look as follows: REFER sip:subscriber1@example.net SIP/2.0 To: From: ;tag=2468 Call-ID: 7531b@mn.example.net CSeq: 1 REFER Contact: Require: replaces, tdialog Refer-To: Referred-By: 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: Jentz, et al. Expires July 29, 2006 [Page 13] Internet-Draft SIP SUBSCRIBE with Replaces Header January 2006 SUBSCRIBE sip:notifier2@example.net SIP/2.0 To: From: ;tag=1357 Call-ID: 9742c@host.example.net CSeq: 1 SUBSCRIBE Contact Event: pkg10 Supported: tdialog, norefersub, replaces Require: replaces Replaces: 0987a@host.example.net;to-tag=5678;from-tag=1234 Referred-By: 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 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. 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. Jentz, et al. Expires July 29, 2006 [Page 14] Internet-Draft SIP SUBSCRIBE with Replaces Header January 2006 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. 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 Jentz, et al. Expires July 29, 2006 [Page 15] Internet-Draft SIP SUBSCRIBE with Replaces Header January 2006 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 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 Jentz, et al. Expires July 29, 2006 [Page 16] Internet-Draft SIP SUBSCRIBE with Replaces Header January 2006 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 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)", draft-ietf-sip-target-dialog-03 (work in progress), December 2005. [7] Levin, O., "Suppression of Session Initiation Protocol REFER Method Implicit Subscription", draft-ietf-sip-refer-with-norefersub-04 (work in progress), January 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-06 (work in progress), October 2005. Jentz, et al. Expires July 29, 2006 [Page 17] Internet-Draft SIP SUBSCRIBE with Replaces Header January 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 July 29, 2006 [Page 18] Internet-Draft SIP SUBSCRIBE with Replaces Header January 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 July 29, 2006 [Page 19] Internet-Draft SIP SUBSCRIBE with Replaces Header January 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 July 29, 2006 [Page 20]