[Docs] [txt|pdf] [Tracker] [Email] [Nits] [IPR]

Versions: 00 01 02 03 04 05 RFC 5631

SIPPING                                                       R. Shacham
Internet-Draft                                            H. Schulzrinne
Expires: August 18, 2005                             Columbia University
                                                            S. Thakolsri
                                                             W. Kellerer
                                                         DoCoMo Eurolabs
                                                       February 14, 2005

           Session Initiation Protocol (SIP) Session Mobility

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 3 of RFC 3667.  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 become aware will be disclosed,
   in accordance with RFC 3668.

   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 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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on August 18, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).  All Rights Reserved.


   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
   service discovery to locate devices to use as transfer targets, for
   which the Service Location Protocol (SLP) is used, session transfer,

Shacham, et al.          Expires August 18, 2005                [Page 1]

Internet-Draft            SIP Session Mobility             February 2005

   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.  Introduction..................................................  3
   2.  Requirements..................................................  4
   3.  Component Overview............................................  5
   4.  Service Location..............................................  6
   5.  Session Mobility..............................................  9
      5.1   Options for Session Mobility.............................  9
         5.1.1   Transfer and Retrieval..............................  9
         5.1.2   Whole and split transfer............................  9
         5.1.3   Transfer modes......................................  9
     Mobile Node Control mode.......................  9
     Session Handoff mode........................... 10
      5.2   Mobile Node Control mode................................. 10
         5.2.1   Transfer to a single local device................... 10
         5.2.2   Transfer to multiple devices........................ 11
         5.2.3   Retrieval of a Session.............................. 13
      5.3   Session Handoff (SH) mode................................ 13
         5.3.1   Transfer to a single device......................... 13
         5.3.2   Retrieval of a session.............................. 15
         5.3.3   Transfer to multiple devices........................ 17
   6.  Reconciling Device Capability Differences..................... 19
      6.1 Codec differences.......................................... 19
      6.2 Display resolution and bandwidth differences............... 21
   7.  Performance................................................... 23
      7.1   Disruption of Media During Transfer...................... 23
      7.2   Total Transfer Latency................................... 24
   8.  Security Considerations....................................... 26
      8.1   Authorization for using local devices.................... 26
      8.2   Privacy concerns for input devices....................... 26
   9.  IANA Considerations........................................... 27
   10.  References................................................... 27
         Authors' Addresses.......................................... 28
         Intellectual Property and Copyright Statements.............. 30

Shacham, et al.          Expires August 18, 2005                [Page 2]

Internet-Draft            SIP Session Mobility             February 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
   o  Service Location - At all times, a user is aware of the devices
      which are available in his local area, along with their
   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.  For our examples, we have decided to use the
   Service Location Protocol (SLP) [5], and the tradeoffs involved in
   choosing the various models will be discussed below.

Shacham, et al.          Expires August 18, 2005                [Page 3]

Internet-Draft            SIP Session Mobility             February 2005

2.  Requirements

   This session mobility framework seeks to fulfill the following
   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.
   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 enhanced to support special call handling and service
      discovery.  Commercial IP phones and embedded devices are basic
      since they cannot be enhanced by the end user.
   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.

Shacham, et al.          Expires August 18, 2005                [Page 4]

Internet-Draft            SIP Session Mobility             February 2005

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.

Shacham, et al.          Expires August 18, 2005                [Page 5]

Internet-Draft            SIP Session Mobility             February 2005

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 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
   implement device discovery in our system using a general protocol,
   namely SLP.

   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

Shacham, et al.          Expires August 18, 2005                [Page 6]

Internet-Draft            SIP Session Mobility             February 2005

   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
   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.

Shacham, et al.          Expires August 18, 2005                [Page 7]

Internet-Draft            SIP Session Mobility             February 2005

             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 August 18, 2005                [Page 8]

Internet-Draft            SIP Session Mobility             February 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.  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 August 18, 2005                [Page 9]

Internet-Draft            SIP Session Mobility             February 2005  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.2  Mobile Node Control Mode

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

   Figure 2 shows the message flow for transferring 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,

Shacham, et al.          Expires August 18, 2005               [Page 10]

Internet-Draft            SIP Session Mobility             February 2005

   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:

      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:

      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 August 18, 2005               [Page 11]

Internet-Draft            SIP Session Mobility             February 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

   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
      c=IN IP4 display.example.com
      m=video 8800 RTP/AVP 34
      c=IN IP4 camera.example.com

Shacham, et al.          Expires August 18, 2005               [Page 12]

