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]