SIPPING Working Group S. Salsano Internet-Draft Univ. of Rome Tor Vergata Intended status: Informational S. Niccolini Expires: August 27, 2007 NEC L. Veltri Univ. of Parma A. Polidoro Univ. of Rome Tor Vergata February 23, 2007 A solution for vertical handover of multimedia sessions using SIP draft-salsano-sipping-siphandover-solution-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 27, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Salsano, et al. Expires August 27, 2007 [Page 1] Internet-Draft Solution for SIP-based vertical handover February 2007 Abstract This document proposes a solution for handling vertical handovers among different network technologies using SIP, fulfilling a set of requirements discussed in the document "Requirements for vertical handover of multimedia sessions using SIP" (draft-niccolini-sipping-siphandover-01). The solution requires a new header field (named "Handover") and a new parameter in the Via header field (named "MMID"). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Architecture of the proposed solution . . . . . . . . . . . . 4 3. Signalling procedures . . . . . . . . . . . . . . . . . . . . 6 3.1. Off-call mobility: Location Update (LU) Registration procedure . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. Extensions to SIP specifications . . . . . . . . . . . 7 3.2. User Registration procedure . . . . . . . . . . . . . . . 8 3.2.1. Extensions to SIP specifications . . . . . . . . . . . 8 3.3. Session Establishment procedure . . . . . . . . . . . . . 9 3.3.1. Extensions to SIP specifications . . . . . . . . . . . 10 3.4. On-Call Mobility: Handover procedure . . . . . . . . . . . 10 3.4.1. Extensions to SIP specifications . . . . . . . . . . . 12 4. Routing of requests and responses . . . . . . . . . . . . . . 13 4.1. Use of Contact header field . . . . . . . . . . . . . . . 13 4.2. MMID parameter in Via header field . . . . . . . . . . . . 14 5. Handover: header . . . . . . . . . . . . . . . . . . . . . . . 15 6. Decoupling user level registration and terminal level registration . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. Security considerations . . . . . . . . . . . . . . . . . . . 18 9. Informative References . . . . . . . . . . . . . . . . . . . . 19 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 22 Salsano, et al. Expires August 27, 2007 [Page 2] Internet-Draft Solution for SIP-based vertical handover February 2007 1. Introduction A set of requirements for vertical handover using SIP has been discussed in [1]. Figure 1 reports the scenario under consideration. In short, the requirement is to allow a Mobile Host to roam over different access networks using both public and private IP addresses, minimizing service disruption due to mobility, without relying on Corresponent Host functionality and even hiding to the Correspondent Host the movements of the Mobile Host. In this document we describe a possible solution to these requirements (and all the other ones listed in [1]). The solution requires a new header field (named "Handover") and a new parameter in the Via header field (named "MMID"). The new header and new parameter will only be added and processed by the entities directly involved in the management of the mobility, with no impact on other SIP entities. +-------+ | AN1 |-----+ ----| | NAT | +--------+ / +-------+-----+ |Corresp.| +-------+ __________ | Host 1 | | Mobile| +-------+ / \ +--------+ | Host | | AN2 | / \ +-------+ ----| | | INTERNET | + - - - + \ / \__________/ \ +-------+ +--------+ ----| AN3 |-----+ +-----|Corresp.| | | NAT | | NAT | Host 2 | +-------+-----+ +-----+--------+ Figure 1: Scenario for Vertical Handover In Section 2 the architectural elements of the solution are presented. Section 3 describe the signalling procedures to realize the mobility management (both off-call and on-call) and the establishment of sessions. Section 4 and Section 5 specify the new parameters in the Via header field (named "MMID") and the new header field (named "Handover") that are required by the proposed solution. Salsano, et al. Expires August 27, 2007 [Page 3] Internet-Draft Solution for SIP-based vertical handover February 2007 2. Architecture of the proposed solution The elements of the proposed solution are shown in Figure 2. We assume that a Mobile Host (MH) is communicating with a Correspondent Host (CH). The MMS is the Mobility Management Server which is able to handle user mobility across different access networks and to perform the handover. The MMS cooperates with the MMC (Mobility Management Client) which resides on the Mobile Host. Figure 2 shows that NAT boxes can be inserted between the MH and the MMS. Figure 2 shows a standard SIP trapezoid with the additional elements of this solution (MMS and MMC). Such figure is just for explanation purposes, the solution proposed here is not depending on the communication following the standard SIP trapezoid to work. The MMS is an "anchor point" for the media flows which are transmitted over the wireless access networks directed to (and coming from) the MH. When the MMC in the MH detects that a handover is needed, it will request the handover to the MMS (via a SIP message) over the "target" network. Then the MMS will update its media proxy and will start transmitting and receiving the media over the target network (details are provided in the next section). Note that the entire handover procedure is handled by the MH and the MMS, letting the CT (and other SIP intermediate nodes) completely unaware of what is occurring. For the sake of simplicity, we only describe here the solution considering a single centralized MMS. In real life, the MMS functionality may need to be distributed for scalability and reliability reasons. The Mobility Management Client can be implemented (as shown in Figure 2) as a separate entity running on the MH that masquerades all mobility and NAT traversal functionality by relaying both signaling and media flows. In this case the SIP User Agent sees the MMC as default "outbound proxy" (which means that the UA will send all SIP message to the MMC) and it has no knowledge of the handovers. Existing SIP UAs can be easily supported/reused without any changes. A different solution would be to integrate the MMC functionality within the UA, saving resources of the MH. These two solutions only differ in the internal implementation, while there is no difference in the external behavior of the procedures. Salsano, et al. Expires August 27, 2007 [Page 4] Internet-Draft Solution for SIP-based vertical handover February 2007 Classical SIP UA +-------+ +-------+ Registration | MH's |---| CH's | ................> | Proxy | | Proxy | . /+-------+ +-------+\ . / \ . / \ . / \ Mobile Host . +-----+ +----+ +-------+ . | MMS |---------------------------| CH | |+-----+|<... +-----+ +----+ || UA || / A |+-----+| / . |+-----+| +-----+ / . || MMC ||---------| NAT |/ . Mobile Host Mobility |+-----+| `+-----+ . +---A---+ . . . . . ..................... Figure 2: Architecture of the proposed solution Salsano, et al. Expires August 27, 2007 [Page 5] Internet-Draft Solution for SIP-based vertical handover February 2007 3. Signalling procedures This section describes the specific procedures for mobility management (off-call and on-call) and shows how the canonical SIP procedures (user registration and session establishment) are realized under the proposed solution. The procedure for mobility management related to the off-call part is meant to be used by the MH (UA+MMC) to tell the MMS about its current selected/active interface (or to communicate changes to such selection) when not in a call, for this we use regular REGISTER sent from the MMC to the MMS. The on-call mobility management related to the on-call part is meant to be used by the MH (UA+MMC) to tell the MMS about a change in its current selected/active interface when in a call, for this we use regular REGISTER sent from the MMC to the MMS with an additional "Handover" header which contains the reference to the active session(s) to which the handover is referred. In both cases an additional parameter to be added to the "Via" header for correct routing of responses to the MMC is needed and used. 3.1. Off-call mobility: Location Update (LU) Registration procedure The "Location Update" (LU) Registration is the basic mobility procedure that allows a MH to notify the MMS about its "position" (or better about its IP address) and select the currently preferred interface for sending/receiving SIP signaling and media flows. The sequence diagram of this procedure is shown in Figure 3. The MMC in the MH sends a standard REGISTER to the MMS over the selected/active interface. This procedure is activated at the start up of the MH (or when the MH first enters in a coverage area), or whenever the MH wants to change the selected/active interface if it is under coverage of more than one network. We can refer to this procedure as "off- call" mobility management because we assume that the MH is not engaged in a call. If the MH is engaged in a call, the handover procedure will be executed (see Section 3.4). When the 200 OK is received, a "keep-in-touch" mechanism is activated on that interface (and deactivated on the previous interface if needed) in order to keep the pinhole in the NAT open. Various techniques could be used for this purpose; we use periodic SIP REGISTER messages from MMC to MMS. Salsano, et al. Expires August 27, 2007 [Page 6] Internet-Draft Solution for SIP-based vertical handover February 2007 +-------+ +-------+ +-------+ +-------+ | U A | | MMC | | MMS | | Proxy | +-------+ +-------+ +-------+ +-------+ | | | | | | LU REGISTER | | | |============>| | | | | | | | 200 OK | | | |<============| | | | | | Figure 3: Location Update Procedure As result of the Location Update Registration procedure, the MMS becomes aware of the current position (i.e. IP address and port) of the MH, and can correctly route any new request or response messages addressed to the mobile UA (even across a NAT box). For each registered user the MMS stores the IP address and port from which it received the "Location Update" (LU) REGISTER. This information can be stored by the MMS in a table that we call "MMS mobility database" containing the MMS state. Such table is depicted in Figure 4. ---------------------------------------------- | User(terminal) | IP/port | ---------------------------------------------- | user@domain.com | 160.80.81.23:45678 | | user2@domain.com | 87.3.235.212:23458 | | ... | ... | ---------------------------------------------- Figure 4: MMS mobility database 3.1.1. Extensions to SIP specifications The Location Update Registration procedure does not require specific extensions to the current SIP specification. A LU REGISTER will have the MMS as target SIP URI in the request line. If the MMS only handles LU REGISTERs there is no problem. If the MMS also handles normal user registration REGISTER (i.e. it acts also as a SIP registrar) the MMS needs to identify LU REGISTERs from normal user REGISTER. In this case a specific SIP URI can be associated to the LU REGISTER messages. Anyway as will be discussed in Section 4, the MMC will add the new parameter "MMID" in the Via header of the REGISTER, in order to have the responses routed to current location (IP addresses) of the MH. Salsano, et al. Expires August 27, 2007 [Page 7] Internet-Draft Solution for SIP-based vertical handover February 2007 3.2. User Registration procedure This procedure consists in the UA registration with its own SIP Registrar server. The sequence diagram of this procedure is described in Figure 5. As any other SIP message, when the UA sends its own registration request to the SIP Registrar, the message is sent by the UA to the MMC which is seen as outbound proxy. The MMC forwards it to the MMS. Acting on behalf of the MH, the MMS will forward the registration to the SIP Registrar, which will update the contact address associated with the user's AoR (that is the public user identifier). When forwarding the REGISTER message, the MMS modifies the Contact header in such a way it becomes the new "contact" for the user. This is required in order to force the routing through the MMS of all further requests addressed to the user. Such mangling of the contact URL should be unique and reversible. Details on how to encode the user AoR in the new contact are provided below in Section 4.1. From now on, only the MMS will keep track of the MH movements, while the SIP Registrar will just believe that the MH location is the IP address of the MMS. +-------+ +-------+ +-------+ +---------+ | U A | | MMC | | MMS | |MH'sProxy| +-------+ +-------+ +-------+ +---------+ | REGISTER | | | |============>| | | | | REGISTER | | | |============>| | | | | REGISTER | | | |=============>| | | | 200 OK | | | |<=============| | | 200 OK | | | |<============| | | 200 OK | | | |<============| | | | | | | Figure 5: User Registration 3.2.1. Extensions to SIP specifications The User Registration procedure requires that the MMS rewrites the contact address as will be described Section 4.1. Anyway, this does not need to be subject of specification as it only concerns the MMS. All other entities will simply handle the rewritten contact according to current SIP specification. As will be discussed in Section 4, the MMC will add the new parameter "MMID" in the Via header of the REGISTER messages, in order to have the responses routed to current Salsano, et al. Expires August 27, 2007 [Page 8] Internet-Draft Solution for SIP-based vertical handover February 2007 location (IP addresses) of the MH. 3.3. Session Establishment procedure The session establishment procedure consists in a standard SIP session setup procedure. All session establishment messages for MH are handled by the MMS. Before relaying an INVITE request sent by the caller and the corresponding 200 OK response sent by the callee the MMS modifies the corresponding SDP bodies in order to act as RTP proxy for media flows in both directions. This is needed to correctly handle NAT traversal in the path towards the MH, and it is done by using the symmetric RTP approach. Once the session is established, the media packets start to flow over the selected wireless interface. Figure 6 shows a session establishment from CH to MH. UserAgent MMC MMS MH's Proxy CH's Proxy CH | | | | | | | | | | | INVITE | | | | | INVITE |<===========| | | | INVITE |<===========| | | | INVITE |<===========| | | | INVITE |<===========| | | | |<===========| | | | | | 200 OK | | | | | |===========>| 200 OK | | | | | |===========>| 200 OK | | | | | |=========== | 200 OK | | | | | |===========>| 200 OK | | | | | |===========>| | | | | | ACK | | | | | ACK |<===========| | | | ACK |<===========| | | | ACK |<===========| | | | ACK |<===========| | | | |<===========| | | | | | | | | | | Figure 6: Session Establishment The MMS needs to keep a state information related to the active flows as it is performing a media relay functionality. In order to correclty perform the handover procedure, we require that this state information is accessible using the current call as key. SIP identifies a call by means of the Call-ID, the From and To header fields. Therefore the MMS maintains an "MMS call database", see Figure 7. For each call and for each media flow the information of Salsano, et al. Expires August 27, 2007 [Page 9] Internet-Draft Solution for SIP-based vertical handover February 2007 two "legs" (MH-MMS and CH-MMS) need to be stored . For each leg the local and remote IP addresses and port of the media flows are stored. As shown in Figure 7 the legs are stored as "originating" leg (i.e. the leg connecting the MMS with the user in the "From" header) and terminating leg (i.e. the leg connecting the MMS with the user in the "To" header). In Figure 7 only one media media flow per call, while in general more than one media flow can be associated to a call. ------------------------------------------------------------------- | Call | Originating leg | Terminating leg | ------------------------------------------------------------------- |Call-ID:F16@192 |Local: |Local: | |From:|160.80.81.23:4345 |160.80.81.23:4569 | |;tag=871 |Remote: |Remote: | |To: |151.2.82.21:3824 |87.3.235.212:3458 | |;tag=345 | | | ------------------------------------------------------------------- |Call-ID:xcv@1sfdsf.sdf |Local: |Local: | |From:|160.80.81.23:8732 |160.80.81.23:7745 | |;tag=sgf |Remote: |Remote: | |To: |87.3.233.12:23458 |151.8.48.2:3456 | |;tag=dsw | | | ------------------------------------------------------------------- Figure 7: MMS call database 3.3.1. Extensions to SIP specifications The User Registration procedure requires that the MMS rewrites the contact address as will be described Section 4.1. Actually, this is not a matter of specification as it only concerns the MMS. All other entities will simply handle the rewritten contact according to current SIP specification. As will be discussed in Section 4, the MMC will add the new parameter "MMID" in the Via header of the REGISTER messages, in order to have the responses routed to current location (IP addresses) of the MH. 3.4. On-Call Mobility: Handover procedure The on-call mobility management procedure takes place when the UA identifies the need for handoff during an ongoing session. In our proposal, all the handover signaling messages can be exchanged on the target network (this approach is commonly referred to as "forward" handover). Therefore the handover can be performed even if the communication on the old network is interrupted abruptly. The handover procedure (see Figure 8) is initiated by the MH. The MMC in the MH sends an "HandOver" (HO) REGISTER over the target network interface addressed to the MMS. Differently from a "Location Update" Salsano, et al. Expires August 27, 2007 [Page 10] Internet-Draft Solution for SIP-based vertical handover February 2007 (LU) REGISTER, the "HandOver" (HO) REGISTER request contains in the message body the reference to the active session(s) to which the handover is referred. At the same time, the MH starts duplicating the outgoing media packets on both interfaces (unless the old interface has gone down). As soon as the MMS receives the "HandOver" (HO) REGISTER, it starts accepting packets coming from the new interface and discarding the ones coming from the old interface for the active session(s) to be handed over. Then it sends back the 200 OK to the MMC and it starts sending the media packets directed to the MH using the new interface. Thanks to the fact that the terminal has already started sending the packets on the new interface, the duration of the handover is minimized. The most critical issue is that the "HandOver" (HO) REGISTER could be lost for any reason, delaying the handoff procedure. The standard SIP procedure foresees that the client performs a set of retransmission of the "HandOver" (HO) REGISTER if the 200 OK is not received back. The SIP specification suggests a default value of the T1 retransmission timeout equal to 500 ms, that is doubled on each retransmission (up to the value of T2 which by default is 4 s). The duration of the ritrasmission is 64*T1. However this is not compatible with a reasonable performance of the handover in case of the loss of the "HandOver" (HO) REGISTER. We propose the the timers for the "HandOver" (HO) REGISTER procedure should be set to lower values, like for example: T1 = 50 ms, T2 = 250 ms. On the MH side, the MMC will stop duplicating the packets on both interfaces as soon as the 200 OK is received or the first media packet is received on the new interface. Note that if the media packet is received, but no 200 OK message, the MMC will still continue sending the "HandOver" (HO) REGISTER until the REGISTER transaction expires. +-------+ +-------+ +-------+ +-------+ | U A | | MMC | | MMS | | Proxy | +-------+ +-------+ +-------+ +-------+ | | | | | | HO REGISTER | | | |============>| | | | | | | | 200 OK | | | |<============| | | | | | Figure 8: Handover REGISTER Salsano, et al. Expires August 27, 2007 [Page 11] Internet-Draft Solution for SIP-based vertical handover February 2007 3.4.1. Extensions to SIP specifications The on-call mobility management needs the definition of a new header field (see Section 5) to carry the identification of the call(s) to be handed over. This header field will be added by the MMC and handled by the MMS. Moreover, as will be discussed in Section 4, the MMC will add the new parameter "MMID" in the Via header of the REGISTER messages, in order to have the responses routed to current location (IP addresses) of the MH. Salsano, et al. Expires August 27, 2007 [Page 12] Internet-Draft Solution for SIP-based vertical handover February 2007 4. Routing of requests and responses In this section we detail how SIP messages are routed among the different entities. The challenge is to deliver incoming SIP requests and SIP responses to the MH, nonwithstanding its mobility. As for incoming SIP requests, when the UA in the MH performs the User Registration procedure (Section 3.2) the MMS rewrites the Contact header filed so that it points to the MMS itself. Therefore incoming requests for the MH will be forwarded by the SIP incoming proxy to the MMS. Similarly when outgoing requests are sent from the MH to a Correspondent Host the MMS will rewrite the Contact header so that the CH will consider the MMS as the destination of future requests to the MH. When incoming requests arrive to the MMS, the MMS will forward them to the current IP address of the MH, as updated by the MH using the Location Update procedure (Section 3.1). As for responses to outgoing SIP requests sent by the MH, the MMS adds a new parameter in the Via header field (see Section 4.2). This parameter is used by the MMS itself to route the response. 4.1. Use of Contact header field The solution foresees that the MMS rewrites the Contact header when forwarding outgoing SIP requests coming from the MH. The rewritten contact address will have as host part the IP address (or domain name) of the MMS, and as username part an hint to the original contact address. The procedure that binds the new username to the original contact address is just a matter of the MMS and is completely left to MMS implementation. There is no need to standardize the procedure for rewriting the Contact header. The only requirement is that such procedure must be reversible since the MMS needs to be able to rebuild the original Contact header field when receiving SIP requests addressed to the rewritten contact address. Obviously, the rewritten Contact header will be compatible with SIP specifications, so that all other involved entities will simply need to behave according to the standard. For example, a possible solution is that the MMS generates a pseudo- random string that is stored in a local database and used as key to retrieve the original Contact header field. Another possible solution is to embed the original contact in the rewritten contact so that no state information needs to be stored in the MMS. For example, assume that user's AoR is user@domain.com and the original Contact header inserted by the UA is: Contact: Salsano, et al. Expires August 27, 2007 [Page 13] Internet-Draft Solution for SIP-based vertical handover February 2007 where x.y.w.z is the current IP address of the MH. The MMS can rewrite the contact as follows: Contact: Where MMS_x.y.w.z is the IP address of the MMS, "TOKEN-" is a string that can be set by the MMS and "/" is used as escape character. When receiving an incoming request with the request URI corresponding to the above contact, the MMS will extract the original contact address user@x.y.w.z:5080 and will forward the message according to the information contained in its MMS mobility database. 4.2. MMID parameter in Via header field According to SIP specification, each node in the request delivery chain adds a Via header field with its own IP address when forwarding the request, in order to be included in the response delivery chain. We propose that the MMC adds an additional parameter to the Via header. This parameter is called MMID (Mobility Management IDentifier) and it carries the identifier of the MH. The MMID parameter is used as an indication that the originator of the request is a mobile host and it could change its IP address even during the transaction. Therefore the value of the MMID will be used as a key into the MMS mobility database, in order to find the current IP address to send the response. With this mechanism, the solution is able to deal in a seamless way with an handover performed during a session establishment. As an example, a Via header sent by the MMC to the MMS may look like the following: Via: SIP/2.0/UDP x.y.w.z;branch=z9h;MMID=user@domain.com Salsano, et al. Expires August 27, 2007 [Page 14] Internet-Draft Solution for SIP-based vertical handover February 2007 5. Handover: header When the MH needs to perform the handover during an active call, the MMC will send an "HandOver" (HO) REGISTER to the MMS. These message will perform the update of the MMS mobility database likewise the "Location Update" (LU) REGISTER, but in addition it will start the handover of the media flows belonging to the call. We insert a new header in the "HandOver" (HO) REGISTER, which includes the reference to the call to be handed over. The new header name will be "Handover:" and it will carry the Call-ID and the two tags, in a similar way to the Join header [2] or to the Replaces header [3]. In particular the parameters that carry the tags are called "req-tag" and "other-tag". Handover: sxdfv20000513@host.domain.com; req-tag=erfg; other-tag=wdfe The MMC requesting the handover will insert in the "req-tag" the tag corresponding to the MH in the INVITE transaction that originated the call (i.e. the From: tag if the call was originated by the MH or the To: tag if the call was originated by the CH). By comparing this information with the MMS call database (Figure 7), the MMS will be able to understand on which of the two legs of the call the handover has been requested. Salsano, et al. Expires August 27, 2007 [Page 15] Internet-Draft Solution for SIP-based vertical handover February 2007 6. Decoupling user level registration and terminal level registration One optional requirement discussed in [1] was to allow the decoupling of "user level" registration and "terminal level" mobility. As an example a user with AOR "sip:user@domain.com" should be allowed to use different terminals (i.e. Mobile Hosts supporting the handover solutions as well as normal SIP terminals). In this document we did not explicilty consider this requirement, we assumed that the Mobile Host is identified by an AOR "sip:user@domain.com" and therefore this AOR can be used for only one Mobile Host. We only mention here that this requirement can be addressed in straighforward way by introducing the concept of a Terminal identifier, distinct by the user AoR. The MMC can use this Terminal identifier inserting it in the MMID parameters in Via header. The terminal identifier will become the key to retrieve information related to the MH in the MMS, rather then using the user's AoR. Salsano, et al. Expires August 27, 2007 [Page 16] Internet-Draft Solution for SIP-based vertical handover February 2007 7. Conclusions This document presented a possible solution to the set of requirements discussed in [1]. The solution requires a new header field (named "Handover") in order to support the handover of media flows during an active call and a new parameters to the Via header field in order to allow the correct routing of SIP responses to the MH even during an handover. The standardization of these two elements would allow the open interoperability of MHs and MMS. We note that variants of the described solution have been successfully implemented in some testbeds by the authors (see for example [4], [5]). Salsano, et al. Expires August 27, 2007 [Page 17] Internet-Draft Solution for SIP-based vertical handover February 2007 8. Security considerations A detailed analysis of the security aspects related to the proposed solution needs to be performed in order to check that no new additional security issues will be introduced with respect to a SIP solution that handles mobility using the traditional end-to-end based approach. Salsano, et al. Expires August 27, 2007 [Page 18] Internet-Draft Solution for SIP-based vertical handover February 2007 9. Informative References [1] S. Niccolini et al., "Requirements for vertical handover of multimedia sessions using SIP", draft-niccolini-sipping-siphandover-01 , 2007. [2] R. Mahy et al., "The Session Initiation Protocol (SIP) "Join" Header", RFC 3911, October 2004. [3] R. Mahy et al., "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. [4] S. Salsano et al., "Architecture and testbed implementation of vertical handovers based on SIP Session Border Controllers", to appear in Wireless Personal Communications, Springer , 2007. [5] S. Salsano et al., "Seamless vertical handover of VoIP calls based on SIP Session Border Controllers", IEEE International Conference on Communications , 2006. Salsano, et al. Expires August 27, 2007 [Page 19] Internet-Draft Solution for SIP-based vertical handover February 2007 Appendix A. Acknowledgments The authors would like to thank Chiara Mingardi (Univ. of Padova/NEC) for her work on the implementation of the solution. Salsano, et al. Expires August 27, 2007 [Page 20] Internet-Draft Solution for SIP-based vertical handover February 2007 Authors' Addresses Stefano Salsano DIE, University of Rome "TorVergata" Via Politecnico, 1 Rome 00133 Italy Phone: +39 06 7259 7770 Email: stefano.salsano@uniroma2.it URI: http://netgroup.uniroma2.it/Stefano_Salsano Saverio Niccolini Network Laboratories, NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany Phone: +49 (0) 6221 43 42 118 Email: saverio.niccolini@netlab.nec.de URI: http://www.netlab.nec.de Luca Veltri DII, University of Parma Parco Area delle Scienze 181/A Parma 43100 Italy Phone: +39 0521 90 5768 Email: luca.veltri@unipr.it URI: http://www.tlc.unipr.it/veltri Andrea Polidoro DIE, University of Rome "TorVergata" Via Politecnico, 1 Rome 00133 Italy Phone: +39 06 7259 7773 Email: andrea.polidoro@uniroma2.it URI: http://netgroup.uniroma2.it Salsano, et al. Expires August 27, 2007 [Page 21] Internet-Draft Solution for SIP-based vertical handover February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Salsano, et al. Expires August 27, 2007 [Page 22]