1. IETF 72 – Dublin – SIPPING Requirements for vertical handover of multimedia sessions using SIP draft-niccolini-sipping-siphandover-04 Saverio Niccolini (NEC), S. Salsano (Univ. of Rome “Tor Vergata”), H. Izumikawa (KDDI Labs), R. Lillie (Motorola Labs), L. Veltri (Univ. of Parma), Y. Kishi (KDDI Labs)

2. IETF 72 – Dublin – SIPPING Introduction Terminal (“Mobile Host”, MH) Different network interfaces (e.g. WiFi, 3G, WiMax, etc.) connected to different Access Networks (AN) –possibly active at same time –each one with different IP addresses MH moves, “interface being used” may become not available (or suffering from bad performances, e.g. loss, delays) MH wants to keep running sessions active (or achieve better performances)

3. IETF 72 – Dublin – SIPPING Reference scenario IETF 72 – Dublin – SIPPING

4. Requirements (the basics) The handover solution should be as fast as possible –The goal is to provide a "seamless" handover with no perception from the user point of view The handover solution should not require a support in the different access network (no “network level mobility” e.g. MIP/MIPv6) –The access networks are only required to provide IP connectivity so that mobility support can be rapidly deployable No special support from Correspondent Hosts (CHs) –CHs should be basic User Agents (UAs) with basic SIP capabilities If this requirement is not fulfilled there is the need to change all SIP terminals to support the handovers of Mobile Host The handover solution should be compatible with NATted networks –NAT discovery should not increase the handover delay

5. IETF 72 – Dublin – SIPPING Why a new solution? There are solutions out there, why do you require a new one? –need to be faster service disruption as small as possible, bound to 0 –do not want to rely on network capabilities –do not want to rely on correspondent host capabilities –need to be NAT-independent More details in the additional requirements in the draft (here only 15 minutes) –details currently not addressed with available solutions

6. IETF 72 – Dublin – SIPPING References (running code?) Currently two available (independent) “solution” drafts –http://tools.ietf.org/html/draft-salsano-sipping-siphandover-solution-02http://tools.ietf.org/html/draft-salsano-sipping-siphandover-solution-02 –http://tools.ietf.org/html/draft-izumikawa-sipping-sipbicast-01http://tools.ietf.org/html/draft-izumikawa-sipping-sipbicast-01 The authors of the solution draft teamed up in the requirement draft to define a common set of requirements Solutions to this problem have been designed and implemented (At least) 3 (known) independent implementations –NEC Laboratories Europe, University of Rome “Tor Vergata”, KDDI Labs/Motorola –2 of them tested interoperability already in 2006 NEC Laboratories  University of Rome “Tor Vergata” Results of implementation and tests on operational networks documented –PIMRC conference, Sept. 2007 –IEEE Wireless Personal Communications, Nov. 2007 –IEEE Wireless Communications, Apr. 2008 –WCNC 2008, April 2008 –Trial with Italian operators

7. IETF 72 – Dublin – SIPPING Feedback received and addressed Differences from Session Mobility ID (draft-shacham-sipping-session- mobility)? –difference in focus: Shacham's I-D is addressing "service mobility", Niccolini and Izumikawa I-Ds are addressing "terminal mobility“ It is necessary to consider the solution to minimize the service disruption during handoff  explained in the draft Are there any advantages/merits to perform a terminal mobility using SIP? –ease of deployment, no support needed in all terminals/networks, different roles and utilizations  reflected in the requirements –do you want to wait for an ubiquitous deployment of mobile IPv6 to start using network level mobility keeping your IP address when you roam across networks? You are fixing some problems with an SBC!!! –solutions based on an intermediate element are promising without the need to rely on Correspondent Host capabilities  reflected in the requirements –anyway this draft does not hint any solutions, it just says current ones are not enough for the requirements What about media like IM, File Transfer using MSRP? –added additional requirement Decide which media stream to render when doing bicast –implementation issue out of the scope of SIP/SIPPING?

8. IETF 72 – Dublin – SIPPING Conclusions Do SIPPING folks agree on requirements? Is the work interesting for SIPPING? Should this be chartered in SIPPING WG and become a WG item?