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

Versions: 00 01 02 03 04 05 RFC 5631

SIPPING                                                       R. Shacham
Internet-Draft                                            H. Schulzrinne
Intended status: Informational                       Columbia University
Expires: May 17, 2007                                       S. Thakolsri
                                                             W. Kellerer
                                                        DoCoMo Euro-Labs
                                                       November 13, 2006


           Session Initiation Protocol (SIP) Session Mobility
               draft-shacham-sipping-session-mobility-03

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 May 17, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

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 May 17, 2007                  [Page 1]

Internet-Draft            SIP Session Mobility             November 2006


   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.














































Shacham, et al.           Expires May 17, 2007                  [Page 2]

Internet-Draft            SIP Session Mobility             November 2006


Table of Contents

   1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Component Overview . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Service Location . . . . . . . . . . . . . . . . . . . . . . .  5
   5.  Session Mobility . . . . . . . . . . . . . . . . . . . . . . .  8
     5.1.  Options for Session Mobility . . . . . . . . . . . . . . .  8
       5.1.1.  Transfer and Retrieval . . . . . . . . . . . . . . . .  8
       5.1.2.  Whole and Split Transfer . . . . . . . . . . . . . . .  8
       5.1.3.  Transfer Modes . . . . . . . . . . . . . . . . . . . .  9
         5.1.3.1.  Mobile Node Control (MNC) Mode . . . . . . . . . .  9
         5.1.3.2.  Session Handoff (SH) Mode  . . . . . . . . . . . .  9
       5.1.4.  Types of Transferred Media . . . . . . . . . . . . . .  9
     5.2.  Mobile Node Control Mode . . . . . . . . . . . . . . . . . 10
       5.2.1.  Transfer to a Single Local Device  . . . . . . . . . . 10
         5.2.1.1.  RTP Media  . . . . . . . . . . . . . . . . . . . . 10
         5.2.1.2.  MSRP Sessions  . . . . . . . . . . . . . . . . . . 11
       5.2.2.  Transfer to Multiple Devices . . . . . . . . . . . . . 13
       5.2.3.  Retrieval of a Session . . . . . . . . . . . . . . . . 16
     5.3.  Session Handoff (SH) mode  . . . . . . . . . . . . . . . . 16
       5.3.1.  Transfer to a Single Device  . . . . . . . . . . . . . 16
       5.3.2.  Retrieval of a Session . . . . . . . . . . . . . . . . 19
       5.3.3.  Transfer to Multiple Devices . . . . . . . . . . . . . 21
     5.4.  On Incoming Call . . . . . . . . . . . . . . . . . . . . . 22
   6.  Reconciling Device Capability Differences  . . . . . . . . . . 23
     6.1.  Codec Differences  . . . . . . . . . . . . . . . . . . . . 23
     6.2.  Display Resolution and Bandwidth Differences . . . . . . . 26
   7.  Simultaneous Session Transfer  . . . . . . . . . . . . . . . . 27
   8.  Session Termination  . . . . . . . . . . . . . . . . . . . . . 27
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 28
     9.1.  Authorization for Using Local Devices  . . . . . . . . . . 28
     9.2.  Maintaining Media Security in Session Mobility . . . . . . 28
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 30
   11. Change History . . . . . . . . . . . . . . . . . . . . . . . . 30
     11.1. Changes from draft-shacham-sipping-session-mobility-00 . . 30
     11.2. Changes from draft-shacham-sipping-session-mobility-01 . . 30
     11.3. Changes from draft-shacham-sipping-session-mobility-02 . . 30
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 31
     12.2. Informative References . . . . . . . . . . . . . . . . . . 32
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
   Intellectual Property and Copyright Statements . . . . . . . . . . 34








Shacham, et al.           Expires May 17, 2007                  [Page 3]

Internet-Draft            SIP Session Mobility             November 2006


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
   allows 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) [16] 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 [22], where two different
   methods are proposed, third-party call control (3PCC) [2] and the
   REFER method [3].  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) [17].


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 May 17, 2007                  [Page 4]

Internet-Draft            SIP Session Mobility             November 2006


   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
   PSTN phone reachable through a 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 [17] 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 [18] 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-



