1 / 32

SIP Session Mobility Project Status

SIP Session Mobility Project Status. Henning Schulzrinne and Ron Shacham Columbia University Collaboration Meeting DoCoMo Eurolabs, Munich July 28, 2005. Project Overview.

venedict
Download Presentation

SIP Session Mobility Project Status

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. SIP Session Mobility Project Status Henning Schulzrinne and Ron Shacham Columbia University Collaboration Meeting DoCoMo Eurolabs, Munich July 28, 2005

  2. Project Overview • Motivation: Mobile devices continue to be limited in bandwidth, power and display capability. They can greatly benefit from the capabilities of other devices. • Project goal: A mobile user should be able to discover nearby devices, then easily and seamlessly include them in his ongoing multimedia session, with the use of only standard internet protocols • Elements: • Location-based Service Discovery • SIP signaling for session transfer

  3. Publications • Two current IETF Internet Drafts • draft-shacham-sipping-session-mobility-01 • draft-shacham-sip-media-privacy-00 • “The Virtual Device: Expanding Wireless Communication Services through Service Discovery and Session Mobility” to be presented at WiMob ’05 in Montreal • Technical Reports submitted at both Docomo Eurolabs and Columbia University

  4. Requirements • Allow users to automatically discover local devices • Allow users to transfer sessions from mobile to local device and later return them to their mobile device • Allow splitting of session onto multiple devices • Provide option of maintaining signaling on mobile device or complete handoff • Require no special capabilities of Correspondent Node • Support existing devices in environment, while developing enhanced devices • Make transfer invisible to the Correspondent Node • Use existing standards whenever possible

  5. Architectural Overview 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 Mobile Node (MN)

  6. Service Discovery • Architecture is not dependent on a single protocol • Low-power wireless protocols find close devices without knowing location • Query-based protocols (eg. Service Location Protocol—SLP) allow different granularities and other locations to be searched • Integration of both types of protocols may be useful • We use SLP in our publications and implementation • Location discovered in a variety of ways • Direct: Through Bluetooth, DHCP, GPS or other means, the device receives its own location • Device subscribes to user presence, presence updated when user walks into a room with his swipe card, the device receives location update and treats it as its own

  7. Service Discovery with SLP • SLP Directory Agent (DA) keeps track of devices based on location, media attributes • SLP Service Agent (SA), either co-located with SIP UA or on separate host, advertises the device and its attributes (Service Registration) • SLP User Agent (UA) on user’s mobile device discovers DA (multicast), queries for devices available in a given location (Service Request), then queries for attributes of each (Attribute Request)

  8. Example—SLP Discovery of display SLP SA SrvRqst [sip-device room=102]/ SrvRply [URI-list] SLP UA 2 1 SrvReg/ SrvAck 3 AttrRqst display@example.com/ AttrRply [attr-list] SLP DA Available Devices: display@example.com video

  9. Session Transfer—Options • Media that may be transferred • Real-time media (eg. audio, video) • Text messaging • Transfer modes • Mobile Node Control Mode • Session Handoff Mode • Whole or Split Session Transfer • Transfer in mid-session or on incoming call

  10. Session Transfer—Mobile Node Control Mode • Third-party call-control used—mobile node establishes a separate session each local device while retaining session with CN, setting up session media to be transmitted directly between them • Useful for retaining part of session media (eg. audio) on mobile device, while adding or transferring another media (eg. video) • Easy to support existing devices (they must only support INVITE request) • To transfer to multiple devices, MN simply establishes session with each one, updating session with CN accordingly

  11. [1] INVITE [5] INVITE [Updated media Parameters] [2] 200 OK [3] INVITE [6] 200 OK [4] 200 OK Example—MNC Transfer to two devices SIP RTP Correspondent Node (CN)

  12. Session Transfer—Handoff Mode REFER sip:av@local_device.example.com SIP/2.0 To: <sip:av@local_device.example.com> From: <sip:mn@example.com> Refer-To:<sip:cn@host1.macrosoft.com;audio;video? Replaces=”1@mob.example.com; to-tag=bbb;from-tag=aaa> Referred-By: <sip:mn@example.com> [S/MIME authentication body] • REFER message sent by MN to local device • Requests it to initiate a session with CN (“Refer-To”) which CN will regard as replacement of its current session with MN (“Replaces” header) • MN includes S/MIME body so that local device may authenticate with CN • Original session is torn down once new session is established • Completely hands off session to local device, no continued involvement by MN • Useful if battery runs low or wireless connectivity becomes spotty

  13. Handoff to multiple devices • Sending Multiple REFER messages does not provide seamless transfer, since they are not assocated together • Preferred Approach: Multi-device systems • One device controls another—when invited into a session, it acts as a Back-to-Back UA • Devices discover each other, create new systems according to all possible combinations in a given location • New systems are advertised using SLP • Two models • Dedicated B2B UA for all multi-device systems (necessary for existing devices) • Distributed model (preferred for enhanced software-driven devices

  14. [5] SrvRqst [6] SrvRply sip:av@dev2.example.com …. RTP [2] SrvRqst/ SrvRply sip:video@.. [1] SrvReg sip:video@dev1…. SIP [4] SrvReg sip:av@dev2.example.com [7] REFER To: sip:av@dev2.... [3] [8] INVITE Replaces: Example—Multi-device system creation and transfer SLP Directory Agent CN A V dev2.example.com dev1.example.com

  15. [5] SrvRqst [6] SrvRply sip:av@dev2.example.com …. RTP [2] SrvRqst/ SrvRply sip:video@.. [1] SrvReg sip:video@dev1…. SIP [4] SrvReg sip:av@dev2.example.com [7] REFER To: sip:av@dev2.... [9] 200 OK [10] INVITE Example—Multi-device system creation and transfer SLP Directory Agent CN A V dev2.example.com dev1.example.com

  16. [5] SrvRqst [6] SrvRply sip:av@dev2.example.com …. RTP [2] SrvRqst/ SrvRply sip:video@.. [1] SrvReg sip:video@dev1…. SIP [4] SrvReg sip:av@dev2.example.com [7] REFER To: sip:av@dev2.... [11] 200 OK Example—Multi-device system creation and transfer SLP Directory Agent CN A V [9] 200 OK dev2.example.com dev1.example.com

  17. [5] SrvRqst [6] SrvRply sip:av@dev2.example.com …. RTP [2] SrvRqst/ SrvRply sip:video@.. [1] SrvReg sip:video@dev1…. SIP [4] SrvReg sip:av@dev2.example.com [7] REFER To: sip:av@dev2.... [12] ACK [13] ACK Example—Multi-device system creation and transfer SLP Directory Agent CN A V dev2.example.com dev1.example.com

  18. [5] SrvRqst [6] SrvRply sip:av@dev2.example.com …. RTP [2] SrvRqst/ SrvRply sip:video@.. [1] SrvReg sip:video@dev1…. SIP [4] SrvReg sip:av@dev2.example.com [7] REFER To: sip:av@dev2.... Example—Multi-device system creation and transfer SLP Directory Agent CN A V SIP SIP Audio dev2.example.com dev1.example.com Video

  19. Retrieval of a handed-off session • Need to replace the current session as was done for original handoff • Correspondent Node will only replace if referred by current call participant (local device) • Local device may not have an interface for requestion this • Our solution: Send a REFER to local device that requests it to send it a REFER, referring it to the CN (“nested REFER”) • Once the MN receives the requested REFER, it will initiate a session with the CN, as the local device did above REFER sip:av@local_device.example.com SIP/2.0 To: <sip:av@local_device.example.com> From: <sip:mn@example.com> Refer-To:<sip:mn@host1.macrosoft.com;method=REFER ?Refer-To=“<sip:cn@host1.macrosoft.com;audio; video?Replaces=”1@local_device.example.com;to- tag=aaa;from-tag=bbb”>”>

  20. Incoming Call Transfer • Part of session is immediately transferred to another device upon receiving a call request • Examples • Use PC for video and desk IP phone for audio • User’s PDA discovers local video camera and projector, registers itself to the proxy as having video capabilities, then transfers video to the devices upon receiving video-call request • Two models • Invite local device before completing call setup with caller • Complete call setup, then immediately invite local device, update call

  21. Transfer of messaging • Three types of messaging • Real-time (RTP) text • SIP Message Request • Message Session Relay Protocol (MSRP) • Real-time text is identical to other real-time media • SIP Message requests may be forwarded to local devices (MNC mode) or are automatically transferred (SH mode) • MSRP is similar to real-time media, but uses TCP to transport messages • When relay agents are used, endpoints need not create TCP connections between them

  22. Reconciling Device Capabilities • When the local device and CN have no common codecs, session transfer must go through a transcoder (may be located through SLP) • MN maintains sessions with transcoder, CN, and local device, using 3pcc to create media sessions between them • Transcoder translates between CN and local device media • Other capabilities, such as bandwidth and display resolution, may be negotiated in SDP, using existing specifications for H.263+

  23. Transcoding Example A B 5 RTP Transcoder 1 INVITE [A and B SDP]/ 200 camera 5 RTP 3 ACK [CN and camera SDP] 3 ACK INVITE [Transcoder B SDP]/ 200 [camera SDP] 2 ORIGINAL SESSION ORIGINAL SESSION SESSION TERMINATED 4 3 ACK MN CN INVITE [Transcoder A SDP]/ 200 [CN SDP] 2

  24. Security/Privacy Considerations • Limiting Usage • Trait-based authentication to identify users as belonging to an authorized group • Preventing remote control of devices for surveillance • Authentication with a local token (available through Bluetooth or display) ensures that the user is present in the room • Visual indicator (eg. LED) when device is in use • Output devices may allow unwanted users to view video or text messages or hear audio

  25. Privacy of Output Devices • Concern not only for session mobility, but anywhere output devices are used, or recording may be done • Speakerphone • Video display • Specify in call messaging the privacy capabilities and privacy requirements • E.g. “My device will not let anyone hear what you say, and I require the same of yours” and “This conversation may not be recored” • Three levels of privacy • 1 – Only the device user has access to the media • 2 – Those in the device user’s organization (eg. company, circle of friends) have access • 3 – Anyone has access; the device is public • Though a user may disregard requests, the messages provide legal evidence • We have specified our model in an Internet Draft

  26. Applications • Have the proxy server only route the call to a device that has the right level of privacy • Disallow the other call participant from transferring the call to a public device, turning on his speakerphone, or recording the call • Force the other participant’s device to retrieve the session from a public device when the conversation becomes more private

  27. Protocol Extensions • SIP Caller Preferences • The header: “Accept-Contact: *;privacy=1;require” causes the proxy server to only route the call to a device on which only the user can view or hear • SDP attributes • “a=required-privacy:user” demands that the other device not make media available to anyone besides the user • “a=provided-privacy:user” expresses that no other user has access to the media • “a=norecord” disallows recording of the session • These may be updated in mid-call

  28. Implementation • Columbia University’s SIPC has been enhanced to provide the major elements described • Both Mobile Node Control Mode and Session Handoff Mode supported • Multi-Device Systems • Incoming Call Transfer

  29. Implementation The location of the device, after being updated, may be viewed

  30. Implementation • The user may choose to transfer the current session, or set the devices to which new sessions should be transferred • When transferring a session, the user may choose between transfer modes • In Mobile Node Control Mode, more than one device may be chosen for multiple media

  31. Implementation • In Session Handoff Mode, only a single device may be used for transfer • One of the devices in the room acts as a Multi-Device System. It supports video locally, and audio through one of the IP phones in the room

  32. Implementation The user may set devices to which incoming calls should be transferred

More Related