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

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

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

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

Architectural Overview 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

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

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)

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

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

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

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

Session Transfer—Handoff Mode REFER SIP/2.0 To: From: to-tag=bbb;from-tag=aaa> Referred-By: [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

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

SLP Directory Agent AV [1] SrvReg [4] SrvReg [2] SrvRqst/ SrvRply [3] dev2.example.comdev1.example.com [5] SrvRqst [6] SrvRply …. [7] REFER To: CN [8] INVITE Replaces: Example—Multi-device system creation and transfer SIP RTP

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

SLP Directory Agent AV [1] SrvReg [4] SrvReg dev2.example.comdev1.example.com [5] SrvRqst [6] SrvRply …. [7] REFER To: CN [9] 200 OK [11] 200 OK Example—Multi-device system creation and transfer [2] SrvRqst/ SrvRply SIP RTP

SLP Directory Agent AV [1] SrvReg [4] SrvReg dev2.example.comdev1.example.com [5] SrvRqst [6] SrvRply …. [7] REFER To: CN [12] ACK [13] ACK Example—Multi-device system creation and transfer [2] SrvRqst/ SrvRply SIP RTP

SLP Directory Agent AV [1] SrvReg [4] SrvReg dev2.example.comdev1.example.com [5] SrvRqst [6] SrvRply …. [7] REFER To: CN SIP Audio Video Example—Multi-device system creation and transfer [2] SrvRqst/ SrvRply SIP RTP

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/2.0 To: From: tag=aaa;from-tag=bbb”>”>

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

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

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+

Transcoding Example CN MN Transcoder A B INVITE [A and B SDP]/ 200 camera INVITE [Transcoder B SDP]/ 200 [camera SDP] INVITE [Transcoder A SDP]/ 200 [CN SDP] RTP ACK [CN and camera SDP] SESSION TERMINATED ORIGINAL SESSION

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

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

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

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

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

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

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

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

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