Shacham, et al.           Expires May 17, 2007                  [Page 5]

Internet-Draft            SIP Session Mobility             November 2006


   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 [27].  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 as part of his presence [23] which has been suggested by
   [24] as a way to receive location updates in the format standardized
   in [20].  Outdoors, a mobile device may use direct methods such as
   the Global Positioning System (GPS) [21] 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 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)



Shacham, et al.           Expires May 17, 2007                  [Page 6]

Internet-Draft            SIP Session Mobility             November 2006


   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 May 17, 2007                  [Page 7]

Internet-Draft            SIP Session Mobility             November 2006


              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.


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



Shacham, et al.           Expires May 17, 2007                  [Page 8]

Internet-Draft            SIP Session Mobility             November 2006


   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 (MNC) Mode

   In Mobile Node Control Mode, the Mobile Node uses third-party call
   control [2].  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.

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, 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 MNC 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 Transferred 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 [9].
   Any examples given for audio and video will work identically for



Shacham, et al.           Expires May 17, 2007                  [Page 9]

Internet-Draft            SIP Session Mobility             November 2006


   text, as only the payloads differ.  For the transfer of whole
   messages, either the SIP MESSAGE method [25] or the Message Session
   Relay Protocol (MSRP) [7] 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.  We
   discuss later how these messages are affected by session mobility.
   MSRP, on the other hand, is based on sessions that are established
   like the real-time media sessions previously described.  As such,
   transferring them is similar to transferring 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

5.2.1.  Transfer to a Single Local Device

5.2.1.1.  RTP Media

              local                       MN                        CN
                |(1) INVITE no sdp        |                         |
                |<------------------------|                         |
                |(2) 200 OK local params  |                         |
                |------------------------>|                         |
                |                         |(3) INVITE local params  |
                |                         |------------------------>|
                |    RTP                  |                         |
                |<..................................................|
                |                         |(4) 200 OK CN params     |
                |                         |<------------------------|
                |                         |(5) ACK                  |
                |                         |------------------------>|
                |(6) ACK CN params        |                         |
                |<------------------------|        RTP              |
                |..................................................>|
                |                         |                         |
                |                         |                         |


   Figure 2 : Mobile Node Control mode flow for transfer to a single
   device.

   Figure 2 shows the message flow for transferring a session to a
   single local device.  It follows Third Party Call Control Flow I
   specified in [2] which is recommended as long as the endpoints will
   immediately answer.  The MN sends a SIP INVITE request to the local



Shacham, et al.           Expires May 17, 2007                 [Page 10]

Internet-Draft            SIP Session Mobility             November 2006


   device used for the transfer, requesting that a new session be
   established, but not including an SDP body.  The local device's
   response contains an SDP body that includes the address and ports it
   will use for any media, as well as a list of codecs it supports for
   each.  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:

      v=0
      c=IN IP4 av_device.example.com
      m=audio 4400 RTP/AVP 0 8
      a=rtpmap:0 PCMU/8000
      a=rtpmap:8 PCMA/8000
      m=video 5400 RTP/AVP 31 34
      a=rtpmap:31 H261/90000
      a=rtpmap:34 H263/90000

   The MN may select a subset of the media returned, and use that in the
   request sent to the CN.  For example, if it only wishes to transfer
   an audio session to a local device that supports audio and video, it
   will isolate the appropriate media line for audio.  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.  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.1.2.  MSRP Sessions

   The message sequence for transferring 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 transferred 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,
   including MSRP, as follows (2):




Shacham, et al.           Expires May 17, 2007                 [Page 11]

