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




[5] SrvRqst



CN[9] 200 OK [10] INVITE



SIP

RTP

SLPDirectory

Agent

A V




[5] SrvRqst



CN[9] 200 OK [11] 200 OK



SIP

RTP

SLPDirectory

Agent

A V




[5] SrvRqst



CN[12] ACK [13] ACK



SIP

RTP

SLPDirectory

Agent

A V




[5] SrvRqst



CNSIP SIP

Audio

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

Date post:	19-Dec-2015
Category:	Documents
View:	217 times
Download:	3 times

SIP Session Mobility Project Status Henning Schulzrinne and Ron Shacham Columbia University...

Documents