[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02

SIPPING Working Group                                         S. Salsano
Internet-Draft                                 Univ. of Rome Tor Vergata
Intended status: Informational                              S. Niccolini
Expires: November 8, 2008                                            NEC
                                                               L. Veltri
                                                          Univ. of Parma
                                                             A. Polidoro
                                               Univ. of Rome Tor Vergata
                                                             May 7, 2008


   A solution for vertical handover of multimedia sessions using SIP
             draft-salsano-sipping-siphandover-solution-02

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 November 8, 2008.













Salsano, et al.         Expires November 8, 2008                [Page 1]


Internet-Draft  Solution for SIP-based vertical handover        May 2008


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-03).  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 . . . . . . . . . . . . . . . . . . . . . . . . .  4

   2.  Architecture of the proposed solution  . . . . . . . . . . . .  5

   3.  Signalling procedures  . . . . . . . . . . . . . . . . . . . .  7
     3.1.  Off-call mobility: Location Update (LU) Registration
           procedure  . . . . . . . . . . . . . . . . . . . . . . . .  7
       3.1.1.  Extensions to SIP specifications . . . . . . . . . . .  8
     3.2.  User Registration procedure  . . . . . . . . . . . . . . .  9
       3.2.1.  Extensions to SIP specifications . . . . . . . . . . .  9
     3.3.  Session Establishment procedure  . . . . . . . . . . . . . 10
       3.3.1.  Extensions to SIP specifications . . . . . . . . . . . 11
     3.4.  On-Call Mobility: Handover procedure . . . . . . . . . . . 11
       3.4.1.  Extensions to SIP specifications . . . . . . . . . . . 13

   4.  Routing of requests and responses  . . . . . . . . . . . . . . 14
     4.1.  Use of Contact header field  . . . . . . . . . . . . . . . 14
     4.2.  MMID parameter in Via header field . . . . . . . . . . . . 15

   5.  Handover: header . . . . . . . . . . . . . . . . . . . . . . . 16

   6.  Decoupling user level registration and terminal level
       registration . . . . . . . . . . . . . . . . . . . . . . . . . 17

   7.  Related work . . . . . . . . . . . . . . . . . . . . . . . . . 18

   8.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 19

   9.  Security considerations  . . . . . . . . . . . . . . . . . . . 20

   10. Informative References . . . . . . . . . . . . . . . . . . . . 21

   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 22

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23



Salsano, et al.         Expires November 8, 2008                [Page 2]


Internet-Draft  Solution for SIP-based vertical handover        May 2008


   Intellectual Property and Copyright Statements . . . . . . . . . . 24


















































Salsano, et al.         Expires November 8, 2008                [Page 3]


Internet-Draft  Solution for SIP-based vertical handover        May 2008


1.  Introduction

   A set of requirements for vertical handover using SIP has been
   discussed in [niccolini-sip-HO].  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 [niccolini-sip-HO]).  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 November 8, 2008                [Page 4]


Internet-Draft  Solution for SIP-based vertical handover        May 2008


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 November 8, 2008                [Page 5]


Internet-Draft  Solution for SIP-based vertical handover        May 2008


               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 November 8, 2008                [Page 6]


Internet-Draft  Solution for SIP-based vertical handover        May 2008


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 November 8, 2008                [Page 7]


Internet-Draft  Solution for SIP-based vertical handover        May 2008


     +-------+     +-------+     +-------+     +-------+
     |  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 November 8, 2008                [Page 8]


Internet-Draft  Solution for SIP-based vertical handover        May 2008


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 November 8, 2008                [Page 9]


Internet-Draft  Solution for SIP-based vertical handover        May 2008


   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 November 8, 2008               [Page 10]


Internet-Draft  Solution for SIP-based vertical handover        May 2008


   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:<sip:user1@domain.com>|160.80.81.23:4345 |160.80.81.23:4569 |
   |;tag=871                   |Remote:           |Remote:           |
   |To:<sip:user2@domain.com>  |151.2.82.21:3824  |87.3.235.212:3458 |
   |;tag=345                   |                  |                  |
   -------------------------------------------------------------------
   |Call-ID:xcv@1sfdsf.sdf     |Local:            |Local:            |
   |From:<sip:user3@domain.com>|160.80.81.23:8732 |160.80.81.23:7745 |
   |;tag=sgf                   |Remote:           |Remote:           |
   |To:<sip:user5@domain.com>  |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 November 8, 2008               [Page 11]