Internet-Draft            SIP Session Mobility             November 2006


      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 52000 msrp/tcp *
      a=accept-types:text/plain
      a=path:msrp://msgn.example.com:12000/kjhd37s2s2;tcp
      m=audio 4400 RTP/AVP 0 8
      a=rtpmap:0 PCMU/8000
      a=rtpmap:8 PCMA/8000
      m=video 5400 RTP/AVP 31 34
      a=rtpmap:31 H261/90000
      a=rtpmap:34 H263/90000

   The same request is then sent by the MN to the CN (3), but containing
   the MSRP media and attribute lines with the path given in the MSGN
   response above.  The CN responds (4) with its own path.  The MN
   includes this in the ACK that it sends to the MSGN (6).

   MSRP sessions are carried over a reliable connection, using TCP or
   TLS.  Therefore, unlike in the case of real-time media, this
   connection must be established.  According to the MSRP
   specifications, 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 of both
   sessions is the MN, who is on neither end of the desired TCP
   connection.  As such, neither end point will establish the
   connection.  A negotiation mechanism could be used to assign the role
   of active endpoint during session setup.  However, while MSRP leaves
   open this possiblity, it is not currently included due to complexity.
   The only other way that such session transfer would be possible is if
   both the CN and the local device ordinarily use an MSRP relay [8],
   since 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) 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:







Shacham, et al.           Expires May 17, 2007                 [Page 12]

Internet-Draft            SIP Session Mobility             November 2006


      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 52000 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.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 appropriate media parameters it receives in
   their responses.  For instance, in order to transfer an audio and
   video call to two devices, it initiates separate sessions with each
   of them, combines the audio media line from one response and the
   video line from the other, and sends them together as the request to
   the CN, as follows:

      v=0
      m=audio 48400 RTP/AVP 0
      c= IN IP4 audio_dev.example.com
      a=rtpmap:0 PCMU/8000
      m=video 58400 RTP/AVP 34
      c= IN IP4 video_dev.example.com
      a=rtpmap:34 H263/90000

   The CN responds with its own parameters for audio and video.  The MN
   splits them and sends one to each local device in the ACK that
   completes each session setup.









Shacham, et al.           Expires May 17, 2007                 [Page 13]

Internet-Draft            SIP Session Mobility             November 2006


      VN                  AN                   MN                     CN
      |                   |(1) INVITE no sdp   |                       |
      |                   |<-------------------|   RTP Audio           |
      |                   |(2) 200 AN params   |                       |
      |                   |------------------->|                       |
      |                   |(3) INVITE no sdp   |                       |
      |<---------------------------------------|                       |
      |                   |(4) 200 VN params   |                       |
      |                   |------------------->|                       |
      |                   |                    |(5) INVITE AN/VN params|
      |                   |                    |---------------------->|
      |                   |         RTP Audio  |                       |
      |   RTP Video       |<...........................................|
      |<...............................................................|
      |                   |                    |(6) 200 OK             |
      |                   |                    |<----------------------|
      |                   |                    |(7) ACK                |
      |                   |                    |---------------------->|
      |                   |(8) ACK CN audio    |                       |
      |                   |<-------------------|   RTP Audio           |
      |                   |...........................................>|
      |                   |(9) ACK CN video    |                       |
      |<---------------------------------------|   RTP Video           |
      |...............................................................>|
      |                   |                    |                       |
      |                   |                    |                       |


   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 local
   devices into two different sessions, but does not include any SDP
   body.  They each respond with all of their available media.  If they
   only support unidectional media, as is the case for a camera or
   devoted display device, they will include the "sendonly" or
   "recvonly" attributes.  Otherwise, the MN will have to append the
   appropriate attribute to each one's media line before sending the
   combined SDP body to the CN.  That body will look as follows:

      m=video 50900 RTP/AVP 34
      a=rtpmap:34 H263/90000





Shacham, et al.           Expires May 17, 2007                 [Page 14]

Internet-Draft            SIP Session Mobility             November 2006


      a=sendonly
      c=IN IP4 camera.example.com
      m=video 50800 RTP/AVP 34
      a=rtpmap:34 H263/90000
      a=recvonly
      c=IN IP4 display.example.com

   In updating an SDP session, according to Section 8 of [4], the i-th
   media line in the new SDP corresponds to the i-th media line in the
   previous SDP.  In the above cases, if a media type is added during
   the transfer, the media line(s) should follow the existing ones.
   When an existing media is transferred to a different device, the
   media line should appear in the same place that it did in the
   previous SDP, as should the lines for all media that have not been
   altered.  When a duplex media stream is being split across an input
   and output device, the stream corresponding to the input device
   should appear in place of the duplex media stream.  Since this new
   stream is the one that will be received by the CN, including it in
   place of the old one ensures that the CN will only stop listening to
   the old port (in case it changes) once it starts receiving on the new
   one.  The media line corresponding to the output device must appear
   after all existing media lines.  In the last example, if the SDP had
   initially contained a video line followed by an audio line, the
   updated SDP sent to the CN would look as follows:

      m=video 50900 RTP/AVP 34
      a=rtpmap:34 H263/90000
      a=sendonly
      c=IN IP4 camera.example.com
      m=audio 45000 RTP/AVP 0
      a=rtpmap:0 PCMU/8000
      m=video 50800 RTP/AVP 34
      a=rtpmap:34 H263/90000
      a=recvonly
      c=IN IP4 display.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 any MESSAGE request to
   the MN, who will forward it to the CN.







