SIPPING Working Group M. Coulas Internet Draft A.Salkintzis Expires: October 2008 Motorola April 2, 2008 Private Header Extension to SIP for Support of Mobility Operations draft-mcoulas-mobility-p-header-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 October 2, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract Voice call continuity and media over IP session mobility operations are typically characterized by the movement of a specific segment of a communication session across networks and/or devices. This movement may be implemented through the use of SIP procedures that result in the establishment of a new segment replacing the existing segment. Coulas, et al. Expires October 2, 2008 [Page 1] Internet-Draft SIP P-Header for Mobility Operations April 2008 This document proposes a private extension to the Session Initiation Protocol (SIP) that enable User Agents (UA) to indicate that a SIP request is associated with a mobility operation for an existing session. Table of Contents 1. Introduction...................................................2 2. Terminology....................................................5 3. Usage in INVITE requests.......................................6 3.1. Sending an INVITE Request with a P-Mobility header........7 3.2. Mobility Application Server Behavior.....................10 3.3. Proxy Server Behavior....................................12 3.4. Remote Party UAS Behavior................................12 4. Usage in BYE requests.........................................12 4.1. Endpoint UA Behavior.....................................13 4.2. Mobility Application Server Behavior.....................14 5. "mobility-op" SIP Option Tag Usage............................14 6. Example Call Flows............................................15 6.1. CS call to VoIP session VCC domain transfer..............16 6.2. IMS multimedia session to CSI session transfer...........17 7. Future Considerations.........................................19 8. Security Considerations.......................................20 9. IANA Considerations...........................................20 10. Acknowledgments..............................................20 11. References...................................................21 11.1. Normative References....................................21 11.2. Informative References..................................21 Author's Addresses...............................................22 Intellectual Property Statement..................................22 Disclaimer of Validity...........................................23 1. Introduction Session mobility typically involves the movement of an existing media session across different networks and/or the transfer of the media session between different devices. Examples of session mobility scenarios would be: o Domain transfer of a circuit-switched (CS) voice call to an IMS VoIP session, as specified in the 3GPP specifications for Voice Call Continuity (VCC)[4]. E.g., Transfer of a GSM cellular call to a VoIP over WiFi session. Coulas, et al. Expires October 2, 2008 [Page 2] Internet-Draft SIP P-Header for Mobility Operations April 2008 o Transfer of a SIP-based VoIP or multimedia session from one Radio Access Network (RAN) to another. E.g., Transfer of VoIP session from WiFi to WiMAX. o Transfer of a Combination of CS and IMS services (CSI) session to an IMS multimedia session, as specified in the 3GPP specifications for CSI [5]. E.g., Transfer of a CS call with Video Share to an audio+video multimedia over IP session. o Transfer of a SIP-based VoIP or multimedia over IP session from one device to another. Similarly, domain transfer of a circuit- switched (CS) voice call on one device to a VoIP session on another device. o Any practical combination of the above. In all of these scenarios, the mobility operation consists of moving one or more segments of the communication session across different access and/or transport networks. Additionally, the segment(s) may also be moved from one device to another. The movement of a communication segment may be implemented through the use of SIP procedures that result in the establishment of a new segment replacing the existing segment. Two examples of SIP-based approaches that are used in current practice would be: o The SIP device invoking the mobility operation directly addresses the SIP INVITE request that is used to establish the new segment to a mobility application server (AS) which acts as a SIP B2BUA anchor point for managing the mobility operation. Once the new segment is established, the old segment is then either released by the SIP device or the application server. This is the current 3GPP standard approach for implementing VCC domain transfers [4] and is also being contemplated by 3GPP for implementing media over IP session mobility across different access and transport networks. o The SIP device invoking the mobility operation uses an INVITE w/Replaces request to replace a current SIP dialog with a new one [6]. In the case of transferring a session between devices, INVITE w/Replaces may be used in conjunction with SIP REFER requests as described in [3]. The first approach requires that addresses of specific mobility application servers be available to the devices. This approach can become awkward and complicated if different application servers are used to manage different types of mobility (e.g., VCC AS for VCC domain transfers; Session Mobility Function (SMF) AS for session mobility transfers). Coulas, et al. Expires October 2, 2008 [Page 3] Internet-Draft SIP P-Header for Mobility Operations April 2008 The second approach requires that the device has specific knowledge about the dialog that needs replacing. This may not be all that straightforward when there are multiple B2BUAs and hence multiple dialogs in the signaling path of a communication segment that is to be replaced. The dialogs known to the device and the mobility application server may be different. Furthermore, the rules for propagating INVITE w/Replaces across multiple B2BUAs are not well defined. This document proposes a third approach in which a new private extension header (P-header), called P-Mobility, with specific cause is included in SIP requests as a means of indicating that the request is associated with a mobility operation for an existing session. Inclusion of a SIP P-Mobility header in a SIP request indicates that the request is part of a session mobility operation and is to be processed by a UAS capable of (responsible for) implementing that operation. The cause parameter code value further qualifies the type of mobility operation being requested (e.g., VCC, PS-PS mobility, inter-device mobility). This document describes two basic use cases in which the new P- Mobility header may be used: Usage in INVITE requests - A UA in a device initiates a mobility operation for an existing call/session by sending an INVITE request with a P-Mobility header containing one or more cause values describing the type of mobility operation being initiated. The purpose of this INVITE request is to establish a new source communication segment that will replace an existing source communication segment in the session. The INVITE request with P-Mobility header is processed by a UAS capable of processing such requests. This UAS could be the remote endpoint UAS of the session but will more typically be a mobility application server in the home network serving the user that is initiating the mobility operation. Usage in BYE requests - Either the UA in the device which initiated the mobility operation and/or the UAS managing the mobility operation may release the transfer-from source communication segment by sending a BYE request with a P-Mobility header containing one or more cause values describing the type of mobility operation being completed. Note that it shall be possible for either the endpoint UA or the UAS managing the mobility operation to only support the usage in BYE requests and not the usage in INVITE requests. This, for example, would allow a device to use legacy 3GPP mechanisms for VCC domain Coulas, et al. Expires October 2, 2008 [Page 4] Internet-Draft SIP P-Header for Mobility Operations April 2008 transfer while at the same enabling it to use the BYE request with a P-Mobility header to unambiguously release the old transfer-from source communication segment. However, an endpoint UA that supports and uses the usage in INVITE requests MUST also support and use the usage in BYE requests. This document covers the semantics for these two use cases, describing the roles of the SIP entities involved in processing SIP requests with P-Mobility headers. To support these use cases, this document defines a new private extension header (P-header), called P- Mobility, with three cause values describing the type of mobility operation being performed. This document also defines a new "mobility-op" SIP option tag to be used in Supported and Require headers. 2. Terminology 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. The following terms, when used in this document, have specific meanings: Communication segment: A "communication segment" or "segment" for short is a communication signaling path of a call/session consisting of a contiguous sequence of one or more SIP dialogs or circuit-switched connections that is terminated at each end by either an endpoint UA or a B2BUA. For example, the topology illustrated in Figure 1 contains a maximum of 4+3+2+1=10 different communication segments. +----+ +-----+ +-----+ +-----+ +----+ | |dialog| |dialog| |dialog| | CS | | | UA |<---->|B2BUA|<---->|B2BUA|<---->|B2BUA|<---->| UA | | | | | | | | | conn | | +----+ +-----+ +-----+ +-----+ +----+ |--segment--| |--segment--| |---------segment---------| |---------segment--------| Figure 1 Example of Communication Segments. Source communication segment: A "source communication segment" or "source segment" for short is the communication segment of a call/session that is moved in a mobility operation. It is Coulas, et al. Expires October 2, 2008 [Page 5] Internet-Draft SIP P-Header for Mobility Operations April 2008 terminated at one end by a mobile endpoint UA (i.e., mobile device) and at the other end by a Mobility Application Server. The source segment is essentially the part of the signaling path of the call/session that is moved in a mobility operation. Remote communication segment: A "remote communication segment" or "remote segment" for short is the communication segment forming the other half of a call/session that is not moved in a mobility operation. It is terminated at one end by a Mobility Application Server and at the other end by an endpoint UA (mobile or not). While the remote segment is not directly moved in a mobility operation, it may still be impacted by the move. The relationship between the source and remote segment for a simple two party call/session is illustrated in Figure 2. +----+ +--------+ +--------+ +----+ | | dialog |mobility| dialog |mobility| CS | | | UA |<------>| server |<-------------->| server |<------>| UA | | | |(B2BUA) | |(B2BUA) | conn | | +----+ +--------+ +--------+ +----+ Source Remote |-----segment----|----------segment------------------------| Figure 2 Example of Source and Remote Segments. Mobility Application Server (AS): A "Mobility Application Server" is a SIP B2BUA in the network that acts as an anchor point for the source and remote segments of a call/session and is responsible for managing mobility operations for the source segment. Different Mobility Application Servers may be responsible for managing different types of mobility operations (e.g., VCC AS for VCC domain transfers; SMF AS for session mobility transfers). The different endpoints in a call/session may be served by different Mobility Application Servers. Call/session: The term "call/session" is used in this document to generally refer to a communication session, between one or more parties, that may contain both circuit-switched connections and/or SIP sessions. 3. Usage in INVITE requests The P-Mobility header is used in an initial INVITE request to initiate a mobility operation for an existing call/session. Two different variants of mobility operations are supported: Coulas, et al. Expires October 2, 2008 [Page 6] Internet-Draft SIP P-Header for Mobility Operations April 2008 o Call/session mobility for a single device. In this type of mobility, a call/session on a single device is transferred to a different network. The transfer-from network can either be a circuit-switched or a packet-switched network while the transfer- to network will typically be a packet-switched network. Note that in certain cases, such as with 3GPP IMS Centralized Services (ICS), where the core network supports the use of SIP to do call control signaling even though a circuit-switched bearer is used for audio, the transfer-to network may also be a circuit- switched network. o Call/session mobility from one device to another. In this type of mobility, a call/session on one device is transferred to a different device. This type of mobility operation may involve transferring the call to a different network. For example, INVITE w/P-Mobility may be used in conjunction with SIP REFER requests, as described in [3]. Also, as described in [3], inter-device mobility may be applied to the entire call/session or to a specific media component of the call/session. The INVITE request with P-Mobility header is sent by an endpoint UA in the device initiating the mobility operation. This request is routed to one or more Mobility Application Servers in the SIP core network serving the user initiating the mobility operation. Each mobility application server in the path services the mobility operation that it is responsible for managing, based on the value of the cause parameter(s) contained in the P-Mobility header. Processing of the mobility operation by an application server involves establishing a new source segment that replaces an existing one, updating the remote segment and, if necessary, forwarding the INVITE request to the next mobility application server upstream. 3.1. Sending an INVITE Request with a P-Mobility header When an endpoint UA on a device wishes to initiate a mobility operation, it needs to establish a new source segment for the call/session that will replace the current source segment. An endpoint UA, compliant to this draft, SHALL initiate a mobility operation for an existing call/session by sending a SIP INVITE request containing a P-Mobility header. The P-Mobility header value is "transfer" which identifies the request as initiating a mobility transfer of an existing call. Note that the value "transfer" is defined in anticipation of further values such as "info" being defined in future revisions of Coulas, et al. Expires October 2, 2008 [Page 7] Internet-Draft SIP P-Header for Mobility Operations April 2008 this draft(refer to Section 7. Future Considerations for more information). Otherwise, a value of "*" would be sufficient. Associated with the "transfer" value is a cause parameter which qualifies the type of mobility transfer operation being requested. If more than one type of mobility operation is being requested, then a separate transfer cause value for each mobility type SHALL be included in the P-Mobility header. Alternatively, these separate values MAY also be included in separate P-Mobility headers. The current version of this draft defines three different cause values for the P-Mobility header. These are: o Cause=1, VCC Domain Transfer (e.g., transfer of GSM CS call to SIP VoIP) o Cause=2, PS-PS Session Mobility (e.g., VoIP/wi-fi to VoIP/3G cellular) o Cause=3, Inter-device Session Mobility (e.g., transfer session from desk VoIP phone to VoIP/WiFI session on dual-mode cell phone) As inter-device session mobility will almost always involve either a PS-PS session transfer or a VCC domain transfer, the inter-device session mobility cause, SHOULD be used in tandem with at least one of the other two causes. The justification for defining an additional cause value for inter-device session mobility is that this type of mobility operation may have more stringent security requirements than single device mobility. The syntax of the P-Mobility header is somewhat similar to that of the SIP Reason header. In addition to a cause parameter, a P-Mobility header value MAY also include a text parameter containing a descriptive text that can either be logged or displayed on a UI. Examples of P-Mobility headers that could be included in an INVITE request are: Initiating VoIP session transfer from WiFi to WiMAX: P-Mobility: transfer;cause=2 Initiating CS call to VoIP session VCC domain transfer: P-Mobility: transfer;cause=1;text="VCC Domain Transfer to WiFi" Initiating VoIP session transfer from one device to another: Coulas, et al. Expires October 2, 2008 [Page 8] Internet-Draft SIP P-Header for Mobility Operations April 2008 P-Mobility: transfer;cause=2, transfer;cause=3;text="Inter-device session mobility" Initiating transfer of a CS call with Video Share session to an audio+video multimedia session: P-Mobility: transfer;cause=1, transfer;cause=2 Other requirements for generating the INVITE request are: o The INVITE Request-URI SHALL be set to the URI of the remote party in the call/session being moved. This URI MUST correspond to the AOR, telephone number or GRUU that was exchanged in the signaling used to setup the original call/session. o The INVITE request shall use the same identity for the local party that was exchanged in the signaling used to setup the original call/session. This identity may be included in a P-Preferred- Identity header (e.g., IMS) and/or a From header. o The INVITE request SHALL include a Require header field with a value that contains the "mobility-op" option tag. o If a PS-PS session mobility operation is being initiated, then the SDP specification contained in the INVITE request SHOULD use the same session ID in the "o=" line as in the SDP specification of the session being moved. Provisional message reliability [8] and preconditions [9] MAY be applied to the mobility session establishment, if necessary. However, 180 (Ringing) provisional responses SHOULD NOT be received. If a 200 (OK) response is received, then the UA SHALL release the old transfer-from source segment, if possible, by sending a BYE request, as specified in Section 4. of this document. If a 420 (Bad Extension) response identifying "mobility-op" as an unsupported extension is returned, then this signifies that the user's serving network (or possibly the remote party UA) does not support the mobility mechanisms specified in this draft. The UA may then either attempt to use an alternative mechanism (e.g., INVITE w/Replaces) or simply give up. If any other error response code is received, then the UA SHOULD follow the behavior described in Section 8.1.3 of [2]. Coulas, et al. Expires October 2, 2008 [Page 9] Internet-Draft SIP P-Header for Mobility Operations April 2008 In any case, if the mobility operation fails for any reason, then the transfer-from source segment SHALL continue to be used, if possible. For single device mobility, this means continuing to use the transfer-from access network. For inter-device mobility, this means maintaining the call/session on the transfer-from device. 3.2. Mobility Application Server Behavior The INVITE request with P-Mobility header is processed by the mobility application server(s) in the home SIP network serving the user that is initiating the mobility operation. As the request is addressed to the remote party of an existing call/session, it is the responsibility of the home SIP network to ensure that the INVITE request is routed to the appropriate mobility application server(s). While this draft does not specify any particular mechanism for doing this, a good example of such a mechanism would be the initial Filter Criteria (iFC) mechanism for triggering services, specified in the 3GPP IMS standards [10]. In this case, originating iFC associated with this mobility service matches the contents of the INVITE request against a specific boolean expression and if there is a match, then the request is routed to a specific application server. When the mobility application server receives as INVITE request with P-Mobility header, it processes the request as follows: o If the P-Mobility header does not contain a mobility cause value that it is responsible for processing, then it does not perform a mobility operation. However, it SHOULD anchor the new session as it would any other originating session and then forward the INVITE request on to its destination. o If the P-Mobility header does contain a mobility cause value that it is responsible for processing, then it performs the required mobility operation. If the P-Mobility header contains multiple mobility cause values that it is responsible for processing, then the mobility application server SHALL perform each required mobility operation in sequence. o In the case where the P-Mobility header contains both a VCC Domain Transfer cause value and a PS-PS Session Mobility cause value, the PS-PS Session Mobility operation SHALL be performed and completed before the VCC Domain Transfer operation. Coulas, et al. Expires October 2, 2008 [Page 10] Internet-Draft SIP P-Header for Mobility Operations April 2008 o Once the mobility application server determines that it is responsible for processing the mobility operation, it attempts to match the INVITE request with a call/session currently anchored at the server. If the INVITE request does not match any call/session, then the server SHALL reject the request and return a 480 (Temporarily Unavailable) response back to the user. A mobility operation consists of the following generic steps: o The mobility application server SHALL behave as a UAS for the INVITE request, establishing a new source segment for the call/session. This anchors the new source segment at the mobility application server thus enabling future mobility operations for that segment. o The mobility application server SHALL update the remote segment of the call/session by sending a re-INVITE request over the remote segment. o The mobility application server SHALL release the old source segment by sending a BYE request, as specified in Section 4. of this document. o Once the mobility operation is completed, the mobility application server SHALL remove the mobility cause value that is associated with the completed mobility operation from the P-Mobility header. o If, after removing the mobility cause value, the P-Mobility header still contains a cause value other than "Inter-device Session Mobility", the mobility application server SHALL forward the INVITE with modified P-Mobility header to its destination, which should cause it to be routed to the next mobility application server upstream. Note that in keeping with B2BUA operation, the forwarded INVITE request is sent as a new SIP request. o If, after removing the mobility cause value, the P-Mobility header does not contain any cause value other than "Inter-device Session Mobility", then processing of the INVITE request is completed. At this point, the mobility operation associated with the original INVITE request sent by the endpoint UA is considered to be completed. Other than the generic steps described here, details specific to the type of mobility operation being performed are outside the scope of this draft. Coulas, et al. Expires October 2, 2008 [Page 11] Internet-Draft SIP P-Header for Mobility Operations April 2008 3.3. Proxy Server Behavior In general, SIP proxy servers route an INVITE request with P-Mobility header as they would any other INVITE request. However, it is the responsibility of the proxy in the home SIP network serving the user that is initiating the mobility operation to route the INVITE request to the appropriate mobility application servers. It should be noted that since mobility operations are always initiated by the endpoint UA (i.e., device), mobility application servers in the home SIP network of the remote party addressed by an INVITE request with P-Mobility header MUST NOT process the INVITE request. In 3GPP IMS networks, this means that terminating iFC should not be defined for this service. A SIP proxy SHOULD NOT add or delete or modify a P-Mobility header. However, in some SIP network implementations, it MAY be possible for the serving proxy to explicitly reject an INVITE request that has the "mobility-op" SIP option tag in the Require header if the "mobility- op" extension is not supported by that network. 3.4. Remote Party UAS Behavior A UAS at the remote party end of the call/session MAY receive an INVITE request with P-Mobility header if the P-Mobility header was not completely processed in the home SIP network of the user that initiated the mobility operation. In this case, the UAS MAY process the INVITE request, if it supports the "mobility-op" extension. Processing of the mobility operation, in this case, would be similar to that performed by the mobility application server except that there would be no remote segment to update. If the UAS does not support the "mobility-op" extension or if it is unable to process the specified mobility cause then it SHALL return a 420 (Bad Extension) response. 4. Usage in BYE requests Upon successful establishment of the new transfer-to source segment(s) in a mobility operation, both the endpoint UA in the device which initiated the mobility operation and the UAS in the network managing the mobility operation (e.g., the mobility application server) SHALL release the transfer-from source segment(s) by sending a BYE request(s) with a P-Mobility header containing one or more cause values describing the type of mobility operation being completed. Coulas, et al. Expires October 2, 2008 [Page 12] Internet-Draft SIP P-Header for Mobility Operations April 2008 Inclusion of the P-Mobility header in the BYE request SHALL enable both the device and the network to unambiguously distinguish between a source segment release in a mobility operation and a user initiated release of the call/session occurring during the transfer. The BYE request with P-Mobility header is sent by both ends of the mobility operation in order to deal with cases where network connectivity over the transfer-from source segment may be lost. Examples of P-Mobility headers that could be included in a BYE request are: Releasing WiFi segment after a VoIP session transfer from WiFi to WiMAX: P-Mobility: transfer;cause=2; Releasing VoIP segment after a VCC domain transfer to CS call: P-Mobility: transfer;cause=1;text="VCC release of VoIP call leg" Releasing the multi-media session segment after completion of a handover of an audio+video multimedia session to a CS call with Video Share session: P-Mobility: transfer;cause=1, transfer;cause=2 4.1. Endpoint UA Behavior Upon successful establishment of the new transfer-to source segment(s) in a mobility operation, the endpoint UA which initiated the mobility operation SHALL release any of the old transfer-from segments that have not already been released by the network by sending a BYE request, for each segment, with a P-Mobility header containing one or more cause values describing the type of mobility operation being completed for that segment. The endpoint UA MAY, at any time after initiation of a mobility operation, receive BYE requests from the network releasing any of the old transfer-from segments that need to be released. These BYE requests MUST contain a P-Mobility header containing one or more cause values describing the type of mobility operation being completed for that segment. Any BYE request received without a P-Mobility header SHOULD be interpreted as a call/session release request. Coulas, et al. Expires October 2, 2008 [Page 13] Internet-Draft SIP P-Header for Mobility Operations April 2008 4.2. Mobility Application Server Behavior Upon successful establishment of the new transfer-to source segment(s) in a mobility operation, the mobility application server SHALL release any of the old transfer-from segments that have not already been released by the endpoint UA by sending a BYE request, for each segment, with a P-Mobility header containing one or more cause values describing the type of mobility operation being completed for that segment. This BYE request SHALL be sent downstream towards the endpoint UA. A mobility application server MAY, at any time after initiation of a mobility operation, receive a BYE request from another mobility application server upstream. This BYE request SHOULD NOT contain a P- Mobility header with a cause value that the mobility application server is responsible for processing. However, upon receiving such a BYE request, the mobility application server SHALL, assuming the dialog still exists, forward it downstream toward the endpoint UA. A mobility application server MAY, at any time after initiation of a mobility operation, receive BYE requests from the endpoint UA or from another mobility application server downstream. These BYE requests MUST contain a P-Mobility header containing one or more cause values describing the type of mobility operation being completed for that segment. These BYE requests may or may not contain a P-Mobility header with a cause value that the mobility application server is responsible for processing. However, after processing the BYE request, the mobility application server SHALL remove any mobility cause value(s) from the P-Mobility header that it is responsible for processing. If, after removing the mobility cause value(s), the P- Mobility header still contains another cause value, the mobility application server SHALL, assuming the dialog still exists, forward the BYE request with modified P-Mobility header upstream towards the next mobility application server. Any BYE request received without a P-Mobility header SHOULD be interpreted as a call/session release request and SHOULD trigger a release of the call/session. 5. "mobility-op" SIP Option Tag Usage An INVITE request sent by an endpoint UA to initiate a mobility operation SHALL include a Require header field with a value that contains the "mobility-op" option tag. An INVITE request sent to an endpoint UA by a mobility application server compliant to this draft SHALL include a Supported header field Coulas, et al. Expires October 2, 2008 [Page 14] Internet-Draft SIP P-Header for Mobility Operations April 2008 with a value that contains the "mobility-op" option tag. Similarly, a 200 (OK) response sent by a mobility application server, compliant to this draft, in response to an INVITE request for a SHALL include a Supported header field with a value that contains the "mobility-op" option tag. This usage of the "mobility-op" SIP Option Tag provides a means for the network to inform the UA on the device that it supports the P- Mobility header in INVITE and BYE requests. An INVITE request sent by an endpoint UA compliant to this draft SHALL include a Supported header field with a value that contains the "mobility-op" option tag. Similarly, a 200 (OK) response sent by an endpoint UA, compliant to this draft, in response to an INVITE request SHALL include a Supported header field with a value that contains the "mobility-op" option tag. This usage of the "mobility-op" SIP Option Tag provides a means for the UA in the device to inform the network that it supports the P- Mobility header in INVITE and BYE requests. Note that in the case of inter-device session mobility, the device initiating the mobility operation cannot rely on this mechanism to determine network support for the "mobility-op" extension. This is due to the fact that the transfer-from segment of the call/session is not terminated at the transfer-to device and subsequently did not receive a "Supported: mobility-op" header from the network for that call. However, if the mobility operation is triggered as a result of receiving a REFER request to INVITE w/P-Mobility, similar to the approach described in [3], then the device can infer that the network supports the "mobility-op" extension. A BYE request sent by an endpoint UA to release a transfer-from segment in a mobility operation MAY include a Require header field with a value that contains the "mobility-op" option tag. A BYE request sent by a mobility application server to release a transfer-from segment in a mobility operation MAY include a Require header field with a value that contains the "mobility-op" option tag. 6. Example Call Flows For simplicity, the following are not shown in the call flows: o SIP ACK requests o Role of SIP proxy servers Coulas, et al. Expires October 2, 2008 [Page 15] Internet-Draft SIP P-Header for Mobility Operations April 2008 6.1. CS call to VoIP session VCC domain transfer In this scenario, a mobile device initiates a VCC domain transfer of a circuit-switched call to a VoIP/WiFi session. Transfer-from segment is released by the network. Mobile Network Network Remote UA SNF AS VCC AS segment | Domain Transfer | | . |<~~~~~Trigger | | . | | | . | INVITE (Cause=1) | | . |--------------------->| INVITE (Cause=1) | . | Anchor~~~>|--------------------->| . | Session | Update~~~~>| re-INVITE | | Remote Segment |------------------> | | | 200 OK . | | 200 OK |<------------------ | 200 OK |<---------------------| . |<---------------------| | . |<~~~~Switch to VoIP | | . | | | . | BYE (Cause=1) | | Release . |<--------------------------------------------|<~~~CS Segment . | | 200 OK | . |-------------------------------------------->| . |<~~~CS release~~~> | | . | | | . Figure 3 Call Flow: CS call to VoIP session VCC domain transfer. 1. Endpoint UA sends a INVITE request over WiFi connection containing a P-Mobility header with cause=1. 2. INVITE request is routed to mobility application server which handles PS-PS mobility (SNF AS). 3. Mobility application server (SMF AS) does not handle P-Mobility header with cause=1 and therefore anchors the new session. 4. INVITE request is forwarded upstream to mobility application server which handles CS-PS VCC (VCC AS). 5. Mobility application server (VCC AS) recognizes and therefore handles P-Mobility header with cause=1. Hence, mobility application server performs VCC mobility operation. Coulas, et al. Expires October 2, 2008 [Page 16] Internet-Draft SIP P-Header for Mobility Operations April 2008 6. Mobility application server (VCC AS) sends re-INVITE request to update remote segment. 7. Mobility application server (VCC AS) releases transfer-from segment by sending BYE request, containing a P-Mobility header with cause=1, towards endpoint UA. 8. CS call is released and BYE request containing a P-Mobility header with cause=1 is sent to endpoint UA (3GPP IMS Centralized Services (ICS) is assumed). 6.2. IMS multimedia session to CSI session transfer. In this scenario, a mobile device initiates a transfer of a audio+video multimedia/WiFi session to a CS call with Video Share CSI session. Transfer-from segment is released by the network. This is a more complex scenario involving both a VCC domain transfer and a PS- PS transfer. Note that the assumption here is that audio components of a call/session are always anchored at the VCC AS. Hence initially, the original multimedia session is split at the SMF AS into an audio segment towards the VCC AS (and then towards the CSI AS) and a video segment towards the CSI AS. A CSI AS that is linked into the signaling path after the mobility application servers is responsible for managing CSI services for the local party and the call/session towards the remote party. Coulas, et al. Expires October 2, 2008 [Page 17] Internet-Draft SIP P-Header for Mobility Operations April 2008 Mobile Network Network Remote Network UA SNF AS VCC AS segment CSI AS | | | . | | Domain Transfer | | . | |<~~~~~Trigger | | . | | | | . | | INVITE (Cause=2) | | . | |-------------------->| | re-INVITE(video) | | Update~~~~>|----------------------------------------->| | Remote Segment | INVITE (Cause=1) | . | |----------------------------------------->| . | |<~~~CS setup~~~> | 200 OK | . | | 200 OK |<-----------------------------------------| |<--------------------| Release | . | | BYE (Cause=2) | Multimedia | re-INVITE(audio) | |<--------------------|<~~Session Update~~>|-------------------->| | 200 OK | Remote | . | |-------------------->| Segment | 200 OK . | | 200 OK | |<--------------------| |<-----------------------------------------| . | | | BYE (Cause=1) | Release . | | |<-------------------|<~~~VoIP . | | | | Session . | | | | . | Figure 4 Call Flow: IMS multimedia to CSI session transfer. 1. Endpoint UA in a nultimedia/WiFi session sends an INVITE request over 3GPP UMTS PS connection containing a P-Mobility header with cause=2. This INVITE requests negotiates a video only session. 2. Endpoint UA in sends an INVITE request containing a P-Mobility header with cause=1, over control channel associated with CS connection. (Not shown: endpoint UA establishes CS audio bearer). Note that the remaining steps may occur in a different order than shown. 3. INVITE request with mobility cause=2 is routed to mobility application server which handles PS-PS mobility (SMF AS). 4. Mobility application server (SMF AS) does recognizes and therefore handles P-Mobility header with cause=2. Hence, mobility application server performs PS-PS mobility operation. Coulas, et al. Expires October 2, 2008 [Page 18] Internet-Draft SIP P-Header for Mobility Operations April 2008 5. Mobility application server (SMF AS) sends re-INVITE request to update remote segment, which in this case is a video session terminated at the CSI Application Server. 6. Mobility application server (SMF AS) releases transfer-from multimedia segment by sending BYE request, containing a P-Mobility header with cause=2, towards endpoint UA. 7. INVITE request with mobility cause=1 is forwarded upstream to mobility application server which handles CS-PS VCC (VCC AS). 8. Mobility application server (VCC AS) recognizes and therefore handles P-Mobility header with cause=1. Hence, mobility application server performs VCC mobility operation. 9. Mobility application server (VCC AS) sends re-INVITE request to update remote segment, which in this case is an audio session terminated at the CSI Application Server. 10. Mobility application server (VCC AS) releases transfer-from segment by sending BYE request, containing a P-Mobility header with cause=1, towards endpoint UA, via the Mobility application server (SMF AS). 11. Mobility application server (SMF AS) does not forward the BYE request towards the endpoint UA as the transfer-from segment has already been released. Note that the reverse scenario in which a mobile device initiates a transfer of a CS call with Video Share CSI session to an audio+video multimedia/WiFi session would involve sending a single INVITE request containing a P-Mobility header with cause=1 (VCC domain transfer) and cause=2 (PS-PS mobility). 7. Future Considerations This section describes some additional desirable features to be considered for inclusion in subsequent revisions of this draft. 1. It may be desirable to define an additional P-Mobility header value "info" that could be included in INVITE requests or in 200 (OK) responses to INVITE requests to provide information related to the support of or implementation of specific mobility operations. For example, the following P-mobility header P-Mobility: info;cause=1, info;cause=2 Coulas, et al. Expires October 2, 2008 [Page 19] Internet-Draft SIP P-Header for Mobility Operations April 2008 contained in an INVITE request or a 200 (OK) response received from the network would indicate that the network supports VCC domain transfer and PS-PS mobility for that call. Specific information associated with each supported mobility cause for that call could be included in additional P-Mobility parameters (see desirable feature 2). 2. It may be desirable to define some additional optional P- Mobility header parameters to be associated with specific mobility causes. For example, a parameter identifying a specific call/session as the target of a mobility operation could be associated with all mobility causes. This call/session identifier would then be used as an alternative to SDP session IDs or dialog IDs for this purpose. This would be particularly useful for supporting inter-device mobility operations such as those described in [3] as it may otherwise be difficult for the device originating the mobility operation to include sufficient information in the INVITE w/P-Mobility to identify the call/session being transferred. These additional parameters could be used in both "info" and "transfer" P-Mobility headers. Definition of new P-Mobility header parameters is for future consideration. 3. It may be desirable to extend usage of the P-Mobility header to support network initiated mobility operations. In these scenarios, the network would initiate the VCC domain transfer or PS-PS mobility operation by sending an INVITE with appropriate mobility causes to the device. 8. Security Considerations TBD 9. IANA Considerations This document adds to the IANA Registry a private SIP header field P- Mobility and defines a SIP option tag. Formal specification is TBD. 10. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Coulas, et al. Expires October 2, 2008 [Page 20] Internet-Draft SIP P-Header for Mobility Operations April 2008 11. References 11.1. Normative References [1] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, December 2002. [2] 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. [3] Shacham, R. Schulzrinne, H., Thakolsri, S., Kellerer, W., "Session Initiation Protocol (SIP) Session Mobility", draft- shacham-sipping-session-mobility-04 (work in progress), July 2007. [4] 3GPP TS 23.206: "Voice call continuity between Circuit Switched (CS) and IP Multimedia Subsystem (IMS)"; Stage 2". [5] 3GPP TS 23.279: "Combining CS and IMS services"; Stage 2. 11.2. Informative References [6] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. [7] Polk, J., "Extending the Session Initiation Protocol (SIP) Reason Header for Preemption Events", RFC 4411, February 2006 [8] Rosenberg J., Schulzrinne, H., "Reliability of Provisional Responses in the Session Initiation Protocol (SIP)", RFC 3262, June 2002 [9] Camarillo, G., Marshall, W., Rosenberg J., "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002 [10] 3GPP TS 24.229: "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)"; Stage 3 Coulas, et al. Expires October 2, 2008 [Page 21] Internet-Draft SIP P-Header for Mobility Operations April 2008 Author's Addresses Michael F. Coulas Motorola 600 N. US Highway 45 Room E1/50N Libertyville, IL 60048 U.S.A. Phone: +1 847-523-1827 Email: mcoulas1@motorola.com Apostolis K. Salkintzis Motorola 32 Kifissias Ave. Athens, 15125, Greece Phone: +30-210-8172335 Email: salki@motorola.com 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. Coulas, et al. Expires October 2, 2008 [Page 22] Internet-Draft SIP P-Header for Mobility Operations April 2008 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, THE IETF TRUST 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 IETF Trust (2008). 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. Coulas, et al. Expires October 2, 2008 [Page 23]