SIP Session Mobility Project Status Henning Schulzrinne and Ron Shacham Columbia University...
-
date post
19-Dec-2015 -
Category
Documents
-
view
217 -
download
3
Transcript of SIP Session Mobility Project Status Henning Schulzrinne and Ron Shacham Columbia University...
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
CorrespondentNode (CN)
SIP UA
SLP UA
SIP SM
Local Devices
SLP SA SLP UA
SIP SM SIP UA
SLP DA
Mobile Node (MN)
SLPSIPRTP
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 UASLP SA
SLP DA
SrvReg/SrvAck
SrvRqst [sip-device room=102]/SrvRply [URI-list]
1
2
AttrRqst [email protected]/AttrRply [attr-list]
3
Available Devices:[email protected] 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
CorrespondentNode (CN)
[1] INVITE
[2] 200 OK
[4] 200 OK
[3] INVITE
[5] INVITE[Updated mediaParameters]
[6] 200 OK
SIPRTP
Session Transfer—Handoff ModeREFER sip:av@local_device.example.com SIP/2.0To: <sip:av@local_device.example.com>From: <sip:[email protected]>Refer-To:<sip:[email protected];audio;video?Replaces=”[email protected];
to-tag=bbb;from-tag=aaa>Referred-By: <sip:[email protected]>
[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
SLPDirectory
Agent
A V
[1] SrvReg sip:video@dev1….
[4] SrvReg sip:[email protected]
[2] SrvRqst/SrvRplysip:video@..
[3]
dev2.example.com dev1.example.com
[5] SrvRqst
[6] SrvRplysip:[email protected]….
[7] REFERTo: sip:av@dev2....
CN[8] INVITEReplaces:
Example—Multi-device system creation and transfer
SIP
RTP
SLPDirectory
Agent
A V
[1] SrvReg sip:video@dev1….
[4] SrvReg sip:[email protected]
dev2.example.com dev1.example.com
[5] SrvRqst
[6] SrvRplysip:[email protected]….
[7] REFERTo: sip:av@dev2....
CN[9] 200 OK [10] INVITE
Example—Multi-device system creation and transfer
[2] SrvRqst/SrvRplysip:video@..
SIP
RTP
SLPDirectory
Agent
A V
[1] SrvReg sip:video@dev1….
[4] SrvReg sip:[email protected]
dev2.example.com dev1.example.com
[5] SrvRqst
[6] SrvRplysip:[email protected]….
[7] REFERTo: sip:av@dev2....
CN[9] 200 OK [11] 200 OK
Example—Multi-device system creation and transfer
[2] SrvRqst/SrvRplysip:video@..
SIP
RTP
SLPDirectory
Agent
A V
[1] SrvReg sip:video@dev1….
[4] SrvReg sip:[email protected]
dev2.example.com dev1.example.com
[5] SrvRqst
[6] SrvRplysip:[email protected]….
[7] REFERTo: sip:av@dev2....
CN[12] ACK [13] ACK
Example—Multi-device system creation and transfer
[2] SrvRqst/SrvRplysip:video@..
SIP
RTP
SLPDirectory
Agent
A V
[1] SrvReg sip:video@dev1….
[4] SrvReg sip:[email protected]
dev2.example.com dev1.example.com
[5] SrvRqst
[6] SrvRplysip:[email protected]….
[7] REFERTo: sip:av@dev2....
CNSIP SIP
Audio
Video
Example—Multi-device system creation and transfer
[2] SrvRqst/SrvRplysip:video@..
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:av@local_device.example.com SIP/2.0To: <sip:av@local_device.example.com>From: <sip:[email protected]>Refer-To:<sip:[email protected];method=REFER
?Refer-To=“<sip:[email protected];audio;video?Replaces=”1@local_device.example.com;to-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
RTP
ACK
ACKACK[CN and camera SDP]
1
2
2
3 3
3
4
5
5
SESSIONTERMINATED
ORIGINAL SESSION
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