Shacham, et al.           Expires May 17, 2007                 [Page 15]

Internet-Draft            SIP Session Mobility             November 2006


5.2.3.  Retrieval of a Session

   The MN may later retrieve the session by sending an INVITE request 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 [3].  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" [5] 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.






























Shacham, et al.           Expires May 17, 2007                 [Page 16]

Internet-Draft            SIP Session Mobility             November 2006


               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:

      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.example.com;audio;video?
            Replaces="1@mn.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 [10].  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



Shacham, et al.           Expires May 17, 2007                 [Page 17]

Internet-Draft            SIP Session Mobility             November 2006


   device requests that the CN replace its current session with the MN
   with the new session.  According to [6], 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.


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




Shacham, et al.           Expires May 17, 2007                 [Page 18]

Internet-Draft            SIP Session Mobility             November 2006


   Once a session is transferred, 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 [12].  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 [7] or will set up the session through its relay if
   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.example.com SIP/2.0
       To: <sip:cn@host1.example.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," [5] 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



Shacham, et al.           Expires May 17, 2007                 [Page 19]

Internet-Draft            SIP Session Mobility             November 2006


   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.example.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
   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.example.com;method=REFER
              ?Refer-To="<sip:cn@host1.example.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 transferred 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 [11] 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



Shacham, et al.           Expires May 17, 2007                 [Page 20]

Internet-Draft            SIP Session Mobility             November 2006


   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.

   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 a system of devices, it may hand off a session
   by sending a REFER request to the MDSM URI.  When the MDSM 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 May 17, 2007                 [Page 21]

Internet-Draft            SIP Session Mobility             November 2006


           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.  MNC 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 SIP UA on the



Shacham, et al.           Expires May 17, 2007                 [Page 22]

Internet-Draft            SIP Session Mobility             November 2006


   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) [26] 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



Shacham, et al.           Expires May 17, 2007                 [Page 23]

Internet-Draft            SIP Session Mobility             November 2006


   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
   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 MNC 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 MNC 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 any means, including SLP.

   Using transcoding services in SIP is defined in [18] using third-
   party call control.  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 its
   own media parameters to indicate which media it would like
   transcoded.  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 May 17, 2007                 [Page 24]

Internet-Draft            SIP Session Mobility             November 2006


     AN       Transcoder                      MN                      CN
   (codec A)                                                       (codec B)
      |           |(1) INVITE MN params        |                       |
      |           |<---------------------------|                       |
      |           |(2) 200 TA, TB params       |                       |
      |           |--------------------------->|                       |
      |           |(3) ACK                     |                       |
      |           |<---------------------------|                       |
      |           |(4) INVITE TA params        |                       |
      |<---------------------------------------|                       |
      |   RTP     |                            |                       |
      |..........>|                            |                       |
      |           |(5) 200 AN params           |                       |
      |--------------------------------------->|                       |
      |           |(6) ACK                     |                       |
      |<---------------------------------------|                       |
      |           |                            |(7) INVITE TB params   |
      |           |                            |---------------------->|
      |           |                            |       RTP             |
      |           |<...................................................|
      |           |                            |(8) 200 OK CN params   |
      |           |                            |<----------------------|
      |           |                            |(9) ACK                |
      |           |                            |---------------------->|
      |           |(8) INVITE AN, CN params    |                       |
      |  RTP      |<---------------------------|                       |
      |<..........|                            |  RTP                  |
      |           |...................................................>|
      |           |(9) 200 OK TA,TB params     |                       |
      |           |--------------------------->|                       |
      |           |(10) ACK                    |                       |
      |           |<---------------------------|                       |
      |           |                            |                       |


   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 MNC mode, the Mobile Node establishes one 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 itself.  The transcoder
   responds with parameters for both streams that it will accept.  The
   MN invites the local device and the CN into separate sessions using
   these provided parameters.  They each provide their own parameters in
   the responses, which the MN combines to update the session with the
   transcoder.  Once the three sessions have been established, two media



