summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5631.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5631.txt')
-rw-r--r--doc/rfc/rfc5631.txt1963
1 files changed, 1963 insertions, 0 deletions
diff --git a/doc/rfc/rfc5631.txt b/doc/rfc/rfc5631.txt
new file mode 100644
index 0000000..fb33738
--- /dev/null
+++ b/doc/rfc/rfc5631.txt
@@ -0,0 +1,1963 @@
+
+
+
+
+
+
+Network Working Group R. Shacham
+Request for Comments: 5631 H. Schulzrinne
+Category: Informational Columbia University
+ S. Thakolsri
+ W. Kellerer
+ DoCoMo Euro-Labs
+ October 2009
+
+
+ Session Initiation Protocol (SIP) Session Mobility
+
+Abstract
+
+ Session mobility is the transfer of media of an ongoing communication
+ session from one device to another. This document describes the
+ basic approaches and shows the signaling and media flow examples for
+ providing this service using the Session Initiation Protocol (SIP).
+ Service discovery is essential to locate targets for session transfer
+ and is discussed using the Service Location Protocol (SLP) as an
+ example. This document is an informational document.
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright and License Notice
+
+ Copyright (c) 2009 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the BSD License.
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+
+
+
+Shacham, et al. Informational [Page 1]
+
+RFC 5631 SIP Session Mobility October 2009
+
+
+ the copyright in such materials, this document may not be modified
+ outside the IETF Standards Process, and derivative works of it may
+ not be created outside the IETF Standards Process, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+Table of Contents
+
+ 1. Overview ........................................................3
+ 2. Requirements ....................................................4
+ 3. Roles of Entities ...............................................4
+ 4. Device Discovery ................................................5
+ 5. Session Mobility ................................................7
+ 5.1. Options for Session Mobility ...............................7
+ 5.1.1. Transfer and Retrieval ..............................7
+ 5.1.2. Whole and Split Transfer ............................7
+ 5.1.3. Transfer Modes ......................................8
+ 5.1.3.1. Mobile Node Control (MNC) Mode .............8
+ 5.1.3.2. Session Handoff (SH) Mode ..................8
+ 5.1.4. Types of Transferred Media ..........................8
+ 5.2. Addressing of Local Devices ................................9
+ 5.3. Mobile Node Control Mode ..................................10
+ 5.3.1. Transferring a Session to a Single Local Device ....10
+ 5.3.1.1. RTP Media .................................10
+ 5.3.1.2. MSRP Sessions .............................11
+ 5.3.2. Transfer to Multiple Devices .......................13
+ 5.3.3. Retrieval of a Session .............................16
+ 5.4. Session Handoff (SH) mode .................................16
+ 5.4.1. Transferring a Session to a Single Local Device ....16
+ 5.4.2. Retrieval of a Session .............................19
+ 5.4.3. Transfer to Multiple Devices .......................21
+ 5.5. Distributing Sessions for Incoming Call ...................23
+ 5.6. Use of ICE in Session Mobility ............................24
+ 6. Reconciling Device Capability Differences ......................25
+ 6.1. Codec Differences .........................................25
+ 6.2. Display Resolution and Bandwidth Differences ..............27
+ 7. Simultaneous Session Transfer ..................................27
+ 8. Session Termination ............................................28
+ 9. Security Considerations ........................................29
+ 9.1. Authorization for Using Local Devices .....................29
+ 9.2. Maintaining Media Security During Session Mobility ........29
+ 9.2.1. Establishing Secure RTP Using SDP ..................29
+ 9.2.2. Securing Media Using the Transport Layer ...........31
+ 9.3. Flooding Attacks in MNC Mode ..............................31
+ 10. Acknowledgments ...............................................32
+ 11. References ....................................................32
+ 11.1. Normative References .....................................32
+ 11.2. Informative References ...................................33
+
+
+
+Shacham, et al. Informational [Page 2]
+
+RFC 5631 SIP Session Mobility October 2009
+
+
+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 are not mobile. Moving active multimedia sessions
+ between these devices allows mobile and stationary devices to be used
+ concurrently or interchangeably in mid-session, combining their
+ advantages into a single "virtual device". An approach to session
+ mobility based on the Session Initiation Protocol (SIP) [1] was
+ described first in [20], 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 framework for
+ session mobility that allows a Mobile Node to discover available
+ devices and to include them in an active session. In particular, the
+ framework for session mobility presented in this document describes
+ basic approaches for using existing protocols and shows the signaling
+ and media flow examples for providing session mobility using SIP. It
+ is intended as an informational document.
+
+ The devices selected as session transfer targets may be either
+ personal or public. Personal devices are ones used by a single
+ individual, such as one's PC or phone. Public devices are ones
+ available for use by a large group of people and include large
+ conference-room displays. Two capabilities are required to transfer
+ sessions:
+
+ Device Discovery - At all times, a user is aware of the devices
+ that are available in his local area, along with their
+ capabilities.
+
+ Session Mobility - While in a session with a remote participant,
+ the user may transfer any subset of the active media sessions to
+ one or more devices.
+
+ This document describes session mobility examples for SIP. It does
+ not mandate any particular protocol for device discovery. Many
+ different protocols exist and we discuss the tradeoffs involved in
+ choosing between them. For our examples, we use the Service Location
+ Protocol (SLP) [17], primarily because it is the only such protocol
+ standardized by the IETF.
+
+
+
+
+
+
+
+Shacham, et al. Informational [Page 3]
+
+RFC 5631 SIP Session Mobility October 2009
+
+
+2. Requirements
+
+ This session mobility framework seeks to fulfill the following
+ requirements:
+
+ o REQ 1: Backward Compatibility - We distinguish two kinds of
+ devices. Enhanced devices support the call flows described in
+ Section 5 and can perform discovery, while basic devices can do
+ neither and only have basic SIP capabilities. Devices initiating
+ session mobility must have enhanced functionality, while all
+ others can be either basic or enhanced devices. This includes the
+ transfer destinations, such as the local video camera, as well as
+ the device being used by the remote participant.
+
+ o REQ 2: 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 3: Minimal Disruption - Session transfer should involve
+ minimal disruption of the media flow and should not appear to the
+ remote participant as a new call.
+
+3. Roles of Entities
+
+ Session mobility involves five types of components: A Correspondent
+ Node (CN), a Mobile Node (MN), one or more local devices used as
+ targets for session transfer, an SLP [17] 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 User Agent (UA), or a Public
+ Switched Telephone Network (PSTN) phone reachable through a gateway.
+ The Mobile Node (MN) is a mobile device, containing a SIP UA for
+ standard SIP call setup, as well as specialized SIP-handling
+ capabilities for session mobility, and an SLP [17] User Agent (UA)
+ for discovering local devices. 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.4.3.
+ The SLP Directory Agent (DA) keeps track of devices, including their
+ locations and capabilities. The use of SLP will be described in more
+ detail in Section 4. SIP-based transcoding services [18] are used,
+
+
+
+Shacham, et al. Informational [Page 4]
+
+RFC 5631 SIP Session Mobility October 2009
+
+
+ when necessary, to translate between media streams, as described in
+ Section 6.
+
+4. Device Discovery
+
+ A Mobile Node must be able to discover suitable devices in its
+ vicinity. This is outside the scope of SIP, and a separate service
+ location protocol is needed. It is outside the scope of this
+ document to define any service location protocol. This section
+ discusses various options, and describes one of them in more detail.
+
+ While having a global infrastructure for discovering devices or other
+ services in any location would be desirable, nothing of this sort is
+ currently deployed or standardized. However, this document assumes
+ that such an infrastructure is unnecessary for discovering devices
+ that are in close proximity, such as in the same room. It is
+ possible for such devices to be discovered through direct
+ communication over a short-range wireless protocol such as the
+ Bluetooth Session Description Protocol (SDP). Two other categories
+ of service discovery protocols may be used, assuming that devices
+ that are physically close to each other are also within the same
+ network and/or part of the same DNS domain. Multicast-based
+ protocols, such as SLP [17] (in its serverless mode) or Bonjour
+ (mDNS-SD [30]), may be used as long as the Mobile Node is within the
+ same subnet as the local devices. When devices are part of the same
+ DNS domain, server-mode SLP or non-multicast DNS Service Discovery
+ (DNS-SD) [29] are possible solutions. Such protocols can discover
+ devices within a larger geographical area, and have the advantage
+ over the first category in that they allow for the discovery of
+ devices at different location granularities, such as at the room or
+ building level, and in locations other than the current one. In
+ order to discover devices in a specific location, location
+ attributes, such as room number, must be used in the search, e.g., as
+ service attributes in SLP or as a domain name in DNS-SD. The mobile
+ device must ascertain its location in order to perform this search.
+ We note that many of these techniques could be difficult to implement
+ in practice. For example, different wireless networks may be
+ deployed by different organizations, which could make it unrealistic
+ to have a common DNS setup.
+
+ We describe here how SLP is used in server mode in general, then how
+ it may be used to discover devices based on their location. As
+ mentioned before, this is only one of many ways to perform service
+ discovery. 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. The attributes may be information such as vendor,
+ supported media codecs, and display resolution. SLP defines three
+ roles: Service Agents (SAs), which send descriptions of services;
+
+
+
+Shacham, et al. Informational [Page 5]
+
+RFC 5631 SIP Session Mobility October 2009
+
+
+ User Agents (UAs), which query for services; and Directory Agents
+ (DAs), which receive the registrations and queries. An SA registers
+ a service description to a 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 a 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. It may then ascertain the
+ specific attributes of each service using an attribute request
+ (AttrRqst) message.
+
+ This document assumes the following use of SLP for discovering local
+ devices. Devices have a service type of "sip-device" and a SIP URI
+ as the service URI. Section 5.2 describes the form of this URI.
+ Attributes specify device characteristics such as vendor, supported
+ media codec, display resolution, as well as location coordinates,
+ such as street address and room number. SAs are co-located with SIP
+ UAs on session-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.
+
+ 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 that are not in the
+ current room. A SrvRply message is sent to the mobile device with a
+ list of SIP URIs for all devices in the room. A separate attribute
+ request (AttrRqst) is then sent for each URL to get the attributes of
+ the service. The MN displays for the user the available devices in
+ the room and their attributes. Figure 1 shows this protocol flow.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Shacham, et al. Informational [Page 6]
+
+RFC 5631 SIP Session Mobility October 2009
+
+
+ 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. A transfer means to move the session on the current device
+ to one or more other devices. A retrieval causes a session currently
+ on another device to be transferred to the local device. This may
+ mean returning 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 move 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
+
+ The set of session media may either be transferred completely to a
+ single device or split across multiple devices. For instance, a user
+ may only wish to transfer the video component of his session while
+ maintaining the audio component on his PDA. Alternatively, he may
+ find separate video and audio devices and wish to transfer one media
+
+
+
+Shacham, et al. Informational [Page 7]
+
+RFC 5631 SIP Session Mobility October 2009
+
+
+ type 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 (MNC) mode and Session Handoff (SH) mode. We describe them
+ below in turn.
+
+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 sessions 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, for
+ example, the battery on his mobile device is running out or he is
+ losing radio connectivity. 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 a case, Session Handoff mode, which
+ completely transfers the session signaling and media to another
+ device, is useful.
+
+ Based on our experiments, 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 text
+ messages, and possibly other MIME types, that are suitable for SIP
+ endpoints. RTP may be used to transport text payloads in real time,
+
+
+
+Shacham, et al. Informational [Page 8]
+
+RFC 5631 SIP Session Mobility October 2009
+
+
+ based on [9]. Any examples given for audio and video will work
+ identically for text, as only the payloads differ. For the transfer
+ of entire messages (as opposed to a small number of characters in
+ RTP), either the SIP MESSAGE method [21] 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 with 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. Addressing of Local Devices
+
+ As stated before, this document assumes both personal and public
+ devices. We assume that public devices use a dedicated Address of
+ Record (AOR), such as sip:device11@example.com. A personal device
+ already uses the owner's AOR, so that he should be reachable there;
+ that AOR could also be used for transferring sessions. However, it
+ is preferable to distinguish the role of a device as a transfer
+ target from its existing role. Therefore, all devices are assumed to
+ have dedicated AORs.
+
+ Since every transfer device has its own AOR, there is a one-to-one
+ mapping between AOR and device. Therefore, a transfer request could
+ be addressed to the AOR, which would resolve to the device. However,
+ in Section 5.4.3, we present a model where devices create multi-
+ device systems to pool their capabilities. Therefore, a single
+ device must be reachable by multiple URIs representing different
+ combinations of devices. The appropriate solution is to define each
+ combination of devices with a Globally Routable UA URI (GRUU) [12].
+
+ Therefore, we assume the following addressing for the remainder of
+ the document. As mentioned earlier, a device has a unique AOR. It
+ registers a separate contact URI for itself and for each system of
+ devices that it controls. Each contact has an associated GRUU, which
+ is registered with SLP as the Service URI, and may be directly
+ addressed by another device in a request sent through the proxy.
+ When the proxy forwards the request to the device, it will replace
+ the GRUU with the contact URI, as described in [12]. Therefore, the
+ contact URI, not the associated GRUU, will be used by devices to
+ determine whether the request is for the device itself or for a
+ multi-device system. We assume that the public GRUU is used.
+
+
+
+Shacham, et al. Informational [Page 9]
+
+RFC 5631 SIP Session Mobility October 2009
+
+
+5.3. Mobile Node Control Mode
+
+5.3.1. Transferring a Session to a Single Local Device
+
+5.3.1.1. RTP Media
+
+ local device 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 device used for the transfer, requesting that a new session be
+ established, but does not include an SDP body. The local device's
+ response contains an SDP body that includes the address and port 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
+ request (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
+
+
+
+Shacham, et al. Informational [Page 10]
+
+RFC 5631 SIP Session Mobility October 2009
+
+
+ Sending both audio and video media lines will transfer both media
+ sessions of an existing audio/video call to the local device.
+ Alternatively, the MN may select a subset of the media available on
+ the local device, and use the local device's parameters for those
+ media in the request sent to the CN, while continuing to use its own
+ parameters for the rest of the media. 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 from
+ the response received from the local device and put it in the request
+ sent to the CN, along with its own video parameters. The CN will
+ send 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 will send an ACK message to the local
+ device, which includes these parameters in the body. The MN will
+ establish a session with the local device and maintain its session
+ with the CN, while the media flow will be established directly
+ between the CN and the local device. Only the MN, who will be in an
+ ongoing session with the CN, will later be allowed to retrieve the
+ media session. Parsing of unknown SDP attributes by the controller
+ is discussed in [2].
+
+5.3.1.2. MSRP Sessions
+
+ In figure 2, the message sequence for transferring an MSRP message
+ session using MNC mode is identical to that used for audio or video,
+ 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 node, MSGN. In the following
+ flow, we refer to the corresponding messages in Figure 2. An empty
+ INVITE request (1) is sent to the local messaging node, MSGN, as
+ follows:
+
+ INVITE sip:msgn@example.com;gr=urn:uuid:jtr5623n SIP/2.0
+ To: <sip:msgn@example.com;gr=urn:uuid:jtr5623n>
+ From: <sip:bob@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):
+
+ SIP/2.0 200 OK
+ To: <sip:msgn@example.com;gr=urn:uuid:jtr5623n;tag=087js>;tag=087js
+ From: <sip:bob@example.com>;tag=786
+ Call-ID: 893rty@mn.example.com
+ Content-Type: application/sdp
+
+
+
+
+
+Shacham, et al. Informational [Page 11]
+
+RFC 5631 SIP Session Mobility October 2009
+
+
+ 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 (Transport Layer Security). 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, and open 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 endpoint 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
+ possibility, it is not currently included in this document 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, including its relay, in the
+ path attribute. For instance, the response from the MSGN will look
+ as follows:
+
+ SIP/2.0 200 OK
+ To: <sip:msgn@example.com;gr=urn:uuid:jtr5623n;tag=087js>;tag=087js
+ From: <sip:bob@example.com>;tag=786
+ Call-ID: 893rty@mn.example.com
+ Content-Type: application/sdp
+
+
+
+
+
+
+Shacham, et al. Informational [Page 12]
+
+RFC 5631 SIP Session Mobility October 2009
+
+
+ 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.3.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, the MN initiates separate sessions with
+ each of them, combines the audio media line from one response and the
+ video media 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. Informational [Page 13]
+
+RFC 5631 SIP Session Mobility October 2009
+
+
+ video_dev audio_dev MN CN
+ | |(1) INVITE no sdp | |
+ | |<-------------------| RTP Audio |
+ | |(2) 200 params | |
+ | |------------------->| |
+ | |(3) INVITE no sdp | |
+ |<---------------------------------------| |
+ | |(4) 200 params | |
+ |--------------------------------------->| |
+ | | |(5) INVITE a/v 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, such as a camera and a video display, 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 unidirectional
+ media, as is the case for a camera or display-only 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:
+
+
+
+
+
+
+
+
+Shacham, et al. Informational [Page 14]
+
+RFC 5631 SIP Session Mobility October 2009
+
+
+ m=video 50900 RTP/AVP 34
+ a=rtpmap:34 H263/90000
+ 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 views the new stream as a
+ replacement of the old 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. Informational [Page 15]
+
+RFC 5631 SIP Session Mobility October 2009
+
+
+5.3.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.4. Session Handoff (SH) mode
+
+5.4.1. Transferring a Session to a Single Local Device
+
+ Session Handoff mode uses the SIP REFER method [3]. This message is
+ a request sent by a "referrer" 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 referrer'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 Secure/Multipurpose Internet Mail Extensions (S/MIME) to
+ authenticate the REFER request. Figure 4 shows the flow for
+ transferring a session.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Shacham, et al. Informational [Page 16]
+
+RFC 5631 SIP Session Mobility October 2009
+
+
+ device15 MN CN
+ |(1) REFER | |
+ |<----------------------------| |
+ |(2) 202 Accepted | |
+ |---------------------------->| |
+ |(3) INVITE, Replaces | |
+ |-------------------------------------------------->|
+ | RTP |
+ |<..................................................|
+ |(4) 200 OK | |
+ |<--------------------------------------------------|
+ | RTP |
+ |..................................................>|
+ |(5) ACK | |
+ |-------------------------------------------------->|
+ | |(6) BYE |
+ | |<--------------------|
+ | |(7) 200 OK |
+ | |-------------------->|
+ |(8) NOTIFY | |
+ |---------------------------->| |
+ |(9) 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:device15@example.com;gr=urn:uuid:qfnb443ccui SIP/2.0
+ To: <sip:device15@example.com;gr=urn:uuid:qfnb443ccui>
+ From: <sip:bob@example.com>
+ Refer-To:<sip:corresp@example.com;gr=urn:uuid:bbb6981;audio;video?
+ Replaces="1@mn.example.com;
+ to-tag=bbb;from-tag=aaa">
+ Referred-By: <sip:bob@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 in the Refer-To
+ 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 in the URI is the Replaces header field,
+ specifying that a Replaces header field should be included with the
+ specified value in the subsequent INVITE request. The Replaces
+
+
+
+Shacham, et al. Informational [Page 17]
+
+RFC 5631 SIP Session Mobility October 2009
+
+
+ header identifies an existing session that should be replaced by the
+ new session. Here, the local device will request that the CN
+ replaces its current session with the MN with the new session.
+ According to [6], the CN should only accept a request to replace a
+ session from certain authorized categories 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 provides 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.
+
+ 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.4.2.
+
+ 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) indicates 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 feature tag, "message" has already
+ been defined [11]. 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Shacham, et al. Informational [Page 18]
+
+RFC 5631 SIP Session Mobility October 2009
+
+
+5.4.2. Retrieval of a Session
+
+ device15 MN CN
+ |(1) REFER | |
+ |<----------------------------| |
+ |(2) 202 Accepted | |
+ |---------------------------->| |
+ |(3) REFER | |
+ |---------------------------->| |
+ |(4) 202 Accepted | |
+ |<----------------------------| |
+ | |(5) INVITE, Replaces |
+ | |-------------------->|
+ | | RTP |
+ | |<....................|
+ | |(6) 200 OK |
+ | |<--------------------|
+ | | RTP |
+ | |....................>|
+ | |(7) ACK |
+ | |-------------------->|
+ | (8) BYE | |
+ |<--------------------------------------------------|
+ | (9) 200 OK | |
+ |-------------------------------------------------->|
+ | | |
+ | | |
+
+ Figure 5. Session Handoff mode flow for session retrieval.
+
+ Figure 5 shows the flow for retrieval by the MN of a session
+ currently on a local device. In order to better motivate the message
+ flow, we start by describing the final INVITE (5) and work backwards.
+ 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
+ (5):
+
+ INVITE sip:corresp@example.com;gr=urn:uuid:bbb6981 SIP/2.0
+ To: <sip:corresp@example.com;gr=urn:uuid:bbb6981>
+ From: <sip:bob@example.com>
+ Replaces: 1@device15.example.com;to-tag=aaa;from-tag=bbb
+ Referred-By: <sip:device15@example.com>
+
+ [S/MIME authentication body]
+
+
+
+
+
+
+Shacham, et al. Informational [Page 19]
+
+RFC 5631 SIP Session Mobility October 2009
+
+
+ Since the users on the MN and the local device are different
+ identities, 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. Also, the user may wish to execute the transfer while
+ running out of the office with mobile device in hand. In order for
+ the MN to prompt the REFER from the local device, it sends a "nested
+ REFER" [5], a REFER request for another REFER. 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 subsequent INVITE
+ request. The REFER request from the local device to the MN (3) is
+ composed as follows:
+
+REFER sip:bob@example.com;gr=urn:uuid:ytav223h67gb3 SIP/2.0
+To: <sip:bob@example.com;gr=urn:uuid:ytav223h67gb3>
+From: <sip:device15@example.com>
+Refer-To: <sip:correspondent@example.com;gr=urn:uuid:bbb6981;audio;
+ video?Replaces="1@device15.example.com;to-tag=aaa;
+ from-tag=bbb">
+Referred-By: <sip:device15@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:device15@example.com;gr=urn:uuid:qfnb443ccui SIP/2.0
+To: <sip:device15@example.com;gr=urn:uuid:qfnb443ccui>
+From: <sip:bob@example.com>
+Refer-To:<sip:bob@example.com;gr=urn:uuid:ytav223h67gb3;method=REFER
+ ?Refer-To="<sip:correspondent@example.com;gr=urn:uuid:bbb6981;
+ audio;video?Replaces=%221@device15.example.com;
+ to-tag=aaa;from-tag=bbb%221>">
+
+ The Refer-To header specifies that the MN is the refer target and
+ that the referral be in the form of a REFER request. The header
+ field specifies that the REFER request contains a Refer-To header
+ containing the URI of the CN. That URI, itself, contains 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 contains a Replaces header. If the MN had previously
+ transferred the session to the local device, it would have received
+
+
+
+Shacham, et al. Informational [Page 20]
+
+RFC 5631 SIP Session Mobility October 2009
+
+
+ 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 gets these parameters by subscribing to the
+ Dialog Event Package [13] 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 does not accept the
+ REFER request from anybody except the original participant in the
+ session or the owner of the device. The MN receives the REFER
+ request from the local device, sends the INVITE request to the CN,
+ which accepts it, and, once the session is established, terminates
+ its session with the local device.
+
+5.4.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", or a Multi-Device
+ System (MDS). We refer to the controlling device as the Multi-Device
+ System Manager (MDSM). In a system that includes at least one
+ mobility-enhanced device, one of them 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 acts as MDSM.
+ When the MDSM subsequently receives a REFER request, it uses third-
+ party call control to set up media sessions between the CN and each
+ device in the system. Specifically, it invites each local device
+ into a separate session, and uses their media parameters (and
+ possibly its own) in the INVITE request it sends to the CN.
+
+ A single device may act as an MDSM for several different groups of
+ devices, and also act as an ordinary device with only its native
+ capabilities. There must be a way to address a request to a device
+ and specify whether it is to the device itself or one of the multi-
+ device systems it controls. As mentioned above in Section 5.2, a
+ device registers a separate contact for itself and for each of its
+
+
+
+Shacham, et al. Informational [Page 21]
+
+RFC 5631 SIP Session Mobility October 2009
+
+
+ multi-device systems. For example, the device with AOR
+ "sip:device11@example.com" and hostname "device11.example.com" will
+ register a contact "sip:device11@device11.example.com" that
+ represents its own capabilities. Once it discovers other devices and
+ creates an MDS, it will register a new contact,
+ "sip:av1@device11.example.com". It associates a GRUU with each of
+ these contacts. The device itself and any new system is registered
+ in SLP using the GRUU. When the proxy receives a request addressed
+ to a GRUU, it will rewrite it as the contact URI before forwarding
+ the request to the device. The device will use this unique contact
+ to determine whether to handle the request natively or with one of
+ its systems.
+
+ Figure 6 shows the transfer of a session to a multi-device system.
+ The audio device has previously discovered the video device and
+ created a multi-device system. The REFER request sent to
+ "sip:device11@example.com;gr=urn:uuid:893eeeyuinm981" prompts the
+ audio device to invite the video device 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 device.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Shacham, et al. Informational [Page 22]
+
+RFC 5631 SIP Session Mobility October 2009
+
+
+ video audio MN CN
+ | |(1) REFER | |
+ | |<--------------------| |
+ | |(2) 202 Trying | |
+ | (3) INVITE no sdp |-------------------->| |
+ |<---------------------| | |
+ | (4) 200 OK SDP | | |
+ |--------------------->| | |
+ | |(5) INVITE a/v SDP, Replaces |
+ | |--------------------------------->|
+ | | RTP Audio |
+ | |<.................................|
+ | | RTP Video |
+ |<........................................................|
+ | |(6) 200 OK CN SDP |
+ | |<---------------------------------|
+ | | RTP Audio |
+ | (7) ACK CN Video SDP |.................................>|
+ |<---------------------| | |
+ | RTP Video | | |
+ |........................................................>|
+ | |(8) ACK | |
+ | |--------------------------------->|
+ | | |(9) BYE |
+ | | |<-----------|
+ | | |(10) 200 OK |
+ | | |----------->|
+ | | | |
+ | | | |
+
+ Figure 6. Session Handoff to a multi-device system.
+
+5.5. Distributing Sessions for Incoming Call
+
+ The examples presented above have involved an established session
+ that 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 proxying or 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
+
+
+
+Shacham, et al. Informational [Page 23]
+
+RFC 5631 SIP Session Mobility October 2009
+
+
+ SIP UA on the PC would, for any incoming call, send an INVITE request
+ to the desk phone, setting the display name in the From header field
+ 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 Correspondent Node 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 request 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 must ensure
+ the proper routing of the call. One solution would be for the PC to
+ register its contact with a higher priority than the one given to the
+ phone. The Call Processing Language (CPL) [22] (the "proxy" node)
+ could then be used to specify that forking should be done to the set
+ of user devices in sequence, rather than in parallel. Since all
+ calls would first be sent to the PC as long as it were online, it
+ would redirect any request that included only audio in its SDP.
+
+5.6. Use of ICE in Session Mobility
+
+ Interactive Connectivity Establishment (ICE) [27] is a protocol for
+ Network Address Translator (NAT) traversal that may be used with SIP.
+ Rather than negotiating addresses and ports used for media sessions
+ directly in SDP, a list of possible address/ports (candidates) is
+ exchanged, and the Session Traversal Utilities for NAT (STUN) [28]
+ protocol is used to check which pairs of candidates may be used. ICE
+ could be used in the call flows described in this section. In MNC
+ mode, the candidates would be sent by each local device to the MN,
+ who would exchange them with the CN. Afterward, each device would
+ perform checks with the CN to determine an appropriate candidate. In
+ SH mode, where the local device establishes a session with the CN,
+ ICE would work no differently than in the standard case.
+
+
+
+
+
+
+
+
+Shacham, et al. Informational [Page 24]
+
+RFC 5631 SIP Session Mobility October 2009
+
+
+6. Reconciling Device Capability Differences
+
+ Session mobility sometimes involves the transfer of a session between
+ devices with different 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 that must be taken into account
+ when carrying out a session transfer.
+
+6.1. Codec Differences
+
+ Before executing a session transfer, the device checks 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 is suggested to
+ be used to query the CN, while SLP is suggested to 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 flow will negotiate that this should become the codec used
+ in the media session. In MNC mode, the MN forwards the response from
+ the local device to the CN, who will choose a codec it supports from
+ those available. 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 during their session establishment. No special behavior
+ of the MN is required.
+
+ If the MN sees that a common codec does not exist, it executes the
+ transfer through an intermediate transcoding service. 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 discovers available transcoders through some means,
+ including SLP.
+
+ Using transcoding services in SIP is defined in [18] using third-
+ party call control. 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. This differs from the normal
+ transcoding case, where one party establishes a media session between
+ itself and the transcoder and one between the transcoder and the
+ other party. The MN starts by sending an INVITE request to the local
+ device with no body; it receives in the response the list of codecs
+ that the device can use. It then repeats this for the CN, and
+ receives its available codecs. It chooses one codec from each side,
+
+
+
+Shacham, et al. Informational [Page 25]
+
+RFC 5631 SIP Session Mobility October 2009
+
+
+ along with the address and port of each device, and combines them in
+ an INVITE request sent to the transcoder. The transcoder responds
+ with the ports on which it will accept each stream. The appropriate
+ port information is sent individually to the CN and the local device.
+ Once the three sessions have been established, two media sessions
+ exist, and the transcoder translates between them. This flow is
+ shown in Figure 7.
+
+ AN Transcoder MN CN
+(codec A) (codec B)
+ | |(1) INVITE no sdp | |
+ |<---------------------------------------| |
+ | |(2) 200 AN params | |
+ |--------------------------------------->| |
+ | | |(3) INVITE no sdp |
+ | | |---------------------->|
+ | | |(4) 200 OK CN params |
+ | | |<----------------------|
+ | |(5) INVITE AN, CN params | |
+ | |<---------------------------| |
+ | |(6) 200 OK TA, TB params | |
+ | |--------------------------->| |
+ | |(7) ACK | |
+ | |<---------------------------| |
+ | |(8) ACK TA params | |
+ |<---------------------------------------| |
+ | RTP | | |
+ |..........>| RTP | |
+ | |...................................................>|
+ | | | (9) ACK TB 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 node AN, where they share no common
+ codec.
+
+ In Session Handoff mode, the local device itself establishes 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].
+
+
+
+
+Shacham, et al. Informational [Page 26]
+
+RFC 5631 SIP Session Mobility October 2009
+
+
+6.2. Display Resolution and Bandwidth Differences
+
+ Other differences in device capabilities, such as display resolution
+ and bandwidth limitations, are also suggested to be reconciled during
+ transfer. 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 frame rate. 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 frame rate.
+
+ Changing the image resolution and frame rate requires no special
+ handling by the MN. An SDP format is defined [19] for specifying
+ these and other parameters for the H.263+ codec, for example. The
+ suitable image formats and corresponding MPIs (Minimum Picture
+ Interval, related to the frame rate) 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 2)
+ to the initial INVITE request sent by the MN includes this line in
+ the SDP body, and the MN then includes it in the INVITE request sent
+ to the CN (3). In Session Handoff mode, the local device includes
+ this parameter in the INVITE request sent to the CN (Figure 4,
+ message 3) after receiving the REFER request. If the local device is
+ not configured to include the supported image sizes during session
+ establishment, the information could be made available through SLP.
+ The MN then includes it in the INVITE request sent to the CN in
+ Mobile Node Control mode. However, this information is not sent in
+ Session Handoff mode unless the local device was configured to send
+ it. In both modes, the MN sends its own resolution and frame rate
+ preferences in the body of the INVITE request sent to retrieve the
+ 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
+
+
+
+Shacham, et al. Informational [Page 27]
+
+RFC 5631 SIP Session Mobility October 2009
+
+
+ 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 request 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
+ 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 request 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. An 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 to
+ the REFER request, and the BYE it sends to the CN on hang-up requires
+ no special handling.
+
+
+
+
+
+
+Shacham, et al. Informational [Page 28]
+
+RFC 5631 SIP Session Mobility October 2009
+
+
+9. Security Considerations
+
+ 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, providing media-level security following transfer, and the
+ issue of flooding attacks in MNC mode.
+
+9.1. Authorization for Using Local Devices
+
+ It is necessary that the use of a local device be limited to
+ authorized parties. As stated earlier, this document assumes both
+ personal and public devices, and these have different authorization
+ policies. A personal device only accepts transfer requests from a
+ single identity, the device owner. Therefore, the most appropriate
+ means of access control is to maintain a list of identities
+ representing the device owner authorized to transfer sessions to the
+ device. As mentioned before, the device is configured with an AOR
+ representing its status as a transfer device, in addition to the
+ user's AOR. Only requests made to the device AOR follow the access
+ list, while incoming requests to the user's AOR are accepted from
+ anyone (provided that a white or blacklist or other policy does not
+ preclude their request from being accepted). The SIP-Identity header
+ [25] is used to securely identify the initiator of a SIP request.
+ That specification can be used in our use-cases when the local device
+ must ensure that the INVITE or REFER request in MNC or SH mode,
+ respectively, is indeed from the owner of the device.
+
+ Public devices accept transfer requests from a large number of
+ identities. Access lists may be used for this purpose.
+ Alternatively, since devices are often available to categories of
+ users, such as "manager" or "faculty member", an appropriate solution
+ may be to use trait-based authorization [23]. Using this mechanism,
+ a user may acquire, from a trusted authorization service, an
+ "assertion" of his user status and permissions. The assertion, or a
+ reference to it, is included in the request to use the device.
+
+9.2. Maintaining Media Security During Session Mobility
+
+9.2.1. Establishing Secure RTP Using SDP
+
+ 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) [14] 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
+
+
+
+
+
+Shacham, et al. Informational [Page 29]
+
+RFC 5631 SIP Session Mobility October 2009
+
+
+ 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].
+
+ The establishment of secure RTP communications through SDP is defined
+ by two documents. The "crypto" attribute [15] 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 [16] 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 the 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. In this
+ document, the Mobile Node (MN) in Mobile Node Control mode (MNC) has
+ the role of controller in 3pcc, while in the Session Handoff (SH)
+ mode, MN uses the REFER method instead. 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
+
+
+
+Shacham, et al. Informational [Page 30]
+
+RFC 5631 SIP Session Mobility October 2009
+
+
+ prevent the controller from interfering with the initial exchanges
+ of keying materials. As a result, it is trivially possibl[e] 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
+ device, i.e., the MN user, there is even more reason to believe that
+ the controller will be well-behaved and will not interfere with the
+ initial transfer of key exchanges.
+
+9.2.2. Securing Media Using the Transport Layer
+
+ The exchange of media could alternatively be secured at the transport
+ layer, using either TLS or Datagram Transport Layer Security (DTLS)
+ [24]. The one consideration for use of these protocols in session
+ mobility would be assigning the client and server roles. In SH mode,
+ it may be assumed that the local device, the referee, would act as
+ the client, since it is initiating the signaling session with the CN.
+ However, in MNC mode, these roles would be unclear. The same problem
+ was mentioned above in establishing a secure connection for an MSRP
+ session transferred in MNC mode. This problem could be solved
+ through the use of Connection-Oriented Media (COMEDIA) [26], which
+ specifies the "setup" SDP attribute to negotiate these roles.
+
+ We describe here briefly how this is done. In the MNC exchange shown
+ in Figure 2, the local device chooses whether to specify a media
+ session over a secured transport in its response to the MN. If so,
+ it includes under the media line a "setup" attribute set to either
+ "active", "passive", or "actpass". This is sent on to the CN.
+ Assuming it agreed to such a session, it responds with a "setup"
+ attribute, as per the COMEDIA specifications. This is then sent by
+ the MN to the local device. If the local device and CN agreed on
+ their roles, the appropriate session could be established, through
+ which the media would be transmitted. Before they transmit media
+ between them, the CN and local device exchange messages to establish
+ the TLS or DTLS session. This same approach could be used to
+ establish an SRTP security context over DTLS, as per [31].
+
+9.3. Flooding Attacks in MNC Mode
+
+ The MNC call flows in this document, where one device instructs
+ another device to send an RTP flow to a third one, present the
+ possibility of a flooding attack. This is a general problem that
+ relates to any use of 3pcc. In this document, it is only a concern
+ where the device is public, as described at the beginning of this
+ section, and a large group of people can transfer media to it, since
+ there may not be a very strong trust relationship between the device
+
+
+
+Shacham, et al. Informational [Page 31]
+
+RFC 5631 SIP Session Mobility October 2009
+
+
+ owner (e.g., an institution) and the users. Obviously, where a
+ device is private and only its owner can transfer to it, the concern
+ does not exist, given the use of the Identity header mentioned
+ earlier. A possible solution may be the use of ICE [27], since both
+ sides confirm that they want to receive each other's media.
+
+10. Acknowledgments
+
+ We would like to acknowledge the helpful comments made about this
+ document by the SIP community, in particular Jon Peterson, Joerg Ott,
+ and Cullen Jennings.
+
+11. References
+
+11.1. Normative References
+
+ [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
+ Peterson, J., Sparks, R., Handley, M., 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)", BCP 85, 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
+ 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., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The
+ Message Session Relay Protocol (MSRP)", RFC 4975, September
+ 2007.
+
+ [8] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for the
+ Message Sessions Relay Protocol (MSRP)", RFC 4976, September
+ 2007.
+
+ [9] Hellstrom, G. and P. Jones, "RTP Payload for Text
+ Conversation", RFC 4103, June 2005.
+
+
+
+
+Shacham, et al. Informational [Page 32]
+
+RFC 5631 SIP Session Mobility October 2009
+
+
+ [10] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating
+ User Agent Capabilities in the Session Initiation Protocol
+ (SIP)", RFC 3840, August 2004.
+
+ [11] Camarillo, G., "Internet Assigned Number Authority (IANA)
+ Registration of the Message Media Feature Tag", RFC 4569, July
+ 2006.
+
+ [12] Rosenberg, J., "Obtaining and Using Globally Routable User
+ Agent URIs (GRUU) in the Session Initiation Protocol (SIP)",
+ RFC 5627, October 2009.
+
+11.2. Informative References
+
+ [13] Rosenberg, J., Schulzrinne, H., and R. Mahy, Ed., "An INVITE-
+ Initiated Dialog Event Package for the Session Initiation
+ Protocol (SIP)", RFC 4235, November 2005.
+
+ [14] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
+ Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
+ 3711, March 2004.
+
+ [15] Andreasen, F., Baugher, M., and D. Wing, "Session Description
+ Protocol (SDP) Security Descriptions for Media Streams", RFC
+ 4568, July 2006.
+
+ [16] Arkko, J., Lindholm, 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.
+
+ [17] Guttman, 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., Bormann, C., Sullivan, G., Wenger, S., and R. Even,
+ Ed., "RTP Payload Format for ITU-T Rec. H.263 Video", RFC 4629,
+ January 2007.
+
+ [20] Schulzrinne, H. and E. Wedlund, "Application-Layer Mobility
+ Using SIP", ACM SIGMOBILE Mobile Computing and Communications
+ Review, Vol. 4, No. 3, July 2000.
+
+
+
+
+
+Shacham, et al. Informational [Page 33]
+
+RFC 5631 SIP Session Mobility October 2009
+
+
+ [21] Campbell, B., Ed., Rosenberg, J., Schulzrinne, H., Huitema, C.,
+ and D. Gurle, "Session Initiation Protocol (SIP) Extension for
+ Instant Messaging", RFC 3428, December 2002.
+
+ [22] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing
+ Language (CPL): A Language for User Control of Internet
+ Telephony Services", RFC 3880, October 2004.
+
+ [23] Peterson, J., Polk, J., Sicker, D., and H. Tschofenig, "Trait-
+ Based Authorization Requirements for the Session Initiation
+ Protocol (SIP)", RFC 4484, August 2006.
+
+ [24] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+ Security", RFC 4347, April 2006.
+
+ [25] Peterson, J. and C. Jennings, "Enhancements for Authenticated
+ Identity Management in the Session Initiation Protocol (SIP)",
+ RFC 4474, August 2006.
+
+ [26] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the
+ Session Description Protocol (SDP)", RFC 4145, September 2005.
+
+ [27] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
+ Protocol for Network Address Translator (NAT) Traversal for
+ Offer/Answer Protocols", Work in Progress, October 2007.
+
+ [28] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session
+ Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
+
+ [29] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery",
+ Work in Progress, September 2008.
+
+ [30] Cheshire, S. and M. Krochmal, "Multicast DNS", Work in
+ Progress, September 2008.
+
+ [31] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for
+ Establishing an SRTP Security Context using DTLS", Work in
+ Progress, March 2009.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Shacham, et al. Informational [Page 34]
+
+RFC 5631 SIP Session Mobility October 2009
+
+
+Authors' Addresses
+
+ Ron Shacham
+ Columbia University
+ 1214 Amsterdam Avenue, MC 0401
+ New York, NY 10027
+ USA
+
+ EMail: shacham@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. Informational [Page 35]
+