SIP Session Mobility Project Status

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
  ProtocolSLP) 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 users mobile device
  discovers DA (multicast), queries for devices
  available in a given location (Service Request),
  then queries for attributes of each (Attribute
  Request)

8
ExampleSLP Discovery of display
SLP SA
SrvRqst sip-device room102/ SrvRply URI-list
SLP UA
2
SrvReg/ SrvAck
1
AttrRqst display_at_example.com/ AttrRply attr-list
3
SLP DA
Available Devices display_at_example.com video
9
Session TransferOptions

• 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 TransferMobile Node Control Mode

• Third-party call-control usedmobile 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
ExampleMNC Transfer to two devices
SIP RTP
Correspondent Node (CN)
12
Session TransferHandoff Mode

• REFER sipav_at_local_device.example.com SIP/2.0
• To ltsipav_at_local_device.example.comgt
• From ltsipmn_at_example.comgt
• Refer-Toltsipcn_at_host1.macrosoft.comaudiovideo?
• Replaces1_at_mob.example.com
• to-tagbbbfrom-tagaaagt
• Referred-By ltsipmn_at_example.comgt
• 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 anotherwhen 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
ExampleMulti-device system creation and transfer
SLP Directory Agent
CN
A
V
dev2.example.com
dev1.example.com
15
ExampleMulti-device system creation and transfer
SLP Directory Agent
CN
A
V
dev2.example.com
dev1.example.com
16
ExampleMulti-device system creation and transfer
SLP Directory Agent
CN
A
V
9 200 OK
dev2.example.com
dev1.example.com
17
ExampleMulti-device system creation and transfer
SLP Directory Agent
CN
A
V
dev2.example.com
dev1.example.com
18
ExampleMulti-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 sipav_at_local_device.example.com SIP/2.0
• To ltsipav_at_local_device.example.comgt
• From ltsipmn_at_example.comgt
• Refer-Toltsipmn_at_host1.macrosoft.commethodREFER
• ?Refer-Toltsipcn_at_host1.macrosoft.comaudio
• video?Replaces1_at_local_device.example.comto-
  tagaaafrom-tagbbbgtgt

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
• Users 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
RTP
5
Transcoder
INVITE A and B SDP/ 200
1
camera
RTP
5
ACK
ACK CN and camera SDP
3
3
INVITE Transcoder B SDP/ 200 camera SDP
2
ORIGINAL SESSION
ORIGINAL SESSION
SESSION TERMINATED
4
MN
ACK
3
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 users 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 participants 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 privacy1require
  causes the proxy server to only route the call to
  a device on which only the user can view or hear
• SDP attributes
• arequired-privacyuser demands that the other
  device not make media available to anyone besides
  the user
• aprovided-privacyuser expresses that no other
  user has access to the media
• anorecord disallows recording of the session
• These may be updated in mid-call

28
Implementation

• Columbia Universitys 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