Internet-Draft            SIP Session Mobility             February 2005

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.

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 Trying               |                     |
            |---------------------------->|                     |
            |(3) INVITE, Replaces         |                     |
            |               RTP                                 |
            |(4) 200 OK                   |                     |
            |         RTP                                       |
            |(5) ACK                      |                     |
            |                             |(6) BYE              |
            |                             |-------------------->|
            |                             |(7) 200 OK           |
            |                             |<--------------------|
            |                             |                     |
            |                             |                     |

   Figure 4 : Session Handoff mode flow for transfer to a single device.

Shacham, et al.          Expires August 18, 2005               [Page 13]

Internet-Draft            SIP Session Mobility             February 2005

   The MN sends the following REFER request (1) to a local device:

      REFER sip:av@local_device.example.com SIP/2.0
      To: <sip:av@local_device.example.com>
      From: <sip:mn@example.com>
      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 August 18, 2005               [Page 14]

Internet-Draft            SIP Session Mobility             February 2005

           AN                             MN                    CN
            |(1) REFER                    |                     |
            |<----------------------------|                     |
            |(2) 202 Trying               |                     |
            |---------------------------->|                     |
            |(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.

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

Shacham, et al.          Expires August 18, 2005               [Page 15]

Internet-Draft            SIP Session Mobility             February 2005

   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

       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?
       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 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>

    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.
   Obviously, the local device must not grant the request to anybody and
   allow the session to be taken over.  Only the original participant in
   the session or the owner of the device should be authorized to

Shacham, et al.          Expires August 18, 2005               [Page 16]

Internet-Draft            SIP Session Mobility             February 2005

   request such a REFER.  The CN accepts the INVITE request and, once
   the session is established, will terminate its session with the local

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.

   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 August 18, 2005               [Page 17]

Internet-Draft            SIP Session Mobility             February 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.

Shacham, et al.          Expires August 18, 2005               [Page 18]

Internet-Draft            SIP Session Mobility             February 2005

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
   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

   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"

Shacham, et al.          Expires August 18, 2005               [Page 19]

Internet-Draft            SIP Session Mobility             February 2005

   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

       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

Shacham, et al.          Expires August 18, 2005               [Page 20]

Internet-Draft            SIP Session Mobility             February 2005

   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
   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

Shacham, et al.          Expires August 18, 2005               [Page 21]

Internet-Draft            SIP Session Mobility             February 2005

   framerate preferences in the body of the INVITE request sent to
   retrieve the session.

Shacham, et al.          Expires August 18, 2005               [Page 22]

Internet-Draft            SIP Session Mobility             February 2005

7.  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.

7.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."

   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
   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

Shacham, et al.          Expires August 18, 2005               [Page 23]

Internet-Draft            SIP Session Mobility             February 2005

   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.

7.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
   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

Shacham, et al.          Expires August 18, 2005               [Page 24]

Internet-Draft            SIP Session Mobility             February 2005

   request.  Here, too, the transfer should not take much longer than a

Shacham, et al.          Expires August 18, 2005               [Page 25]

Internet-Draft            SIP Session Mobility             February 2005

8.  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].

8.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].

8.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
   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.

Shacham, et al.          Expires August 18, 2005               [Page 26]

Internet-Draft            SIP Session Mobility             February 2005

9.  IANA Considerations

   This document has no actions for IANA.

10.  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.

   [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.

Shacham, et al.          Expires August 18, 2005               [Page 27]

Internet-Draft            SIP Session Mobility             February 2005

   [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
         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.

Authors' Addresses

   Ron Shacham
   Columbia University
   1214 Amsterdam Avenue, MC 0401
   New York, NY  10027

   Email: rs2194@cs.columbia.edu

   Henning Schulzrinne
   Columbia University
   1214 Amsterdam Avenue, MC 0401
   New York, NY  10027

   Email: hgs@cs.columbia.edu

Shacham, et al.          Expires August 18, 2005               [Page 28]

Internet-Draft            SIP Session Mobility             February 2005

   Srisakul Thakolsri
   DoCoMo Eurolabs
   Landsberger Str. 312
   Munich  80687

   Email: thakolsri@docomolab-euro.com

   Wolfgang Kellerer
   DoCoMo Eurolabs
   Landsberger Str. 312
   Munich  80687

   Email: kellerer@docomolab-euro.com

Shacham, et al.          Expires August 18, 2005               [Page 29]

Internet-Draft            SIP Session Mobility             February 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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

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.

Shacham, et al.          Expires August 18, 2005               [Page 30]

Internet-Draft            SIP Session Mobility             February 2005


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Shacham, et al.          Expires August 18, 2005               [Page 31]

Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/