Shacham, et al.           Expires May 17, 2007                 [Page 25]

Internet-Draft            SIP Session Mobility             November 2006


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

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 [19] 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 MNC 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



Shacham, et al.           Expires May 17, 2007                 [Page 26]

Internet-Draft            SIP Session Mobility             November 2006


   session.


7.  Simultaneous Session Transfer

   A session transfer may be carried out by one call participant after
   the other participant has transferred the session on his side.  If
   the first transfer was done in MNC mode, a subset of the original
   session media is now on local devices.  The MN receives either a re-
   INVITE from the other participant or an INVITE request from a local
   device on the other side.  This message carries the new media
   parameters of the session.  The MN, therefore, must send a re-INVITE
   to any local devices with these parameters.  It then includes the
   parameters returned from these devices in the 200 OK response.  If
   the first transfer was done in SH mode, the local device will
   directly receive the session transfer message from the other party
   and will follow the normal procedure for responding to an INVITE
   request.  If it is controlling other local devices for this session
   as part of an MDS, it follows the procedure above where the first
   transfer was done in MNC mode.

   It may occur that both participants attempt a transfer at the same
   time.  In MNC mode, each node initiates a session with a local
   device, then sends a re-INVITE to the other node.  Section 14.2 in
   [1] mandates a 491 response when a re-INVITE is received for a dialog
   once another re-INVITE has already been sent.  Once both parties
   receive this response, they each generate a random timer, with
   staggered intervals.  Once its timer fires, each participant attempts
   the re-INVITE again.  The first to receive it from the other
   participant responds to it with the SDP parameters of its local
   device.  Both participants then send an ACK to their local device
   containing the new parameters obtained from the other one during the
   re-INVITE process.

   In SH mode, if both participants attempt a transfer at the same time,
   after one node sends a REFER request to the local device, it receives
   the INVITE request from the local device on the other end.  The
   appropriate protocol definition could mandate that a 491 response be
   sent in this case, as well.  This response would be returned to the
   referrer in a NOTIFY indicating the status of the referred session
   establishment.  The staggered timer solution described above could
   work.  The MN would cancel the REFER request sent to the local
   device, then wait a random amount of time before sending it again.


8.  Session Termination

   Once a session has been transferred, the user may terminate it by



Shacham, et al.           Expires May 17, 2007                 [Page 27]

Internet-Draft            SIP Session Mobility             November 2006


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


9.  Security Considerations

   Many security concerns must be addressed in session mobility.  As
   this work is based heavily on the work in [2], [3] and [5], the
   security considerations described in those documents apply.  We
   discuss here the particular issues of authorizing use of local
   devices and providing media-level security following transfer.

9.1.  Authorization for Using Local Devices

   Use of a local device must be limited to authorized parties.  We
   assume in this document that these devices are private, accessible
   for transfer only to their owners.  They must accept these types of
   INVITE and REFER requests only from identities representing the
   owner.  However, they may also be used to accept ordinary calls.
   Therefore, there must be a distinction between requests to
   communicate with the owner himself, which should be accepted from
   anybody (except for those excluded through a white/black list policy)
   and requests to use the device for transfer, which is only accepted
   from the owner.  The latter type of request should be addressed to a
   different URI, such as phone@example.com.  Digest or S/MIME may be
   used to authenticate the owner's identity.

   Deployment of public devices that are available to a group of users
   for their transfers is beyond the scope of this document.

9.2.  Maintaining Media Security in Session Mobility

   Confidentiality, message authentication and replay protection are
   necessary in internet protocols, including those used for real-time
   multimedia communications.  The Secure Real-time Transfer Protocol
   (SRTP) [13] provides these for RTP streams.  Since SRTP may be used
   to carry the media sessions of SIP devices, such as the MN and CN, we
   discuss how to ensure that the session continues to use SRTP
   following the transfer to another device.  This is also discussed in
   less detail in [2].



