1. SIPPING - IETF 62 - Minneapolis (March 2005)1 Session Initiation Protocol (SIP) Session Mobility draft-shacham-sipping-session-mobility-00 Ron Shacham Henning Schulzrinne Srisakul Thakolsri Wolfgang Kellerer

2. SIPPING - IETF 62 - Minneapolis (March 2005)2 Motivation Session mobility = move active sessions from one (mobile) terminal to one or more (stationary) terminals audio on hardware phone, video on PC move conference to conference room facilities Move active sessions back to controlling device i.e., not just call transfer Service examples requires no new SIP protocol mechanisms Real system also requires discovery mechanism we use SLP

3. SIPPING - IETF 62 - Minneapolis (March 2005)3 Internet Correspondent Node (CN) SIP UA SLP UA SIP SM Local Devices SLP SA SLP UA SIP SM SIP UA SLP DA Mobile Node (MN) SLP SIP RTP SIP UA Transcoder

4. SIPPING - IETF 62 - Minneapolis (March 2005)4 Requirements Interoperability Only require CN to support RFCs and mature IDs Backward Compatibility Support local devices with basic functionality Flexibility Discover and reconcile device capability differences Seamlessness Limit disruption of media

5. SIPPING - IETF 62 - Minneapolis (March 2005)5 Session mobility options Transfer and retrieve an active session Retrieval not only of a session previously transferred Transfer all media to a single device or split over multiple devices Privacy: keep audio on handset, watch video on large screen Take advantage of benefits of different devices Includes division of full-duplex media into half-duplex streams

6. SIPPING - IETF 62 - Minneapolis (March 2005)6 Session mobility modes MN may retain control of or relinquish session signaling Mobile node control mode 3pcc (call control flow I) Session handoff mode REFER, “Replaces” header, Referred-By mechanism for security

7. SIPPING - IETF 62 - Minneapolis (March 2005)7 Session Handoff Mode Retrieval of session not controlled by MN Use “Nested REFER” for MN to retrieve Handoff to multiple devices Can’t currently bind multiple sessions at CN into one Devices discover each other and form “Multi-device systems” where B2B UA receives REFER and controls other devices

8. SIPPING - IETF 62 - Minneapolis (March 2005)8 REFER INVITE / 200 INVITE, Replaces/ 200 OK/ ACK ACK (CN SDP) RTP MDSM MN CN BYE/ 200 OK 1 2 2 2 4 4 4 3 5 5 5 5 6 7 SESSIONS TERMINATED ORIGINAL SESSION Handoff to a Multi-Device System

9. SIPPING - IETF 62 - Minneapolis (March 2005)9 Device Capability Differences Local device does not support any codec supported by CN Transfer carried out through transcoder using 3pcc Local device has higher bandwidth and may receive media at a higher framerate Local device includes such information in response, as is done for H.263+

10. SIPPING - IETF 62 - Minneapolis (March 2005)10 Open issues Can we avoid the B2BUA for SH mode? Integration of text sessions (MSRP)

11. SIPPING - IETF 62 - Minneapolis (March 2005)11 Service Discovery Architecture is not dependent on a single protocol Low-power wireless protocols find close devices without knowing location Query-based protocols (eg., SLP) allow larger areas and other locations to be queried Integration of both types of protocols could prove useful