1 / 11

Session Initiation Protocol (SIP) Session Mobility draft-shacham-sipping-session-mobility-00

Session Initiation Protocol (SIP) Session Mobility draft-shacham-sipping-session-mobility-00. Ron Shacham Henning Schulzrinne Srisakul Thakolsri Wolfgang Kellerer. Motivation. Session mobility = move active sessions from one (mobile) terminal to one or more (stationary) terminals

liza
Télécharger la présentation

Session Initiation Protocol (SIP) Session Mobility draft-shacham-sipping-session-mobility-00

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Session Initiation Protocol (SIP) Session Mobilitydraft-shacham-sipping-session-mobility-00 Ron Shacham Henning Schulzrinne Srisakul Thakolsri Wolfgang Kellerer 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 SIPPING - IETF 62 - Minneapolis (March 2005)

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

  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 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 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 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 SIPPING - IETF 62 - Minneapolis (March 2005)

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

  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+ SIPPING - IETF 62 - Minneapolis (March 2005)

  10. Open issues • Can we avoid the B2BUA for SH mode? • Integration of text sessions (MSRP) 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 SIPPING - IETF 62 - Minneapolis (March 2005)

More Related