Network Working Group J. Aartse Tuijn Internet-Draft University of Twente Intended status: Standards Track D. Bijwaard Expires: August 30, 2007 Alcatel-Lucent February 26, 2007 A method for network initiated partial session transfers draft-aartsetuijn-nipst-00 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 August 30, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 1] Internet-Draft Method for network initiated PST February 2007 Abstract This document describes a SIP-based method for network initiated partial session transfers that works together with terminal initiated partial session transfers. It uses the Mobile Node Control Mode for terminal initiated partial session transfers and it extends this method to support network initiated partial session transfers. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview of operation . . . . . . . . . . . . . . . . . . . . 6 3.1. Key concepts . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Component overview . . . . . . . . . . . . . . . . . . . . 6 3.3. Network initiated partial session transfer . . . . . . . . 7 3.4. Retrieval of a media-stream . . . . . . . . . . . . . . . 10 4. 'pst-control' option-tag . . . . . . . . . . . . . . . . . . . 12 5. The Pst-to header field . . . . . . . . . . . . . . . . . . . 13 6. Pst-call-id header . . . . . . . . . . . . . . . . . . . . . . 14 7. Behaviour of SSC . . . . . . . . . . . . . . . . . . . . . . . 15 8. Behaviour when receiving INVITE with 'pst-control' in Require header . . . . . . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9.1. Sender of proposal can be any node in the signalling path . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.2. Sudden disconnection of the MN . . . . . . . . . . . . . . 17 9.3. MN is informed about the existence of a LN . . . . . . . . 17 9.4. LN is informed about the IP-address of the CN . . . . . . 17 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 10.1. Pst-to and Pst-call-id headers . . . . . . . . . . . . . . 18 10.2. Option Tag . . . . . . . . . . . . . . . . . . . . . . . . 18 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 12. Normative References . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 22 Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 2] Internet-Draft Method for network initiated PST February 2007 1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 3] Internet-Draft Method for network initiated PST February 2007 2. Introduction As work in progress [shacham06] described, SIP Session Mobility is the seamless transfer of media of an ongoing communication session from one device to another. A system for session mobility is defined, aimed at allowing a Mobile Node (MN) to discover available nodes and to include them in an active session. [shacham06] also defines how the different parts of a session can be individually transferred to these devices, meaning the different stream endpoints in a multimedia-stream can each be transferred to another device, here called partial session mobility. Two methods are proposed, the Session Handoff mode and the Mobile Node Control Mode. With both these methods the Mobile Node (The mobile terminal used by the user) initiates the partial session transfer. This document describes how a partial session transfer can be initiated from a dedicated node located in the network such that Mobile Node initiated partial session transfers are still possible based on de described method in [aartsetuijn06] and the work in progress [shacham06]. Network initiated partial session transfers would typically be triggered by external events like network-side discovery of nearby multimedia devices like beamers. When the dedicated node in the network initiates a partial session transfers, the user may want to be involved in the decision; therefore the partial session transfer is proposed to the user- terminal to let the user decide about the actual execution of the partial session transfer. The following information is assumed to be necessary for the user decision: o Which media-stream endpoint will be transferred o The device to transfer the stream endpoint to o The media-parameters to be used for the media-stream after the transfer As described in [aartsetuijn06] the most applicable solution to base network initiated partial session mobility on is the Mobile Node Control Mode. Mechanisms for session transfer between a terminal's IP and circuit voice interface are specified in the 3GPP voice call continuity (VCC) standards [3GPP 23.279]. Contrary to this, the partial session mobility procedure described here targets usage of multiple SIP- enabled devices at each endpoint of a SIP session and the decision for suggesting partial session transfer comes from a (network) node that perceives which devices close to the SIP session endpoint can Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 4] Internet-Draft Method for network initiated PST February 2007 enhance the multimedia session. Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 5] Internet-Draft Method for network initiated PST February 2007 3. Overview of operation This section describes the operation of network initiated partial session mobility; the Mobile Node initiated partial session transfers are assumed to be handled with the Mobile Node Control Mode as described in [shacham06]. 3.1. Key concepts The Mobile Node Control Mode uses the capabilities of SDP [RFC4566] to transfer media-stream endpoints to different devices. Since the media-stream endpoints are controlled solely on the control plane, network initiated partial session mobility can be supported entirely on the control plane, while the actual media-streams are set up directly between the devices. A network node supporting network initiated partial session mobility should be part of all the session-specific SIP signalling of the nodes that want to use the service. This means the node can alter/ change and setup sessions on behalve of the involved nodes. A new session will be set up by the dedicated node in the network if it involves a new device to handle one or more media-streams. The sessions with other devices that help the Mobile Node (MN) handle media-streams are called sub-sessions A mobility session is defined as a session of a Mobile Node with is peer in a session, and the sub-sessions between the Mobile Node and the additional devices that are used in the session with the peer. Another important concept being used is using a proposal to let the user decide about the execution of a network initiated partial session transfer. This means the dedicated node located in the network must first propose a partial session transfer to the user or user-terminal, after which it is only executed if the user agrees with the proposed transfer. 3.2. Component overview The network node to initiate partial session mobility is called the sub-session controller (SSC); it acts as a SIP B2BUA. In IMS [3GPP 23.228] this would typically be implemented as an application server. The SSC can offer its service to each individual node on each individual session that has the SSC in its signalling path. In this document the MN is the user-terminal that the SSC is offering its service to. The MN does have an ongoing session with a corresponding node (CN). To accomodate the user-terminal other devices can be used as endpoint for the involved media-streams, these devices are called Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 6] Internet-Draft Method for network initiated PST February 2007 local nodes (LNs). Examples of LNs are an audio node (AN) that can play and record audio and a video node (VN) that can play and record video. Ofcourse LNs can also act only as source or target for media- streams. In case the CN also wants to use partial session mobility itself, it will play the role of MN in its own mobility session. This means a session between two devices can be represented by two mobility sessions, each of which contains the session between the two devices, but with each of the devices in another role. 3.3. Network initiated partial session transfer Before a partial session transfer can be initiated a session must exist. The SSC is located in the signalling path of this session, and it acts as a B2BUA. Figure 1 shows the message sequence diagram of a typical network initiated partial session transfer. Below this message sequence diagram is explained in more detail. To propose the partial session transfer to the user the SSC sends an INVITE message (1) to the MN. This message uses the option-tag 'pst- control' in the Required header field to make sure the MN can interpet the message correctly. If the MN does not accept the proposal it responses with 603 (Decline), as shown in Figure 2 , message (2). In that case the SSC should not proceed with the partial session transfer. Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 7] Internet-Draft Method for network initiated PST February 2007 AN MN SSC CN | | (1) INVITE | | | |<-----------------| | | | (2) 200 OK | | | |----------------->| | | | (3) ACK | | | |<-----------------| | | | | | | | | (4) INVITE | | | |--------------->| | | | (5) 200 OK | | | |<---------------| | | | | | | (6) INVITE | | | |<-----------------| | | | (7) 200 OK | | | |----------------->| | | | (8) ACK | | | |<-----------------| | | | | | | (9) INVITE no SDP | | | |<---------------------------------------| | | (10) 200 OK AN SDP | | | |--------------------------------------->| | | (11) ACK CN SDP | | | |<---------------------------------------| | | RTP Audio | | | |........................................................>| | | | (12) ACK | | | |--------------->| | RTP Audio | | | |<........................................................| | | | | Figure 1: Network initiated partial session transfer AN MN SSC CN | | (1) INVITE | | | |<-----------------| | | | (2) 603 DECLINE | | | |----------------->| | | | | | Figure 2: Decline of a network initiated partial session transfer Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 8] Internet-Draft Method for network initiated PST February 2007 As described in Section 2 it is assumed the MN need to know which media stream will be transferred, to which device it will be transferred, and with which media-parameters. To show to what device the media-stream will be transferred, a new header field is introduced for INVITE messages, namely the Pst-to header field. This header field contains the SIP-URI of the device the media-stream will be transferred to. To inform the MN about which media-stream will be transferred and with what media-parameters, the INVITE message meant as proposal contains a SDP-body. This SDP-body contains a session description proposal that will be sent to the CN when re-invited. By analyzing this session description and comparing it with the previous session description being offered to the CN, it knows which media-stream is being transferred, and what media-parameters will be used. Figure 4 contains an example of the SDP-proposal sent to the MN; the MN compares it to the last SDP session description it sent to the CN, shown in Figure 3. The MN can determine which media-stream will be transferred by looking at the Connection parameter; the media-stream that is being transferred uses another connection parameter. c=IN IP4 192.0.2.1 m=audio 24224 RTP/AVP 0 3 4 5 16 6 17 14 8 15 18 m=video 24222 RTP/AVP 34 26 31 33 Figure 3: SDP session setup c=IN IP4 192.0.2.1 m=audio 24224 RTP/AVP 0 3 4 5 16 6 17 14 8 15 18 c=IN IP4 192.0.2.2 m=video 25222 RTP/AVP 34 26 31 33 Figure 4: SDP proposal A new header field is added to the SIP INVITE message to inform the MN about the Call-id of the sub-session that will be set up with the target device of the transfer. The header containing this Call-id is called Pst-call-id. SSC might know all capabilities in advance, so it can invite the LD and CN more precisely. If it does not, it invites the LN without any SDP. The order in which the involved nodes are invited is important to the Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 9] Internet-Draft Method for network initiated PST February 2007 compatibility with SIPUAs. To make sure as much SIPUAs are supported as possible old media-streams first has to be stopped before new media-streams are being set-up as also described in [aartsetuijn06]. However this does mean a disruption in the media-streams. Figure 1 also illustrates this order by first inviting the MN (1) making sure the MN stops sending audio to the CN, then inviting the CN (4) making sure the CN stops sending audio to the MN and starts sending audio to the AN, and only after that inviting AN to let it send audio to CN. This sequence also makes sure multiple sources are not sending the media at the same time to the same endpoint. 3.4. Retrieval of a media-stream Retrieval of a media-stream can be initiated from both the terminal and network. In case the media-stream was transferred by the terminal, it can also easily be retrieved by the terminal as described in paragraph 5.3.2 of [shacham06]. If a media-stream was transferred by the SSC, the SSC can transfer the media-stream back to the MN by starting a network initiated partial session transfer. When the SSC has transferred a media-stream, and the MN wants to retrieve that media-stream, the MN knows about the transferred media- stream because it was informed by the proposal (INVITE-message) sent by the SSC. Because it has an up-to-date view on the current situation it is able to determine if a retrieval is necessary, and how it should be accomplished. Figure 5 shows the sequence diagram of this, where the MN only has to re-invite the CN to retrieve the audio-stream. Here the SSC does have the responsibility (As described in section Section 7) to make sure the sub-session with the AN is consistent with the session between the MN and CN. AN MN SSC CN | | (1) INVITE | | | |---------------------------------->| | | (2) 200 OK | | | |<----------------------------------| | | (3) ACK | | | |---------------------------------->| | | RTP Audio | | | |<..................................| | | | | | (4) BYE | | | |<---------------------------------------| | | (5) OK | | | |--------------------------------------->| | | | | | Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 10] Internet-Draft Method for network initiated PST February 2007 Figure 5: Retrieval by Mobile Node The other way arround, where the MN has transferred a media-stream, and the SSC intends to transfer that media-stream back to the MN, the SSC must have an up-to-date view on the current situation. Because the SSC acts as a B2BUA on every session that is related to the MN, it is able to process all changes made in the session(s). This way the SSC always has an up-to-date view of the current situation. Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 11] Internet-Draft Method for network initiated PST February 2007 4. 'pst-control' option-tag A new SIP option-tag called 'pst-control' is defined for the Require and Supported header fields. A user agent including the 'pst-control' option-tag in a header field indicates compliance with this specification. This 'pst-control' option-tag may be included in the Require header field of re-INVITE's sent by a B2BUA. Nodes controlled by end-users should not use this option-tag in the Require header field. A B2BUA that wants to propose a partial session transfer to a certain node for a specific call must include the 'pst-control' option-tag in the Require field of the re-INVITE message that represents the proposal. When the 'pst-control' option-tag is present in an INVITE request, it also MUST contain a Pst-to header field and a Pst-call-id header field. Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 12] Internet-Draft Method for network initiated PST February 2007 5. The Pst-to header field The Pst-to header field can appear in INVITE requests where the 'pst- control' option-tag has been set. This field contains the SIP-URI of the device the media-stream will be transferred to. The following is the ABNF (augmented Backus-Naur Form) for the Pst-to header field: Pst-to = "Pst-to" HCOLON ( name-addr / addr-spec ) * (SEMI generic- param) Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 13] Internet-Draft Method for network initiated PST February 2007 6. Pst-call-id header The Pst-call-id header field can appear in INVITE requests where the 'pst-control' option-tag has been set. This field contains the call-id of the sub-session that will be set up with the device identified by the Pst-to header field. The following is the ABNF (augmented Backus-Naur Form) for the Pst-call-id header field: Pst-call-id = "Pst-call-id" HCOLON callid Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 14] Internet-Draft Method for network initiated PST February 2007 7. Behaviour of SSC When the SSC wants to offer a partial session transfer to a user, it sends an INVITE request to the MN containing the 'pst-control' option-tag in the Required header, the Pst-to header field to indicate the targer of the transfer, the Pst-call-id header field to identify the sub-session being set up with the target device and the SDP-body to indicate what stream is being transferred and what the parameters of it are after the transfer. In case the SSC recieves a 306 response (Decline), meaning the MN does not want the proposed partial session transfer to be executed, the SSC does not continue with the execution. When the MN does not support pst-control it will respond with a 420 response (Bad Extension), while the Unsupported header field contains the 'pst- control' option-tag. The behaviour of the SSC in case the MN does not support pst-control is implementation specific. The SSC could for example use user preferences to determine if it should continue or stop the execution of the partial session transfer. Besides a network initiated partial session transfer, a partial session transfer can also be initiated by the user-terminal. This influences the way how the sub-sessions are handled and by which node they are handled. In case the MN supports pst-control, the node that made the last change to a sub-session is responsible for that specific sub-session. This responsibility consists of making sure the sub-session is consistent with the session between the MN and CN. In case the MN does not supports pst-control, the SSC is always responsible for the sub-sessions. Because the SSC act as a B2BUA that is located in the signalling path of all sessions between the device that acts as MN and it peers, it receives all messages of the involved nodes and must interpet them and make sure these messages are forwarded to other nodes accordingly. As described above, if the SSC is responsible for a certain sub-session it must make sure the sub-session remains consistent with the session between the CN and MN. This includes changes to a sub-session by the involved LN, where the SSC must make sure the sub-session and session between the MN and CN remains consistent. The exact behaviour necessary is considered implementation specific. Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 15] Internet-Draft Method for network initiated PST February 2007 8. Behaviour when receiving INVITE with 'pst-control' in Require header When a node receives an INVITE message with the option tag 'pst- control' in the Required header according to SIP [RFC3261] it should only process the message further if it supports the specified extension. In case it does not supports this extension it response with a 420 response (Bad Extension). In case the receiving node does support the extension it can decline (306 response) or accept (200 response) the proposed partial session. Which one applies depends should depend on what the user wants. This could for example mean user-interaction is necessary before the proposal is accepted or decline. Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 16] Internet-Draft Method for network initiated PST February 2007 9. Security Considerations All security considerations as described in [shacham06] also apply for this proposal. Besides those considerations here some other are described that are related to network initiated partial session transfers. 9.1. Sender of proposal can be any node in the signalling path The INVITE send to the MN to propose a partial session transfer can virtually be send by any node in the signalling path of a certain session. 9.2. Sudden disconnection of the MN In case a media-stream has been transferred to a LN and the MN suddenly disconnects, that specific media-stream does not stop working; it only stops when the LN or CN disconnects, or the LN, CN or SSC uses signalling to stop the media-stream. The proposed method does not contain a mechanism to register sudden disconnects, so one of the involved nodes can take appropriate actions. 9.3. MN is informed about the existence of a LN In case of a network initiated partial session transfer, the MN is informed about the existence of the involved LN at the moment it receives the proposal for the partial session transfer (At (1) in Figure 1. It is the task of the SSC to make sure a LN is only exposed to nodes that are trusted. No mechanism has been defined for this. 9.4. LN is informed about the IP-address of the CN At the moment the MN accepts a transfer, the involved LN is informed about the IP-address of the CN to inform the AN to send or receive media from the CN (At (9) in Figure 1). The CN might not want other nodes beside the MN to know about its IP-address. Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 17] Internet-Draft Method for network initiated PST February 2007 10. IANA Considerations Section 27 of RFC 3261 [RFC3261] creates an IANA registry for method names, header field names, warning codes, status codes, and option tags. This specification defines two new SIP header fields and a SIP option tag. 10.1. Pst-to and Pst-call-id headers This document defines two new SIP header fields: Pst-to and Pst-call-id. These header fields needs to be registered by the IANA in the SIP Parameters registry under the Header Field subregistry 10.2. Option Tag This section defines a new option tag per guidelines in Section 27.1 of RFC 3261 [RFC3261]. Name: pst-control Description: This option tag is used to identify support for client control of network initiated partial session transfers. When present in a Supported header field, it indicates that an agent supports controlling a network initiated partial session transfer. Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 18] Internet-Draft Method for network initiated PST February 2007 11. Acknowledgements The work described in this Internet-Draft is based on results of IST FP6 Integrated Project DAIDALOS. DAIDALOS receives research funding from the European Community's Sixth Framework Programme. Apart from this, the European Commission has no responsibility for the content of this Internet-Draft. The information in this document is provided as is and no guarantee or warranty is given that the information is fit for any particular purpose. The user thereof uses the information at its sole risk and liability. Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 19] Internet-Draft Method for network initiated PST February 2007 12. Normative References [3GPP 23.228] 3GPP, "TS 23.228: IP Multimedia Subsystem (IMS) (Stage 2), Release 7", December 2005. [3GPP 23.279] 3GPP, "TS 23.279: Combining Circuit Switched (CS) and IP Multimedia Subsystems (IMS) services, Release 7", December 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] 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. [RFC4566] Handley, M., Jacobsen, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [aartsetuijn06] Aartse Tuijn, J., "Partial session mobility in context aware IP-based multimedia subsystems", december 2006. [shacham06] Shacham, R., Schulzrinne, H., Thakolsri, S., and W. Kellerer, "Session Initiation Protocol (SIP) Session Mobility", November 2006. Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 20] Internet-Draft Method for network initiated PST February 2007 Authors' Addresses Jasper Aartse Tuijn University of Twente Calslaan 1-309 Enschede 7522MH The Netherlands Email: j.aartsetuijn@student.utwente.nl Dennis Bijwaard Alcatel-Lucent Capitool 5 Enschede 7521PL The Netherlands Email: bijwaard@alcatel-lucent.com Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 21] Internet-Draft Method for network initiated PST February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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, THE IETF TRUST 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). Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 22]