Shacham, et al.           Expires May 17, 2007                 [Page 28]

Internet-Draft            SIP Session Mobility             November 2006


   The establishment of secure RTP communications through SDP is defined
   by two documents.  The "crypto" attribute [14], is a media-level
   attribute whose value includes the desired cryptographic suite and
   key parameters used to perform symmetric encryption on the RTP
   packets.  Since the key information is sent in the SDP body with no
   dedicated encryption or integrity protection, a separate protocol
   such as S/MIME must be used to protect the signaling messages.
   Another document [15] specifies the "key-mgmt" attribute used to
   provide parameters for a key management protocol, such as MIKEY.
   Using this attribute, the two participants exchange keys encrypted by
   a public or shared key, or negotiate a key using the Diffie-Hellman
   method.

   The use of cryptographic parameters in SDP does not change the
   message flows described earlier in this document.  For instance, in
   MNC mode shown in Figure 2, the response from the local device (2)
   will include, in addition to any supported media type, cryptographic
   information for each type.  This cryptographic information will be a
   list of attribute lines describing crypto suite and key parameters
   using either of the two attributes mentioned.  These lines will be
   sent by the MN to the CN in the subsequent request (3).  The CN will
   choose a cryptographic method and return its own key information in
   the response (4).  Maintaining a secure media session in SH mode
   requires the local device to negotiate a cryptographic relationship
   in the session that it establishes following its receipt of the REFER
   request.

   It is noted in [2] that establishing media security in Third Party
   Call Control depends on the cooperation of the controller.  The
   following is an excerpt from that document:

      End-to-end media security is based on the exchange of keying
      material within SDP.  The proper operation of these mechanisms
      with third party call control depends on the controller behaving
      properly.  So long as it is not attempting to explicitly disable
      these mechanisms, the protocols will properly operate between the
      participants, resulting in a secure media session that even the
      controller cannot eavesdrop or modify.  Since third party call
      control is based on a model of trust between the users and the
      controller, it is reasonable to assume it is operating in a well-
      behaved manner.  However, there is no cryptographic means that can
      prevent the controller from interfering with the initial exchanges
      of keying materials.  As a result, it is trivially possibly for
      the controller to insert itself as an intermediary on the media
      exchange, if it should so desire.

   We note here that given the model presented in this document, where
   the controller is operated by the same person that uses the local



Shacham, et al.           Expires May 17, 2007                 [Page 29]

Internet-Draft            SIP Session Mobility             November 2006


   device, there is even more reason to believe that the controller will
   be well-behaved and will not interfere with the transfer of key
   exchanges.


10.  IANA Considerations

   This document has no actions for IANA.


11.  Change History

   [[RFC Editor: Please remove this entire section upon publication as
   an RFC.]]

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

11.2.  Changes from draft-shacham-sipping-session-mobility-01
   o  Clarified in Section 5.2 how media lines must be arranged in a re-
      INVITE to the CN in MNC mode.
   o  Discussed in the Security Considerations section how security
      settings are maintained after session transfer.
   o  Added Section 7 on Simultaneous Session Transfer.

11.3.  Changes from draft-shacham-sipping-session-mobility-02
   o  Discussed the use of the "key-mgmt" attribute in the Security
      Considerations section and made reference to the concern raised in
      3pcc RFC about media security establishment.
   o  Removed sections on input and output devices in Security
      Considerations.
   o  Removed section on performance.


12.  References





Shacham, et al.           Expires May 17, 2007                 [Page 30]

Internet-Draft            SIP Session Mobility             November 2006