Internet-Draft  Solution for SIP-based vertical handover        May 2008


   (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 November 8, 2008               [Page 12]


Internet-Draft  Solution for SIP-based vertical handover        May 2008


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 November 8, 2008               [Page 13]


Internet-Draft  Solution for SIP-based vertical handover        May 2008


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: <sip:user@x.y.w.z:5080>




Salsano, et al.         Expires November 8, 2008               [Page 14]


Internet-Draft  Solution for SIP-based vertical handover        May 2008


   where x.y.w.z is the current IP address of the MH.  The MMS can
   rewrite the contact as follows:

   Contact: <sip:/TOKEN-user/AT-x.y.w.z/PORT-5080@MMS_x.y.w.z>

   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 November 8, 2008               [Page 15]


Internet-Draft  Solution for SIP-based vertical handover        May 2008


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 [refs.rfc3911] or to the Replaces
   header [refs.rfc3891].  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 November 8, 2008               [Page 16]


Internet-Draft  Solution for SIP-based vertical handover        May 2008


6.  Decoupling user level registration and terminal level registration

   One optional requirement discussed in [niccolini-sip-HO] 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 November 8, 2008               [Page 17]


Internet-Draft  Solution for SIP-based vertical handover        May 2008


7.  Related work

   The general problem of continuity of multimedia sessions is currently
   heavily discussed in 3GPP and it was agreed to be studied in
   timeframe of Release 8.  The handover that this document refers to is
   referred to as PS-PS session continuity in 3GPP terminology. 3GPP is
   considering the usage of an intermediate element in order to handle
   PS-PS multimedia session continuity as written in 3GPP Technical
   Report 23.893.  The usage of such intermediate element is also the
   core point of the solution presented in [Salsano08], [Salsano07].
   Also the scenarios currently under discussion are inline with the
   scenario depicted in Section 2 (please note that the scenarios
   discussed in 3GPP are currently a superset of the one depicted in
   this document).





































Salsano, et al.         Expires November 8, 2008               [Page 18]


Internet-Draft  Solution for SIP-based vertical handover        May 2008


8.  Conclusions

   This document presented a possible solution to the set of
   requirements discussed in [niccolini-sip-HO].  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 [Salsano08]).  The motivation of this work assumes even more
   relevance if 3GPP interest in this kind of solutions is taken into
   account.





































Salsano, et al.         Expires November 8, 2008               [Page 19]


Internet-Draft  Solution for SIP-based vertical handover        May 2008


9.  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 November 8, 2008               [Page 20]


Internet-Draft  Solution for SIP-based vertical handover        May 2008


10.  Informative References

   [niccolini-sip-HO]
              S. Niccolini et al., "Requirements for vertical handover
              of multimedia sessions using SIP",
              draft-niccolini-sipping-siphandover-03 , May 2008.

   [refs.rfc3261]
              J. Rosenberg et al., "SIP: Session Initiation Protocol",
              RFC 3261, June 2002.

   [refs.rfc3911]
              R. Mahy et al., "The Session Initiation Protocol (SIP)
              "Join" Header", RFC 3911, October 2004.

   [refs.rfc3891]
              R. Mahy et al., "The Session Initiation Protocol (SIP)
              "Replaces" Header", RFC 3891, September 2004.

   [Salsano08]
              S. Salsano et al., "SIP-based Mobility Management in Next
              Generation Networks", IEEE Wireless Communication ,
              April 2008.

   [Salsano07]
              S. Salsano et al., "Architecture and testbed
              implementation of vertical handovers based on SIP Session
              Border Controllers", Wireless Personal Communications,
              Springer , November 2007.






















Salsano, et al.         Expires November 8, 2008               [Page 21]


Internet-Draft  Solution for SIP-based vertical handover        May 2008


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 November 8, 2008               [Page 22]


Internet-Draft  Solution for SIP-based vertical handover        May 2008


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 November 8, 2008               [Page 23]


Internet-Draft  Solution for SIP-based vertical handover        May 2008


Full 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.

   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.











Salsano, et al.         Expires November 8, 2008               [Page 24]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/