SIPPING R. Shacham
Internet-Draft H. Schulzrinne
Expires: January 7, 2006 Columbia University
S. Thakolsri
W. Kellerer
DoCoMo Eurolabs
July 6, 2005
Session Initiation Protocol (SIP) Session Mobility
draft-shacham-sipping-session-mobility-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 7, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Session Mobility is the seamless transfer of media of an ongoing
communication session from one device to another. This document
describes the general methods and specifies the flows for providing
this service as part of the Session Initiation Protocol (SIP). The
basic steps involved in session mobility which are describe are
Shacham, et al. Expires January 7, 2006 [Page 1]
Internet-Draft SIP Session Mobility July 2005
service discovery to locate devices to use as transfer targets, for
which the Service Location Protocol (SLP) is used, session transfer,
and, sometimes, reconciliation of device capability differences. The
described session mobility methods include the possibility of
transferring any subset of the active media to one or more devices.
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Component overview . . . . . . . . . . . . . . . . . . . . . . 4
4. Service Location . . . . . . . . . . . . . . . . . . . . . . . 4
5. Session Mobility . . . . . . . . . . . . . . . . . . . . . . . 7
5.1 Options for Session Mobility . . . . . . . . . . . . . . . 7
5.1.1 Transfer and Retrieval . . . . . . . . . . . . . . . . 7
5.1.2 Whole and split transfer . . . . . . . . . . . . . . . 7
5.1.3 Transfer modes . . . . . . . . . . . . . . . . . . . . 7
5.1.4 Types of transfered media . . . . . . . . . . . . . . 8
5.2 Mobile Node Control Mode . . . . . . . . . . . . . . . . . 8
5.2.1 Transfer to a single local device . . . . . . . . . . 9
5.2.2 Transfer to multiple devices . . . . . . . . . . . . . 10
5.2.3 Retrieval of a Session . . . . . . . . . . . . . . . . 13
5.3 Session Handoff (SH) mode . . . . . . . . . . . . . . . . 14
5.3.1 Transfer to a single device . . . . . . . . . . . . . 14
5.3.2 Retrieval of a session . . . . . . . . . . . . . . . . 17
5.3.3 Transfer to multiple devices . . . . . . . . . . . . . 18
5.4 On Incoming Call . . . . . . . . . . . . . . . . . . . . . 20
6. Reconciling Device Capability Differences . . . . . . . . . . 21
6.1 Codec differences . . . . . . . . . . . . . . . . . . . . 21
6.2 Display resolution and bandwidth differences . . . . . . . 24
7. Session Termination . . . . . . . . . . . . . . . . . . . . . 24
8. Performance . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.1 Disruption of Media During Transfer . . . . . . . . . . . 25
8.1.1 Media Streams . . . . . . . . . . . . . . . . . . . . 25
8.1.2 MSRP Sessions . . . . . . . . . . . . . . . . . . . . 26
8.2 Total Transfer Latency . . . . . . . . . . . . . . . . . . 27
9. Security Considerations . . . . . . . . . . . . . . . . . . . 28
9.1 Authorization for using local devices . . . . . . . . . . 28
9.2 Privacy concerns for input devices . . . . . . . . . . . . 28
9.3 Privacy concerns for output devices . . . . . . . . . . . 29
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 29
11. Change History . . . . . . . . . . . . . . . . . . . . . . . 29
11.1 Changes from draft-shacham-sipping-session-mobility-00 . . 29
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . . 33
Shacham, et al. Expires January 7, 2006 [Page 2]
Internet-Draft SIP Session Mobility July 2005
1. Overview
As mobile devices improve, and include more enhanced capabilities for
IP-based multimedia communications, they will remain limited in terms
of bandwidth, display size and computational power. Stationary IP
multimedia endpoints, including hardware IP phones, videoconferencing
units, embedded devices and software phones allow more convenience of
use, but not mobility. The seamless transition between these devices
allow them to be used concurrently or interchangeably in mid-session,
combining the advantages of both into a single "virtual device."
Since the Session Initiation Protocol (SIP) [1] has been chosen by
the Third Generation Partnership Project (3GPP) as its standard for
session establishment in the Internet Multimedia Subsystem (IMS) [2]
and it is being deployed in hardware and software IP multimedia
clients, it is natural to specify an architecture to provide this
seamless, ubiquitous service using SIP. Such a SIP-based approach is
first given in [17], where two different methods are proposed, third-
party call control (3PCC) [3] and the REFER method [4]. This
document expands on this concept, defining a complete system for
session mobility. The aim of this system is to allow a Mobile Node
to discover available devices and to include them in an active
session. In order to accomplish this, two main components are
defined:
o Service Location - At all times, a user is aware of the devices
which are available in his local area, along with their
capabilities.
o Session Mobility - While in a session with a remote participant,
the user may transfer any subset of the active media services to
one or more devices.
As described above, this document describes Session Mobility for SIP.
Service location, on the other hand, does not depend on any
particular protocol. Many different models exist for providing this
service, and this document discusses the tradeoffs involved in
choosing between them. For our examples, however, we have decided to
use the Service Location Protocol (SLP) [5].
2. Requirements
This session mobility framework seeks to fulfill the following
requirements:
o REQ 1: Interoperability - No special capabilities should be
required of the remote participant in the call, as long as he is
using a SIP-compliant device or there is a PSTN gateway between
them. The device should be capable of handling a transfer by the
mobile user utilizing only features specified in Requests For
Comments (RFCs) and mature Internet Drafts.
Shacham, et al. Expires January 7, 2006 [Page 3]
Internet-Draft SIP Session Mobility July 2005
o REQ 2: Backward Compatibility - Both mobility-enhanced and basic
devices should be available as destinations for transfer.
Mobility-enhanced devices are those that are controlled by
software that is enhanced to support special call handling and
service discovery. Commercial IP phones and embedded devices are
basic since they cannot be enhanced to support such capabilities.
o REQ 3: Flexibility - Differences in device capabilities should be
reconciled. Transfer should be possible to devices that do not
support the codec being used in the session, and even to devices
that do not have a codec in common with the remote participant. A
transfer should also take into account device differences in
display resolution and bandwidth.
o REQ 4: Seamlessness - Session transfer should be as seamless as
possible. It should involve minimal disruption of the media flow
and should not appear to the remote participant as a new call.
3. Component overview
Session Mobility involves five basic components: The Correspondent
Node (CN), the Mobile Node (MN), the local devices, an SLP Directory
Agent (DA), and, optionally, a transcoder. The Correspondent Node
(CN) is a basic multimedia endpoint being used by a remote
participant and may be located anywhere. It may be a SIP UA, or a
POTS phone reachable through a PSTN gateway. The Mobile Node (MN) is
a mobile device, containing a SIP User Agent (UA) for standard SIP
call setup, as well as specialized SIP-handling capabilities for
session mobility and an SLP [5] User Agent (UA) for service querying.
The local devices are located in the user's local environment, for
discovery and use in his current session. They may be mobility-
enhanced or basic. Basic devices, such as IP phones, are SIP-
enabled, but have no other special capabilities. Mobility-enhanced
devices have SLP Service Agent capabilities for advertising their
services and session mobility handling. They also contain an SLP UA,
whose purpose will be explained in the discussion of multi-device
systems in Section 5.3.3. The SLP Directory Agent (DA) keeps track
of devices based on their location and capabilities. SLP will be
described in more detail in Section 4. SIP-based transcoding
services [7] are used, when necessary, to translate between media
streams, as described in Section 6.
4. Service Location
A mobile node must be able to discover suitable devices in its
vicinity. It is possible for devices in close proximity to be
discovered by direct methods such as Bluetooth without the use of
centralized servers. On the other hand, many centralized directory-
based service discovery protocols exist, such as the Service Location
Protocol (SLP). These protocols are general and are not based on
Shacham, et al. Expires January 7, 2006 [Page 4]
Internet-Draft SIP Session Mobility July 2005
physical locations of services, but they may be easily adapted by
adding location attributes to the service description [18]. They
have the advantage of allowing discovery of devices at different
location granularities, such as at the room or building level, and in
a location other than that of the device. They have the disadvantage
of requiring mobile devices to discover their location in order to
perform such queries. We have chosen to use a general protocol, SLP,
for device discovery in this document.
Many standard technologies may be used to update the mobile node of
its location for use in an SLP query. Indoors, the node can receive
its civic coordinates (ie., street address, room number, etc.) either
directly or indirectly. With direct methods, the location is sent to
the node itself by means such as a Bluetooth beacon. Indirect
methods use external location sources such as swipe cards to update
the user's location. The mobile node subscribes to the user's
location through the mechanism in [11] and receives the location
updates in the format standardized in [12]. Outdoors, a mobile
device may use direct methods such as the Global Positioning System
(GPS) [13] to update it on its geospatial coordinates. Online
databases can translate these to civic coordinates. The choice of
location technology is beyond the scope of this document.
Once the node has obtained its location, it uses SLP to query for
available devices in the vicinity that may be used as transfer
destinations. SLP identifies services by a "service type," a
"service URL," which can be any URL, and a set of attributes, defined
as name-value pairs. For the SIP devices in this framework, we
assume a a service type called "sip-device," whose SIP URL, such as
sip:audio_rm123@example.com or sip:audio@device1.example.com serves
as its service URL. The first URL mentioned is an address of record
that is used to connect to the device through the local proxy server,
while the second URL includes the name of the host on which the
service is provided, "device1.example.com," allowing a point-to-point
session to be established with the device. Either of these models
may be used, although the proxy model will likely make the device
available after an IP address change more quickly than in the point-
to-point model, where the DNS entry would take longer to be updated
unless dynamic DNS were used. The service description also includes
attributes specifying device characteristics (e.g., vendor, supported
media codec, display resolution) and location parameters, such as
street address and room number.
SLP defines Service Agents (SAs) which send descriptions of services
using the Service Registration (SrvReg) message, and User Agents (UA)
which query for services using the Service Request (SrvRqst) message.
SAs are co-located with SIP UAs on mobility-enhanced devices, while a
separate SA is available to send SrvReg messages on behalf of basic
Shacham, et al. Expires January 7, 2006 [Page 5]
Internet-Draft SIP Session Mobility July 2005
devices, which do not have integrated SLP SAs. SLP provides two
models for a UA to query for services. In the distributed model, the
UA sends requests through multicast and SAs reply directly with the
details of the service they provide. In the centralized model, a
Directory Agent (DA) is used, to which the SAs register and from
which the UAs request services. For our examples, we use the
centralized model, though either could be used. The SA registers its
service description to the DA with a service registration (SrvReg)
message that includes its service type, service URL and attribute-
value set. A UA queries for services by sending the service request
(SrvRqst) message, narrowing the query based on service type and
attribute values. It receives a reply (SrvRply) that contains a list
of URLs of services that match the query.
The Mobile Node includes an SLP UA that discovers available local
devices and displays them to the user, showing, for example, a map of
all devices in a building or a list of devices in a current room.
Once the MN receives its current location in some manner, its SLP UA
issues a SrvRqst message to the DA requesting all SIP devices, using
the location attributes to filter out those which are not in the
current room. A SrvRply message is sent to the mobile device with a
list of SIP URIs for all devices on the floor. A separate Attribute
Request (AttrRqst) is then sent for each URL to get the attributes of
the service, which include the room where the device is located. The
MN displays for the user the available devices in the room, and their
attributes. Figure 1 shows this protocol flow.
Device DA MN
|(1) SrvReg | |
|------------------------->| |
|(2) SrvRply | |
|<-------------------------| |
| | |
| | |
| |(3) SrvRqst |
| |<----------------------|
| |(4) SrvRply URL list |
| |---------------------->|
| |(5) AttrRqst URL1 |
| |<----------------------|
| |(6) AttrRply |
| |---------------------->|
| | ... |
| | |
Figure 1 SLP message flow for the device to register its service and
the MN to discover it, along with its attributes.
Shacham, et al. Expires January 7, 2006 [Page 6]
Internet-Draft SIP Session Mobility July 2005
5. Session Mobility
5.1 Options for Session Mobility
5.1.1 Transfer and Retrieval
Session mobility involves both transfer and retrieval of an active
session. Transfer means to move the session on the current device to
one or more other devices. Retrieval means to remotely transfer a
session currently on another device to the local device. This may
mean to return a session to the device on which it had originally
been before it was transferred to another device. For example, after
discovering a large video monitor, a user transfers the video output
stream to that device. When he walks away, he returns the stream to
his mobile device for continued communication. One may also retrieve
a session to a device that had not previously carried it. For
example, a participant in an audio call on his IP phone may leave his
office in the middle of the call and transfer the call to the mobile
device as he is running out the door.
5.1.2 Whole and split transfer
Session media may either be transferred completely to a single device
or be split across multiple devices. For instance, a user may only
wish to transfer the video of his session while maintaining the audio
on his PDA. Alternatively, he may find separate video and audio
devices and wish to transfer one media service to each. Furthermore,
even the two directions of a full-duplex session may be split across
devices. For example, a PDA's display may be too small for a good
view of the other call participant, so the user may transfer video
output to a projector and continue to use the PDA camera.
5.1.3 Transfer modes
Two different modes are possible for session transfer, Mobile Node
Control mode and Session Handoff mode.
5.1.3.1 Mobile Node Control mode
In Mobile Node Control mode, the Mobile Node uses third-party call
control [3]. It establishes a SIP session with each device used in
the transfer and updates its session with the CN, using the SDP
parameters to establish media sessions between the CN and each
device, which take the place of the current media session with the
CN. The shortcoming of this approach is that it requires the MN to
remain active to maintain the sessions.
Shacham, et al. Expires January 7, 2006 [Page 7]
Internet-Draft SIP Session Mobility July 2005
5.1.3.2 Session Handoff (SH) mode
A user may need to transfer a session completely because the battery
on his mobile device is running out. Alternatively, the user of a
stationary device who leaves the area and wishes to transfer the
session to his mobile device, he will not want the session to remain
on the stationary device when he is away, since it will allow others
to easily tamper with his call. In such case, Session Handoff mode,
which completely transfers the session signaling and media to another
device, is useful.
We have found Mobile Node Control mode to be more interoperable with
existing devices used on the CN's side. The remainder of this
section describes the transfer, retrieval and splitting of sessions
in each of the two session transfer modes.
5.1.4 Types of transfered media
A communication session may consist of a number of media types, and a
user should be able to transfer any of them to his device of choice.
This document considers audio, video and messaging. Audio and video
are carried by RTP and negotiated in the SDP body of the SIP requests
and responses. Three different methods exist for carrying messaging
of text, and possibly other MIME types, that are suitable for SIP
endpoints. RTP may be used to transport text payloads based on [22].
Any examples given for audio and video will work identically for
text, as only the payloads differ. For the transfer of whole
messages, either the SIP MESSAGE method [23] or the Message Session
Relay Protocol (MSRP) [20] may be used. MESSAGE is used to send
individual page-mode messages. The messages are not associated as
part of a session, and no negotiation is done to establish a session.
Typically, a SIP UA will allow the user to send MESSAGE requests
during an established dialog, and they are sent to the same contact
address as all signaling messages are sent in mid-session. These
messages, therefore, are forwarded by the controlling node to the
appropriate device. MSRP, on the other hand, is based on sessions
that are established like the real-time media sessions previously
described. As such, transfering them is similar to transfering other
media sessions. However, this document will point out where special
handling is necessary for these types of sessions.
5.2 Mobile Node Control Mode
Shacham, et al. Expires January 7, 2006 [Page 8]
Internet-Draft SIP Session Mobility July 2005
5.2.1 Transfer to a single local device
AN MN CN
|(1) INVITE CN params | |
|<---------------------| RTP |
|............................................>|
|(2) 200 AN params | |
|--------------------->| |
| |(3) INVITE AN params |
| |--------------------->|
| RTP | |
|<............................................|
| |(4) 200 OK |
| |<---------------------|
| |(5) ACK |
| |--------------------->|
|(6) ACK | |
|<---------------------| |
| | |
| | |
Figure 2 : Mobile Node Control mode flow for transfer to a single
device.
Figure 2 shows the message flow for transfering a session to a single
device. It follows Third Party Call Control Flow I specified in [3]
which is recommended as long as the endpoints will immediately
answer. However, the SDP content here differs somewhat from that
flow. Namely, message (1) includes the SDP parameters of the CN,
currently being used in the session. Although these may change
following the INVITE message sent to the CN (3), there is a
performance advantage to initially sending the CN parameters.
Following the reinvitation of the CN (3), the CN will redirect its
media streams to the address and port given for the AN in message
(3). If the AN receives an empty SDP body in message (1), it will be
unaware of the new sender, and will not play the content of the RTP
packets with the new SSRC, until it receives message (6). During
this lapse, not only will media not be played on any device, but the
media segment sent will be lost completely.
The MN sends a SIP INVITE request to the local device used for the
transfer, requesting that a new session be established. The local
device's response contains an SDP body that includes the address and
ports it will use for any media. The MN updates the session with the
CN by sending an INVITE message (re-INVITE) containing the local
device's media parameters in the SDP body, as follows:
Shacham, et al. Expires January 7, 2006 [Page 9]
Internet-Draft SIP Session Mobility July 2005
v=0
c= IN IP4 av_device.example.com
m=audio 4400 RTP/AVP 0
m=video 5400 RTP/AVP 34
The CN sends a response, and includes, in its body, the media
parameters that it will use, which may or may not be the same as the
ones used in the existing session. The MN sends an ACK message to
the local device, which includes these parameters in the body if they
have changed. The MN has established separate SIP session with the
CN and the local device, but a media flow has been established
between the CN and the local device.
5.2.2 Transfer to multiple devices
In order to split the session across multiple devices, the MN
establishes a new session with each local device through a separate
INVITE request and updates the existing session with the CN with an
SDP body that combines the media parameters it receives in their
responses. For instance, in order to transfer an audio and video
call to two devices, it creates an audio session with one device and
a video session with another, and combines the SDP bodies from both
to reINVITE the CN, as follows:
v=0
m=audio 4400 RTP/AVP 0
c= IN IP4 audio_dev.example.com
m=video 5400 RTP/AVP 34
c= IN IP4 video_dev.example.com
Shacham, et al. Expires January 7, 2006 [Page 10]
Internet-Draft SIP Session Mobility July 2005
VN AN MN CN
| |(1) INVITE CN params| |
| |<-------------------| RTP Audio |
| |...........................................>|
| |(2) 200 AN params | |
| |------------------->| |
| |(3) INVITE CN params| |
|<---------------------------------------| RTP Video |
|...............................................................>|
| |(4) 200 VN params | |
| |------------------->| |
| | |(5) INVITE AN/VN params|
| | |---------------------->|
| | RTP Audio | |
| RTP Video |<...........................................|
|<...............................................................|
| | |(6) 200 OK |
| | |<----------------------|
| | |(7) ACK |
| | |---------------------->|
| |(8) ACK | |
| |<-------------------| |
| |(9) ACK | |
|<---------------------------------------| |
| | | |
| | | |
Figure 3 : Mobile Node Control mode flow for transfer to multiple
devices.
Splitting a full-duplex media service such as video across an input
and an output device is a simple extension of this approach. The
signaling is identical to that of Figure 3, with the audio and video
devices replaced by a video output and a video input device. The
SDP, however, is slightly different. The MN invites the video
display and camera into two different unidirectional media sessions,
using the "sendonly" and "recvonly" parameters, respectively. Using
their responses, which contain the opposite parameter, the MN
constructs the following SDP body to re-INVITE the CN:
m=video 8900 RTP/AVP 34
a=recvonly
c=IN IP4 display.example.com
m=video 8800 RTP/AVP 34
a=sendonly
Shacham, et al. Expires January 7, 2006 [Page 11]
Internet-Draft SIP Session Mobility July 2005
c=IN IP4 camera.example.com
During the course of the session, the CN may send a MESSAGE request
to the MN containing text conversation from the remote user. If the
mobile user wishes to have such messages displayed on a device other
than the MN, the request is simply forwarded to that device. The
forwarded message should be composed as though it were any other
message from the MN to the local device, and include the body of the
received message. The local device will send its response to the MN,
who will then send a response to the CN.
The message sequence for transfering an MSRP message session using
MNC mode is identical to that used for audio or video, in Figure 2,
although the contents of the messages differ. To simplify the
example, we assume that an MSRP session, with no other media, is
being transfered to a local messaging device, MSGN. An empty INVITE
request (1) is sent to the local messaging node, MSGN, as follows:
INVITE sip:msgn@msgn.example.com SIP/2.0
To: <sip:msgn@msgn.example.com>
From: <sip:mn@mn.example.com>;tag=786
Call-ID: 893rty@mn.example.com
Content-Type: application/sdp
The messaging node responds with all of its media capabilities, as
follows (2):
SIP/2.0 200 OK
To: <sip:msgn@msgn.example.com>;tag=087js
From: <sip:mn@mn.example.com>;tag=786
Call-ID: 893rty@mn.example.com
Content-Type: application/sdp
v=0
c=IN IP4 msgn.example.com
m=message 12000 msrp/tcp *
a=accept-types:text/plain
a=path:msrp://msgn.example.com:12000/kjhd37s2s2;tcp
The same request is then sent by the MN to the CN, but containing the
path given in the MSGN response above (3). The CN responds with its
own path(4). The MN then includes this in the ACK that it sends to
the MSGN (6).
MSRP sessions are carried over a reliable connection, using TCP or
Shacham, et al. Expires January 7, 2006 [Page 12]
Internet-Draft SIP Session Mobility July 2005
TLS. Therefore, unlike in the case of real-time media, this
connection must be established. According to the current MSRP draft,
the initiator of a message session, known as the "offerer", must be
the active endpoint, opening the TCP connection between them. In
this transfer scenario, the offerer is the MN, who is on neither end
of the desired TCP connection. As such, neither end point will
establish the connection. Therefore, one of two solutions must be
used. A negotiation mechanism may be added to allow the active
endpoint role to be assigned during MSRP session setup. The
aforementioned draft leaves open the possiblity of negotiating this
role, but has left out previously specified methods because of
complexity. Alternatively, the CN and the local device may use MSRP
relays [21], so that no direct connection must be established between
them. When each new endpoint receives the INVITE request from the
MN, it will create a TLS connection with one of its preconfigured
relays if such a connection does not yet exist (the CN will already
have one because of its session with the MN), authenticate, and
receive the path of the relay. In its response to the MN, it will
include the entire path that must be traversed to it, including its
relay, in the path attribute. For instance, the response from the
MSGN will look as follows:
SIP/2.0 200 OK
To: <sip:msgn@msgn.example.com>;tag=087js
From: <sip:mn@mn.example.com>;tag=786
Call-ID: 893rty@mn.example.com
Content-Type: application/sdp
v=0
c=IN IP4 msgn.example.com
m=message 12000 msrp/tcp *
a=accept-types:text/plain
a=path:msrp://relayA.example.com:12000/kjhd37s2s2;tcp \
path:msrp://msgn.example.com:12000/kjhd37s2s2;tcp
Since the CN and the local device each establish a TLS connection
with their relay, as they would for any session, and the relays will
establish a connection between them when a subsequent MSRP message is
sent, neither party needs to establish any special connection. The
existing protocol may therefore be used for session transfer.
5.2.3 Retrieval of a Session
The MN may later retrieve the session by sending a re-INVITE to the
CN with its own media parameters, causing the media streams to
return. It then sends a BYE message to each local device to
terminate the session.
Shacham, et al. Expires January 7, 2006 [Page 13]
Internet-Draft SIP Session Mobility July 2005
5.3 Session Handoff (SH) mode
5.3.1 Transfer to a single device
Session Handoff mode uses the SIP REFER method [4]. This message is
a request sent by a "referer" to a "referee," which "refers" it to
another URI, the "refer target," which may be a SIP URI to be
contacted with an INVITE or other request, or a non-SIP URI, such as
a web page. This URI is specified in the "Refer-To" header. The
"Referred-By" [14] header is used to give the referer's identity
which is sent to the refer target for authorization. Essential
headers from this message may also be encrypted and sent in the
message body as S/MIME to authenticate the REFER request. Figure 4
shows the flow for transferring a session.
AN MN CN
|(1) REFER | |
|<----------------------------| |
|(2) 202 Accepted | |
|---------------------------->| |
|(3) INVITE, Replaces | |
|-------------------------------------------------->|
| RTP |
|<..................................................|
|(4) 200 OK | |
|<--------------------------------------------------|
| RTP |
|..................................................>|
|(5) ACK | |
|-------------------------------------------------->|
|(6) NOTIFY | |
|---------------------------->| |
|(7) 200 OK | |
|<----------------------------| |
| |(6) BYE |
| |-------------------->|
| |(7) 200 OK |
| |<--------------------|
| | |
| | |
Figure 4 : Session Handoff mode flow for transfer to a single device.
The MN sends the following REFER request (1) to a local device:
Shacham, et al. Expires January 7, 2006 [Page 14]
Internet-Draft SIP Session Mobility July 2005
REFER sip:av@local_device.example.com SIP/2.0
To: <sip:av@local_device.example.com>
From: <sip:mn@example.com>
Refer-To:<sip:cn@host1.macrosoft.com;audio;video?
Replaces="1@mob.example.com;
to-tag=bbb;from-tag=aaa">
Referred-By: <sip:mn@example.com>
[S/MIME authentication body]
This message refers the local device to invite the refer target, the
CN, into a session. The "audio" and "video" tokens following the URI
are callee capabilities. Here they are used to inform the referee
that it should initiate an audio and video session with the CN. Also
included is the "Replaces" header which is to be included in the
INVITE request. The "Replaces" header identifies an existing session
that should be replaced by the new session. Here, the local device
requests that the CN replace its current session with the MN with the
new session. According to [15], the CN should only accept a request
to replace a session by certain authorized groups of users. One such
type of user is the current participant in the session. The MN may,
therefore, refer the local device to replace its current session with
the CN. However, it must provide authentication by encrypting
several headers from the original REFER request in an S/MIME body
that it sends in the REFER. The local device sends this body to the
CN. This keeps a malicious user from indiscriminately replacing
another user's session. Once the local device receives the REFER
request, it sends an INVITE request to the CN, and a normal session
setup ensues. The CN then tears down its session with the MN.
Shacham, et al. Expires January 7, 2006 [Page 15]
Internet-Draft SIP Session Mobility July 2005
AN MN CN
|(1) REFER | |
|<----------------------------| |
|(2) 202 Accepted | |
|---------------------------->| |
|(3) REFER | |
|---------------------------->| |
| |(4) INVITE, Replaces |
| |-------------------->|
| | RTP |
| |<....................|
| |(5) 200 OK |
| |<--------------------|
| | RTP |
| |....................>|
| |(6) ACK |
| |-------------------->|
| (7) BYE | |
|<--------------------------------------------------|
| (8) 200 OK | |
|-------------------------------------------------->|
| | |
| | |
Figure 5 : Session Handoff mode flow for session retrieval.
Once the local device has established a session with the CN, it sends
a NOTIFY request to the MN, as specified in [4]. This NOTIFY
contains the "To" (including tag), "From" (including tag) and
"Call-ID" header fields from the established session to allow the MN
to subsequently retrieve the session, as described in Section 5.3.2.
Once a session is transfered, the destination for MESSAGE requests
moves automatically. Since a new session is established between the
CN and the local device, any subsequent MESSAGE requests will be sent
to that device.
The transfer flow described above for media sessions may also be used
to transfer an MSRP session. The local device will initiate an MSRP
session in message (4), along with the other sessions. The REFER
request (1) must indicate that an MSRP session should be established
using callee capabilities in the "Refer-To" header field, as it does
for audio and video. Such a media field tag, "message" has already
been defined [27]. Once the local device receives the REFER request,
it initiates an MSRP session with the CN. As the initiator, it will
establish a TCP connection in order to carry the session, as
specified in [20] or will set up the session through its relay if
Shacham, et al. Expires January 7, 2006 [Page 16]
Internet-Draft SIP Session Mobility July 2005
configured to do so.
5.3.2 Retrieval of a session
Figure 5 shows the flow for retrieval by the MN of a session
currently on a local device. In order for a device to retrieve a
session in Session Handoff mode, it must initiate a session with the
CN that replaces the CN's existing session. The following message is
sent by the MN to the CN (4):
INVITE sip:cn@host1.macrosoft.com SIP/2.0
To: <sip:cn@host1.macrosoft.com>
From: <sip:mn@example.com>
Replaces: 1@local_device.example.com;to-tag=aaa;from-tag=bbb
Referred-By: <sip:av@local_device.example.com>
[S/MIME authentication body]
The MN needs to be referred by the local device and include its URI
in the "Referred-By" header, in addition to including an S/MIME
authentication body from the local device, in order to be permitted
to replace the session. Therefore, the MN must receive a REFER
request from the local device referring it to send this INVITE
request. The user could use the user interface of the local device
to send this REFER message. However, such an interface may not be
available, and the user may also wish to execute the transfer while
running out of the office with mobile device in hand. In order to
prompt the REFER from the Mobile Node, a "nested REFER," [14] a REFER
request for another REFER, is sent. In this case, the second REFER
is sent back to the Mobile Node. That REFER must specify that the
"Replaces" header be included in the target INVITE request. The
REFER request from the local device to the MN (3) is composed as
follows:
REFER sip:mn@example.com SIP/2.0
To: <sip:mn@ example.com>
From: <sip:av@local_device.example.com>
Refer-To: <sip:cn@host1.macrosoft.com;audio;video?
Replaces="1@local_device.example.com;to-tag=aaa;
from-tag=bbb">
Referred-By: <sip:av@local_device.example.com>
[S/MIME authentication body]
A header field is included in the "Refer-To" URI to specify the value
of the "Replaces" header in the target INVITE request. In order to
Shacham, et al. Expires January 7, 2006 [Page 17]
Internet-Draft SIP Session Mobility July 2005
have this message sent to it, the MN must send the following REFER
request (1):
REFER sip:av@local_device.example.com SIP/2.0
To: <sip:av@local_device.example.com>
From: <sip:mn@example.com>
Refer-To:<sip:mn@host1.macrosoft.com;method=REFER
?Refer-To="<sip:cn@host1.macrosoft.com;audio;
video?Replaces=%221@local_device.example.com;
to-tag=aaa;from-tag=bbb%22>">
The "Refer-To" header specifies the MN as the refer target and that
the referral be in the form of a REFER request. The header field
specifies that the REFER request should contain a "Refer-To" header
containing the URI of the CN. That URI, itself, should contain the
"audio" and "video" callee capabilities that will tell the MN to
initiate an audio and video call, and a header field specifying that
the ultimate INVITE request should contain a "Replaces" header. If
the MN had previously transfered the session to the local device, it
would have received these in the NOTIFY sent by the local device
following the establishment of the session. If, on the other hand,
the MN is retrieving a session it had not previously held, as
mentioned above in Section 5.1.1, it must get these parameters by
subscribing to the Dialog Event Package [26] of the local device.
Such a subscription would only be granted, for instance, to the owner
of the original device that carried the session. Even when these
parameters are provided in the "Replaces" header, the local device
must not accept the REFER request from anybody except for the
original participant in the session or the owner of the device. The
MN receives the REFER request from the local device, sends the INVITE
request to the CN, which accepts it and, once the session is
established, terminates its session with the local device.
5.3.3 Transfer to multiple devices
Splitting a session in SH mode requires multiple media sessions to be
established between the CN and local devices, without the MN
controlling the signaling. This could be done by sending multiple
REFER requests to the local devices, referring each to the CN. The
disadvantage of this method is that there is currently no standard
way to associate multiple sessions as part of a single call in SIP.
Therefore, each session between the CN and a local device will be
treated as a separate call. They may occupy different parts of the
user interface, their media may not be available simultaneously, and
they may have to be terminated separately. This certainly does not
fulfill the requirement of seamlessness.
Shacham, et al. Expires January 7, 2006 [Page 18]
Internet-Draft SIP Session Mobility July 2005
This document describes the use of multi-device systems to overcome
this problem. A local device's SLP UA queries for other devices and
joins with them to create a "virtual device." It then chooses a
single SIP URI to address it, such as sip:a_v@dev.example.com, and
registers the service in SLP. We refer to the controlling device as
the Multi-Device System Manager (MDSM). In a system that includes at
least one mobility-enhanced device, it may act as the MDSM. In a
system consisting entirely of basic devices, either a dedicated host
or another local device from outside of the system must act as MDSM.
Once the MN discovers this system, it may hand off a session by
sending a REFER request to the MDSM URI. When the device receives
the request sent to this URI, it uses third-party call control to set
up media sessions between the CN and each device in the system
(including itself). Specifically, it invites each local device into
a separate session, and uses their media parameters to invite the CN
into a session. Figure 6 shows the transfer of a session to a multi-
device system. The Audio Node (AN) has previously discovered the
Video Node (VN), and created a multi-device system. The REFER
request sent to sip:a_v@an.example.com prompts the Audio Node to
invite the Video Node into a session to ascertain its SDP, and then
to invite the CN into a session using its own SDP and that of the
Video Node.
Shacham, et al. Expires January 7, 2006 [Page 19]
Internet-Draft SIP Session Mobility July 2005
VN AN MN CN
| |(1) REFER | |
| |<--------------------| |
| |(2) 202 Trying | |
| (3) INVITE No SDP |-------------------->| |
|<-------------------| | |
| (4) 200 OK VN SDP | | |
|------------------->| | |
| |(5) INVITE AN/VN SDP, Replaces |
| |--------------------------------->|
| | RTP Audio |
| |<.................................|
| | RTP Video |
|<......................................................|
| |(6) 200 OK CN SDP |
| |<---------------------------------|
| | RTP Audio |
| (7) ACK CN SDP |.................................>|
|<-------------------| | |
| RTP Video | | |
|......................................................>|
| |(8) ACK | |
| |--------------------------------->|
| | |(9) BYE |
| | |----------->|
| | |(10) 200 OK |
| | |<-----------|
| | | |
| | | |
Figure 6 : Session handoff to a multi-device system.
5.4 On Incoming Call
The examples presented above have involved an established session
which a user transfers to one or more devices. Another scenario
would be for an incoming call to be immediately distributed between
multiple devices when the user accepts the call. In such a case, the
initial session would not yet be established when the transfer takes
place.
The transfer could be carried out in either of the transfer modes.
However, complete handoff to a separate device, which is done in
Session Handoff mode, could be achieved through existing means, such
as redirection. Mobile Node Control mode would be useful in a case
where the user wishes to automatically include an additional device
in a call. For instance, a user with a desk IP phone and a PC with a
video camera could join the two into a single logical device. The
Shacham, et al. Expires January 7, 2006 [Page 20]
Internet-Draft SIP Session Mobility July 2005
SIP UA on the PC would, for any incoming call, send an INVITE request
to the desk phone, setting the display name in the From header to
"Bob Jones (audio portion)", for instance, so that the user can
identify the caller on the phone. The user could then either accept
or reject, as he would with a call coming directly to the phone. If
he accepts, the PC UA, acting as the controller, would respond to the
caller with its video parameters and the phone's audio parameters in
the SDP body. The final ACK from the caller would then complete the
session establishment.
If the desk phone is registered as a contact for the user, it would
also ring in response to the direct call being proxied there, in
addition to the INVITE sent by the controller, causing confusion to
the user. The use of caller preferences can solve this problem, as
the caller would indicate that the call should preferentially be
proxied to devices with audio and video capabilities. It is likely
that the caller would use caller preferences in any case, if they
were available to him, to avoid the callee unknowingly picking up the
IP phone when he has a video-capable device available. However,
since caller preferences are not yet widely supported on commercial
devices, the callee would alone need to ensure the proper routing of
the call. The desired behavior could be achieved by not registering
the desk phone and having all calls, whether video or audio-only go
through the PC. The PC would register two contacts, one representing
itself and the phone as a single audio-video device, and another
representing only the phone, but using the PC's host address. A
third solution would be to register both devices, give a higher
priority to the PC UA, and use CPL (the "proxy" node) [29] to specify
that routing should be done to the set of user devices in sequence,
rather than in parallel. Since all calls would first be proxied to
the PC as long as it were online, it would need to redirect any
request that included audio in its SDP.
6. Reconciling Device Capability Differences
Session mobility sometimes involves the transfer of a session between
devices with differing capabilities. For example, the codec being
used in the current session may not be available on the new device.
Furthermore, that device may not support any codec that is supported
by the CN. In addition to codecs, devices may have different
resolutions or bandwidth limitations which must be taken into account
when carrying out session transfer.
6.1 Codec differences
Before executing a session transfer, the device must check the
capabilities of the CN and the new device. These may be found
through either the SIP OPTIONS method, used in SIP to query a
Shacham, et al. Expires January 7, 2006 [Page 21]
Internet-Draft SIP Session Mobility July 2005
device's media capabilities, or may be included as SLP service
attributes. Since the OPTIONS method is standard, it should be used
to query the CN, while SLP should be used to get the media
capabilities of local devices, since it is already being used for
them.
If the CN and the local device are found to have a common codec, the
transfer should be carried out so that it becomes the codec used in
the new media session. In Mobile Node Control Mode, the flow is
identical, but the SDP bodies include the desired codec. In Session
Handoff Mode, the MN sends a REFER request to the local device and
allows it to negotiate a common codec with the CN.
If the CN and the local device are found to have a common codec, the
transfer should be carried out so that it becomes the codec used in
the new media session. In Mobile Node Control Mode, the flow is
identical, but the SDP bodies include the desired codec. In Session
Handoff Mode, the MN sends a REFER request to the local device and
allows it to negotiate a common codec with the CN.
If a common codec does not exist, the MN must execute the transfer
through an intermediate transcoding service, which need not be
geographically local. Rather than establishing a direct media
session between the CN and the local device, separate sessions are
established between the transcoder and each of them, with the
transcoder translating between the streams. The Mobile Node may
discover available transcoders through SLP.
Current efforts [7] use third-party call control for transcoding.
The standard case involves a controller, party A, that initiates a
media session with party B through a transcoder. The controller
invites the transcoder into a session and provides the media
parameters of itself and B. The transcoder responds with a "200 OK"
that includes its own media parameters, namely the ports on which it
will receive each stream. The controller then establishes a separate
session with B, in which it gives it the address and port of the
transcoder as the destination of its media. It also establishes its
own media session with the transcoder. Once both sessions are
established, two media streams have been established through the
transcoder.
Shacham, et al. Expires January 7, 2006 [Page 22]
Internet-Draft SIP Session Mobility July 2005
AN Transcoder MN CN
(codec A) (codec B)
| |(1) INVITE AN, CN params | |
| |<---------------------------| |
| |(2) 200 A, B params | |
| |--------------------------->| |
| |(3) INVITE A params | |
|<---------------------------------------| |
| RTP | | |
|..........>| | |
| |(4) 200 AN params | |
|--------------------------------------->| |
| |(5) ACK | |
|<---------------------------------------| |
| | |(5) INVITE B params |
| | |---------------------->|
| | | RTP |
| |<...................................................|
| | |(6) 200 OK CN params |
| | |<----------------------|
| | |(7) ACK |
| | |---------------------->|
| |(8) ACK AN, CN params | |
| RTP |<---------------------------| |
|<..........| | RTP |
| |...................................................>|
| | | |
Figure 7 : Transfer of a session in Mobile Node Control mode through
a transcoder to translate between native codecs of CN and an audio
device AN, where they share no common codec.
In Mobile Node Control mode, the Mobile Node establishes a media
session between the transcoder and the CN, and one between the
transcoder and the local device. The initial INVITE sent by the MN
to the transcoder includes a session description referring to the CN
and the local device, rather than including its own parameters as in
the standard case. It then establishes a separate session with each
of those nodes. Once the three sessions have been established, two
media sessions exist, and the transcoder translates between them.
This flow is shown in Figure 7.
In Session Handoff mode, the local device itself must establish a
session with the CN through the transcoder. After receiving the
REFER request, it uses the OPTIONS method to find the capabilities of
the CN. It will then use a common codec, if available, in the
session setup, or set up the transcoded session using third-party
Shacham, et al. Expires January 7, 2006 [Page 23]
Internet-Draft SIP Session Mobility July 2005
call control as in [7].
6.2 Display resolution and bandwidth differences
Other differences in device capabilities, such as display resolution
and bandwidth limitations, should also be reconciled during tranfer.
For example, a mobile device, limited both in its display size and
bandwidth, will likely be receiving the video stream from the other
call participant at a low resolution and framerate. When the user
transfers his video output to a large-screen display, he may start
viewing much higher quality video at the higher native resolution of
the display and at a higher framerate.
Changing the image resolution and framerate requires no special
handling by the MN. An SDP format is defined [8] for specifying
these and other parameters for the H.263+ codec. The suitable image
formats and corresponding MPIs (Minimum Picture Interval, related to
the framerate) supported for the given codec are listed following the
media line, in order of preference. For example, the following lines
in SDP would indicate that a device supports the H.263 codec (value
34) with the image sizes of 16CIF, 4CIF, CIF and QCIF (with the MPI
for each format following the "="):
m=video 60300 RTP/AVP 34
a=fmtp:34 16CIF=8;4CIF=6;CIF=4;QCIF=3
In Mobile Node Control mode, the response by the local device (Figure
2, message 1) to the initial INVITE request sent by the MN would
include this line in the SDP body, and the MN would then include it
in the INVITE request sent to the CN (3). In Session Handoff mode,
the local device would include this parameter in the INVITE request
sent to the CN (Figure 4, 3) after receiving the REFER request. If
the local device is not mobility-enhanced, and is, therefore, not
configured to include the supported image sizes during session
establishment, the information could be made available through SLP.
The MN would then include it in the INVITE request sent to the CN in
mobile node control mode. However, this information would not be
sent in Session Handoff mode unless the local device were configured
to send it. In both modes, the MN would send its own resolution and
framerate preferences in the body of the INVITE request sent to
retrieve the session.
7. Session Termination
Once a session has been transferred, the user may terminate it by
hanging up the current device, as he would do in a call originating
on that device. This should be true even when the session is using
several local devices. In MNC mode, when the user hangs up the
Shacham, et al. Expires January 7, 2006 [Page 24]
Internet-Draft SIP Session Mobility July 2005
current device, a BYE is sent to the Controller. The Controller must
then send a BYE request to each device used in the transfer and a BYE
request to the CN. A MDSM used for SH mode must follow the same
procedure. In SH mode, the current device has previously inititated
an ordinary session with the CN in response the the REFER request,
and the BYE it sends to the CN on hang-up requires no special
handling.
8. Performance
In order to enjoy the advantages of session mobility, the transfer
should minimize the disruption of service, and should be quick.
Below, we analyze the expected performance of our system, based on
these criteria.
8.1 Disruption of Media During Transfer
The most critical disruption is the "dead time" between tear-down of
the existing media stream and the establishment of the new stream.
Transfer could cause a segment of media to be unplayed, which we
refer to as "lapse." This occurs when one side begins sending media
to a device not ready to display it, because the necessary session
establishment has not been done. It may also occur if the device
involved in the current session stops sending media before the new
device begins sending media. Even if there is no lapse, there may be
a delay during which one or both sides do not receive media on any
device. The flows already shown ensure that this delay is no longer
than the time it takes a single packet to travel between the remote
participant and the local network, and that the lapse is either non-
existent or negligibly small. Therefore, the mobile user need not
warn the participant at the Correspondent Node: "Wait for me until I
complete this transfer."
8.1.1 Media Streams
In the Mobile Node Control mode flow of Figures 2 and 3, even though
the CN receives a new destination address for its media in messages 3
and 5, respectively, it will not stop receiving or playing the
incoming flows from the MN until it starts receiving media streams
from the local devices, initiated (Figure 2 message 1, Figure 3
messages 1 and 3). While the MN has no way of knowing when this
happens, it can wait a safe amount of time, such as a second, before
it stops sending. Therefore, the CN will not experience any
disruption of media flow. The mobile user may experience a
negligibly short delay in incoming media service. The CN stops
sending media to the MN and starts sending to the local devices after
receiving the INVITE request with new media parameters, as shown in
the figure. Since the local devices are already listening for the
Shacham, et al. Expires January 7, 2006 [Page 25]
Internet-Draft SIP Session Mobility July 2005
media following the INVITE requests received by the MN, they will
begin displaying the media as soon as they receive it. Therefore, no
media lapse will occur. The only delay will be the time it takes for
the RTP packets to travel to the devices. During some of that time,
as well, old media packets will still be received by the MN. The
delay will, therefore, be extremely short.
In Session Handoff mode (Fig. 5), also, there will be no media lapse.
After the CN receives the INVITE request (3) from the local device,
it immediately redirects the media from the MN to the local device.
Once the media stream reaches the local device, it will immediately
begin displaying it. Therefore, all media sent by the CN will be
displayed on some device for the mobile user. There may be a
negligibly short delay between the time the MN stops receiving the
media and the local device begins displaying it. The CN will not
experience any lapse or delay, since it will display the media from
the MN until it starts receiving the streams from the local device,
following message 4.
8.1.2 MSRP Sessions
While latency in messaging sessions is not a serious issue, given
their timescale as compared to that of real-time media, lapse is very
serious, as it amounts to the omission of an entire message that may
fully contain essential information. Therefore, we show that this
will not occur. However, it should be mentioned that, unlike real-
time media, messaging sessions do not send any packets unless a
participant explicitly orders them sent. Even if it were possible
for a packet to be lost during the window of time that the transfer
occurs, this will only be an issue if one of the participants
actually sends a message during that window.
As described above, MNC mode operates in a similar way when
transfering message sessions. However, as described in Section
5.2.2, MSRP requires the establishment of a reliable connection
between the two parties, which are, in our case, the CN and the local
device. This connection may be established by one of the sides, such
as the CN, given a negotiation mechanism. Alternatively, the local
device and CN may both use relays, leaving the relays to handle the
connections between them. Given each model, we analyze the
possibility of messages sent by the CN being missed by the mobile
user and messages sent by the mobile user being missed by the CN.
This is done for MNC mode, but the same analysis may be used for SH
mode.
If the user at the CN indicates that a message should be sent once
the transfer starts, it may be sent as part of the existing MSRP
session or as part of the new session. Therefore, it will either be
Shacham, et al. Expires January 7, 2006 [Page 26]
Internet-Draft SIP Session Mobility July 2005
sent through the existing TCP connection to the MN or it will be sent
through the new TCP connection established with the local device,
after being buffered if necessary. In the first case, the MN will
receive the message, as TCP's [24] graceful close will not allow the
MN to close the connection until then. In the second case, the local
device will receive the message after the TCP connection has been
established.
The mobile user may attempt to send a message from the MN after the
transfer has begun. If the TCP connection has already been torn
down, the user interface should disallow such a message by the user,
as it has nowhere to send it. If the connection is still open the MN
may send the message, and the graceful close will ensure that it will
be received by the CN. When the CN wishes to close the connection,
it will send a FIN segment, but will continue receiving packets from
the MN until it receives the FIN/ACK segment. The MN will only send
the FIN/ACK once it has received positive acknowledgments for any
messages it has sent. If the user attempts to send a message on the
local device before the new TCP connection has been established, the
message will be temporarily buffered and sent once the connection is
made.
If relays are used, once the CN receives the INVITE request from the
MN, it will use the same connection to its relay to authenticate and
create a new MSRP session. There will be two sessions, one between
the CN and the MN, and one between the CN and the local device.
Since all connections will remain open, the CN will be able to
receive messages associated with either session. Once the CN
receives the INVITE request from the MN, it should start sending
messages to the local device, in case the MN quickly shuts down.
8.2 Total Transfer Latency
A less critical, but important, concern is the total delay in
transferring a session, from the time that the mobile user makes the
request until he begins to receive the CN's media streams on the new
device. Firstly, the user may be away from the current device when
transfering to a second one. For example, the mobile user may be
retrieving a session onto his mobile device while walking out of the
office. Even if the user has both devices in front of him, the
latency should be small enough to provide seamless use of the
devices. Furthermore, a long delay may lead the mobile user to
believe that the transfer is not working, as mentioned regarding
ordinary telephone call setup in [19]. Therefore, we give an
estimate of the transfer latency in a typical network.
Both models presented in this document use flows that consist of
signaling between the local environment (MN and local devices) and
Shacham, et al. Expires January 7, 2006 [Page 27]
Internet-Draft SIP Session Mobility July 2005
the CN, which may traverse a long distance, and signaling within the
local environment. Previous work [19] has measured transcontinental
call setup delay in SIP to be below one second. We assume that the
network-layer packet loss and latency over the wireless links
connecting the MN, and possibly the CN and local devices, will not
significantly affect this figure. Therefore, we use this figure for
call setup between the local environment and the CN. Delay in
session creation with the local devices depends on the route taken.
If the sessions are established through the proxy servers and the
mobile user's proxy server is far away, the setup may require a
triangular route to be traversed. If, on the other hand, either the
mobile user's proxy is local or peer-to-peer setup is done, without
the proxy, setup time should be negligible. We assume that this
setup time is very short.
In Mobile Node Control mode, the call flow consists of session
creation with each local device, followed by a session update with
the CN, which has the same signaling as a normal call setup. We
therefore estimate that the transfer delay should not be much longer
than a second. In Session Handoff mode, as well, the call flow
consists of a single call setup between the local network and the CN,
and signaling between the MN and the local devices, such as the REFER
request. Here, too, the transfer should not take much longer than a
second.
9. Security Considerations
Many security concerns must be addressed in the local device
environment. Here we give ways to handle two such concerns, the
unauthorized use of devices and the use of input devices for
surveillance [18].
9.1 Authorization for using local devices
Public devices generally have a group of users who are authorized to
use and to transfer their sessions to them. It is essential that any
other users are not allowed access, in order not to limit the usage
of authorized users. Many methods may be used for authentication of
users, including Authentication, Authorization and Accounting (AAA)
in SIP [16].
9.2 Privacy concerns for input devices
Input devices such as cameras and microphones could be used for
surveillance. This concern can be mitigated in two ways. First of
all, the remote control of devices could be disallowed by requiring
proof that the user is actually in the location of the device. This
could be done by requiring an authentication token that is only
Shacham, et al. Expires January 7, 2006 [Page 28]
Internet-Draft SIP Session Mobility July 2005
available locally [18]. Such a token would regularly change and
would be passed to the mobile device by a low-power Bluetooth beacon,
with its ray restricted to a single room. This token would then be
used in Digest Authentication. In order to keep a local user from
transferring an ongoing session, leaving the room and eavesdropping,
the device should also contain an LED to warn other users that a
session is currently active.
9.3 Privacy concerns for output devices
The ability of a call participant to transfer parts of a session to
output devices threatens the privacy of the other participant.
Especially in the case of video and messaging, the remote participant
will be unaware that his stream is being sent to a different device,
where it may be viewed by people besides the other participant.
Extensions to SIP Caller Preferences [28] and SDP [9] are specified
in [30] which allow a call participant to specify the required level
of privacy of the session. This may serve to disallow the other
party to transfer the session to a less private device, and even
force the other party to retieve a session when the content becomes
more private.
10. IANA Considerations
This document has no actions for IANA.
11. Change History
11.1 Changes from draft-shacham-sipping-session-mobility-00
o Discussed in 5.3.1 how MN receives To, From tags and Call-ID of
transfered session, and in 5.3.2 how it receives these if it had
not previously held the session.
o Defined in subsection 5.1.4 the different media that may be
transfered, introducing the three types of messaging
o Specified in 5.2.2 and 5.3.2 how transfer flows apply to messaging
using SIP MESSAGE and MSRP
o Added subsection 5.4 on incoming call
o Added section 7 on hangup behavior
o Divided up subsection 8.1 to discuss disruption for transfer of
continuous media (8.1.1) and MSRP sessions (8.1.2)
o Added Section 9.3 about privacy concerns for output devices
12. References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Sparks, R., Handley, A., and E. Schooler, "SIP: Session
Initiation Protocol", RFC 3261, June 2002.
Shacham, et al. Expires January 7, 2006 [Page 29]
Internet-Draft SIP Session Mobility July 2005
[2] "3GPP: TS 23.228: IP Multimedia Subsystem (IMS) (Stage 2),
Release 5", September 2002.
[3] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo,
"Best Current Practices for Third Party Call Control (3pcc) in
the Session Initiation Protocol (SIP)", RFC 3725, April 2004.
[4] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[5] Gutman, E., Perkins, C., Veizades, J., and M. Day, "Service
Location Protocol, Version 2", RFC 2608, June 1999.
[6] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications",
RFC 3550, July 2003.
[7] Camarillo, G., Burger, E., Schulzrinne, H., and A. Van Wijk,
"Transcoding Services Invocation in the Session Initiation
Protocol Using Third Party Call Control (3pcc)", IETF Internet
Draft (Work in Progress), September 2004.
[8] Ott, J., Sullivan, G., Wenger, S., and R. Even, "RTP Payload
Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+),
IETF Internet Draft (Work in progress)", December 2004.
[9] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[10] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
the Session Description Protocol (SDP)", RFC 3264, June 2002.
[11] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[12] Peterson, J., "A Presence-based GEOPRIV Location Object Format,
IETF Internet Draft (Work in Progress)", September 2004.
[13] "Global Positioning System Standard Positioning Service
Specification, 2nd Edition", June 1995.
[14] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By
Mechanism", RFC 3892, September 2004.
[15] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
Protocol (SIP) 'Replaces' Header", RFC 3891, September 2004.
[16] Loughney, J. and G. Camarillo, "Authentication, Authorization
Shacham, et al. Expires January 7, 2006 [Page 30]
Internet-Draft SIP Session Mobility July 2005
and Accounting Requirements for the Session Initiation
Protocol (SIP)", RFC 3702, February 2004.
[17] Schulzrinne, H. and E. Wedlund, "Application-Layer Mobility
Using SIP, ACM Mobile Computing and Communications Review,
Vol.4, No.3", July 2000.
[18] Berger, S., Schulzrinne, H., Sidiroglou, S., and X. Wu,
"Ubiquitous Computing Using SIP, ACM NOSSDAV", 2003.
[19] Eyers, T. and H. Schulzrinne, "Predicting Internet Telephony
Call Setup Delay, in Proceedings of First IP Telephony
Workshop, Berlin, Germany", April 2000.
[20] Campbell, B., Mahy, R., and C. Jennings, "The Message Session
Relay Protocol", IETF Internet Draft (Work in Progress),
February 2005.
[21] Jennings, C. and R. Mahy, "Relay Extensions for the Message
Session Relay Protocol", IETF Internet Draft (Work in
Progress), June 2005.
[22] Hellstrom, G., "RTP Payload for Text Conversation", RFC 2793,
May 2000.
[23] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging", RFC 3428, December 2002.
[24] Postel, J., "Transmission Control Protocol", RFC 793, May 1981.
[25] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating
User Agent Capabilities in the Session Initiation Protocol
(SIP)", RFC 3840, August 2004.
[26] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE
Initiated Dialog Event Package for the Session Initiation
Protocol (SIP)", IETF Internet Draft (Work in progress),
April 2005.
[27] Camarillo, G., "Internet Assigned Number Authority (IANA)
Registration of the Message Media Feature Tag", IETF Internet
Draft (Work in progress) Session Initiation Protocol (SIP),
June 2005.
[28] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004.
Shacham, et al. Expires January 7, 2006 [Page 31]
Internet-Draft SIP Session Mobility July 2005
[29] Lennox, J., Wu, X., and H. Schulzrinne, "Caller Preferences for
the Session Initiation Protocol (SIP)", RFC 3880, October 2004.
[30] Shacham, R., Schulzrinne, H., Kellerer, W., and S. Thakolsri,
"Specifying Media Privacy Requirements in the Session
Initiation Protocol (SIP)", IETF Internet Draft (Work in
progress), June 2005.
Authors' Addresses
Ron Shacham
Columbia University
1214 Amsterdam Avenue, MC 0401
New York, NY 10027
USA
Email: rs2194@cs.columbia.edu
Henning Schulzrinne
Columbia University
1214 Amsterdam Avenue, MC 0401
New York, NY 10027
USA
Email: hgs@cs.columbia.edu
Srisakul Thakolsri
DoCoMo Eurolabs
Landsberger Str. 312
Munich 80687
Germany
Email: thakolsri@docomolab-euro.com
Wolfgang Kellerer
DoCoMo Eurolabs
Landsberger Str. 312
Munich 80687
Germany
Email: kellerer@docomolab-euro.com
Shacham, et al. Expires January 7, 2006 [Page 32]
Internet-Draft SIP Session Mobility July 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Shacham, et al. Expires January 7, 2006 [Page 33]