12.1.  Normative 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]   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.

   [3]   Sparks, R., "The Session Initiation Protocol (SIP) Refer
         Method", RFC 3515, April 2003.

   [4]   Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
         the Session Description Protocol (SDP)", RFC 3264, June 2002.

   [5]   Sparks, R., "The Session Initiation Protocol (SIP) Referred-By
         Mechanism", RFC 3892, September 2004.

   [6]   Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
         Protocol (SIP)  "Replaces" Header", RFC 3891, September 2004.

   [7]   Campbell, B., Mahy, R., and C. Jennings, "The Message Session
         Relay Protocol, IETF Internet Draft (Work in Progress)",
         October 2006.

   [8]   Jennings, C. and R. Mahy, "Relay Extensions for the Message
         Session Relay  Protocol, IETF Internet Draft (Work in
         Progress)", July 2006.

   [9]   Hellstrom, G., "RTP Payload for Text Conversation", RFC 2793,
         May 2000.

   [10]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating
         User Agent Capabilities in the  Session Initiation Protocol
         (SIP)", RFC 3840, August 2004.

   [11]  Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
         Initiated Dialog Event Package for the  Session Initiation
         Protocol (SIP)", RFC 4235, November 2005.

   [12]  Camarillo, G., "Internet Assigned Number Authority (IANA)
         Registration of the Message Media Feature Tag Session
         Initiation Protocol (SIP)", RFC 4569, July 2006.

   [13]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
         Norrman, "The Secure Real-time Transport Protocol (SRTP)",
         RFC 3711, March 2004.



Shacham, et al.           Expires May 17, 2007                 [Page 31]

Internet-Draft            SIP Session Mobility             November 2006


   [14]  Andreasen, F., Baugher, M., and D. Wing, "Session Description
         Protocol (SDP)  Security Descriptions for Media Streams",
         RFC 4568, July 2006.

   [15]  Arkko, J., Lindhold, F., Naslund, M., Norrman, K., and E.
         Carrara, "Key Management Extensions for Session Description
         Protocol (SDP) and Real Time Streaming Protocol (RTSP)",
         RFC 4567, July 2006.

12.2.  Informative References

   [16]  "3GPP: TS 23.228: IP Multimedia Subsystem (IMS) (Stage 2),
         Release 5", September 2002.

   [17]  Gutman, E., Perkins, C., Veizades, J., and M. Day, "Service
         Location Protocol, Version 2", RFC 2608, June 1999.

   [18]  Camarillo, G., Burger, E., Schulzrinne, H., and A. Van Wijk,
         "Transcoding Services Invocation in the  Session Initiation
         Protocol (SIP) Using Third Party Call Control (3pcc)",
         RFC 4117, June 2005.

   [19]  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)", September 2005.

   [20]  Peterson, J., "A Presence-based GEOPRIV Location Object
         Format", RFC 4119, December 2005.

   [21]  "Global Positioning System Standard Positioning Service
         Specification, 2nd Edition", June 1995.

   [22]  Schulzrinne, H. and E. Wedlund, "Application-Layer Mobility
         Using SIP, ACM Mobile Computing and Communications Review,
         Vol.4, No.3", July 2000.

   [23]  Rosenberg, J., "A Presence Event Package for the Session
         Initiation Protocol (SIP)", RFC 3856, August 2004.

   [24]  Peterson, J., "A Presence Architecture for the Distribution of
         GEOPRIV Location Objects", RFC 4079, July 2005.

   [25]  Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
         D. Gurle, "Session Initiation Protocol (SIP) Extension for
         Instant Messaging", RFC 3428, December 2002.

   [26]  Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing
         Language (CPL): A Language for User Control of Internet



Shacham, et al.           Expires May 17, 2007                 [Page 32]

Internet-Draft            SIP Session Mobility             November 2006


         Telephony Services", RFC 3880, October 2004.

   [27]  Berger, S., Schulzrinne, H., Sidiroglou, S., and X. Wu,
         "Ubiquitous Computing Using SIP", October 2004.


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 Communications Laboratories Europe
   Landsberger Str. 312
   Munich  80687
   Germany

   Email: thakolsri@docomolab-euro.com


   Wolfgang Kellerer
   DoCoMo Communications Laboratories Europe
   Landsberger Str. 312
   Munich  80687
   Germany

   Email: kellerer@docomolab-euro.com









Shacham, et al.           Expires May 17, 2007                 [Page 33]

Internet-Draft            SIP Session Mobility             November 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   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.

   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.


Intellectual Property

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Shacham, et al.           Expires May 17, 2007                 [Page 34]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/