Title: SIP Session Mobility Project Status
1SIP Session Mobility Project Status
- Henning Schulzrinne and Ron Shacham
- Columbia University
- Collaboration Meeting
- DoCoMo Eurolabs, Munich
- July 28, 2005
2Project 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
3Publications
- 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
4Requirements
- 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
5Architectural 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)
6Service 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
7Service 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)
8ExampleSLP 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
9Session 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
10Session 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
11ExampleMNC Transfer to two devices
SIP RTP
Correspondent Node (CN)
12Session 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
13Handoff 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
14ExampleMulti-device system creation and transfer
SLP Directory Agent
CN
A
V
dev2.example.com
dev1.example.com
15ExampleMulti-device system creation and transfer
SLP Directory Agent
CN
A
V
dev2.example.com
dev1.example.com
16ExampleMulti-device system creation and transfer
SLP Directory Agent
CN
A
V
9 200 OK
dev2.example.com
dev1.example.com
17ExampleMulti-device system creation and transfer
SLP Directory Agent
CN
A
V
dev2.example.com
dev1.example.com
18ExampleMulti-device system creation and transfer
SLP Directory Agent
CN
A
V
SIP
SIP
Audio
dev2.example.com
dev1.example.com
Video
19Retrieval 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
20Incoming 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
21Transfer 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
22Reconciling 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
23Transcoding 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
24Security/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
25Privacy 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
26Applications
- 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
27Protocol 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
28Implementation
- 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
29Implementation
The location of the device, after being updated,
may be viewed
30Implementation
- 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
31Implementation
- 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
32Implementation
The user may set devices to which incoming calls
should be transferred