SIPPING Working Group D. Bijwaard Internet-Draft Alcatel-Lucent Intended status: Informational J. Aartse Tuijn Expires: December 13, 2007 University of Twente / Care-Mail June 11, 2007 Requirements for third-party initiated partial session transfers draft-bijwaard-sipping-tpipst-requirements-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 December 13, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Bijwaard & Aartse Tuijn Expires December 13, 2007 [Page 1] Internet-Draft Third-party initiated PST requirements June 2007 Abstract Partial session mobility is defined as moving part of an active multimedia session to another device. Partial session mobility can be triggered both from a terminal as from a third-party node. This document describes the requirements for SIP-based third-party initiated partial session transfers that works together with terminal initiated partial session transfers. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. High-level requirements . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4.1. Sender of proposal can be any third-party node . . . . . . 8 4.2. Sudden disconnection of the SIP UA . . . . . . . . . . . . 8 4.3. SIP UA is informed about the existence of a involved node . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.4. Involved node is informed about the IP-address of the communication peer . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 7. Normative References . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Bijwaard & Aartse Tuijn Expires December 13, 2007 [Page 2] Internet-Draft Third-party initiated PST requirements June 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]. Bijwaard & Aartse Tuijn Expires December 13, 2007 [Page 3] Internet-Draft Third-party initiated PST requirements June 2007 2. Introduction As work in progress [shacham06] described, SIP [RFC3261] 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. This document describes the requirements for third-party-initiated partial session mobility, i.e. partial session mobility initiated by a third-party. The work in progress [aartsetuijn07] describes a method that meets most of these requirements and was a result of [aartsetuijn06] in which existing methods were also compared. Third- party initiated partial session transfers would typically be triggered by external events like third-party discovery of nearby multimedia devices like beamers. Since these multimedia devices are often stationary, the third-party could use a static map of devices and only has to keep track of the location of the user terminal in relation to devices in this static map. Bijwaard & Aartse Tuijn Expires December 13, 2007 [Page 4] Internet-Draft Third-party initiated PST requirements June 2007 3. High-level requirements This section describes the high-level requirements for third-party initiated partial session mobility. The requirements are listed in Table 1 below and most contain background and examples. +-------+-----------------------------------------------------------+ | Req.# | Requirement | +-------+-----------------------------------------------------------+ | 1. | It should be possible to transfer different parts (stream | | | enpoints) of an existing multimedia-session individually | | | to other nodes. This is a basic requirement to enable | | | both user-initiated and third-party initiated partial | | | session mobility. | | | | | 2. | A third-party should be able to propose a transfer of a | | | stream endpoint to a SIP UA and get a related response | | | for agreement or disagreement. The following information | | | are deemed necessary for the SIP UA to agree of disagree | | | to such a transfer: which stream endpoint is to be | | | transferred; to what node the stream endpoint is to be | | | transferred; the proposed media-parameters. E.g. when the | | | user does not know what stream endpoint is transferred | | | where and with what quality, (s)he is less likely to | | | agree to the transfer. Additionally, this information | | | would be necessary if the user wants to close or transfer | | | the stream elsewhere afterwards. | | | | | 3. | A third-party should be able to initiate a transfer of a | | | stream endpoint in a session to another node after | | | agreement by the SIP-UA that is responsible for this | | | endpoint. This agreement can be in advance for all | | | sessions or per transfer proposal as in Requirement 2. | | | The advantage of having a third-party to initiate a | | | transfer is that a SIP UA does not necessarily need | | | support for partial session mobility (and associated | | | device discovery) itself, it only needs to be able to | | | agree in advance or per session. A likely candidate | | | solution for the third-party initiation is a B2BUA that | | | also knows or can easily obtain information about other | | | registered devices. We could imagine a conference hotel | | | where all SIP-enabled beamers, cameras, TVs and hifi-sets | | | have a fixed location, in this case the third-party only | | | has to track the location of the user device to find | | | candidate devices for his/her session. | | | | Bijwaard & Aartse Tuijn Expires December 13, 2007 [Page 5] Internet-Draft Third-party initiated PST requirements June 2007 | 4. | Partial session mobility should be possible at least in a | | | limited way for RFC 3261 complient SIP UAs. In order to | | | get partial session mobility being used, it helps when it | | | also works with off-the-shelf user agents, so everybody | | | can use and experience it. This usage (with possibly | | | limited functionality) may drive the need for more | | | advanced UAs that can also handle partial session | | | mobility themselves. | | | | | 5. | A SIP UA should be able to transfer a stream endpoint of | | | an ongoing SIP session. This is to enable initiating | | | partial session transfers from an advanced SIP user | | | agent. E.g. when entering a conference room, the user may | | | want to initiate the transfer of video in his session | | | from the beamer in that room back to his/her mobile | | | device. This also keeps the user in control and would | | | enable him/her to undo a transfer by transferring it | | | back, or to transfer an already transferred stream to | | | another device. | | | | | 8. | A SIP UA should be able to close the multimedia-session | | | in which a stream endpoint was transferred. This is to | | | keep the user in control, (s)he may not be able to | | | control the devices in the conference room himself, but | | | (s)he should at least be able to close the session | | | including the part that was transferred to the beamer. | | | | | 8. | It should be possible to transfer a transferred stream | | | endpoint back or elsewhere from a third-party node (see | | | req. 3). For SIP UAs that do not support partial session | | | mobility themselves, this is required to move the stream | | | back to the user device, and also to not have to move it | | | back to the user device first when a better candidate | | | device is found or when the other one fails. | | | | | 9. | It should be possible for a third-party to close the | | | multimedia session in which it transferred a stream | | | endpoint, i.e. including the transferred stream endpoint. | | | This is to be able to close a session after failure of | | | the original user agent on behalf of which a stream | | | endpoint was transferred. The battery of the user device | | | could have run out, or it could have crashed. | | | | | 10. | There should be a (SIP) session relationship (here called | | | sub-session) between the node to which a stream endpoint | | | was moved and the node that initiated the transfer of the | | | stream endpoint. This session relationship is needed to | | | be able to change or close the session afterwards. | Bijwaard & Aartse Tuijn Expires December 13, 2007 [Page 6] Internet-Draft Third-party initiated PST requirements June 2007 | 11. | The node to which a stream endpoint was moved should be | | | able to close the sub-session described in req 10. This | | | closing is to enable e.g. a beamer in a conference room | | | that is reserved at a specified time for another user. | | | The node (third-party or user) that inititiated the | | | transfer is responsible to move the stream back to the | | | user device or elsewhere, since it has the session | | | relationship (req. 10) with the node that closes the | | | sub-session. | | | | | 12. | The initiator (third-party or user) of the partial | | | session transfer should have control on the | | | mediaparameters of a transferred media-stream. This means | | | the node initiating the partial session transfer should | | | be able to propose the media-parameters (e.g. the codec) | | | to be used in a SDP [RFC4566] body. When the initiator | | | would not be able to propose these parameters, they may | | | not be compatible with the peer in the session which | | | would result in a discontinued media stream. | | | | | 13. | For the transfer of a stream endpoint, the session (req. | | | 9) with the new node should be setup before breaking the | | | old stream (make before break). Without make before | | | break, the users in the session may experience gabs in | | | their communication or their communcation discontinues | | | when the session setup with the new endpoint fails. | | | | | 14. | A solution for partial session mobility should not be | | | incompatible with general use of SIP sessions. | | | | | 15. | Both third-party and terminal initiated partial session | | | mobility should exploit the existing possibilities of SDP | | | and SIP. | +-------+-----------------------------------------------------------+ Table 1 Bijwaard & Aartse Tuijn Expires December 13, 2007 [Page 7] Internet-Draft Third-party initiated PST requirements June 2007 4. 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 third-party initiated partial session transfers. 4.1. Sender of proposal can be any third-party node The proposal for a partial session transfer can virtually be send by any third-party node, but this third-party needs to be aware of a certain session. This likely means that the third-party is in the signaling path between the user and its peer. 4.2. Sudden disconnection of the SIP UA In case a media-stream has been transferred to another node and the SIP UA of the user suddenly disconnects, that specific media-stream does not stop working; it only stops when that node or the peer in the session disconnects, or when that node, the peer in the session, or a third-party node uses SIP signalling to stop the media-stream. 4.3. SIP UA is informed about the existence of a involved node In case of a third-party initiated partial session transfer, the SIP UA is informed about the existence of the involved node at the moment it receives a proposal for the partial session transfer. It is the task of the third-party node that proposes the transfer to make sure an involved node is only exposed to nodes that are trusted. 4.4. Involved node is informed about the IP-address of the communication peer At the moment the SIP UA accepts a transfer, the involved node is informed about the IP-address of the peer in the original session This peer might not want other nodes beside the SIP UA to know about its IP-address. Bijwaard & Aartse Tuijn Expires December 13, 2007 [Page 8] Internet-Draft Third-party initiated PST requirements June 2007 5. IANA Considerations This document does not require actions by the IANA. Bijwaard & Aartse Tuijn Expires December 13, 2007 [Page 9] Internet-Draft Third-party initiated PST requirements June 2007 6. 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. Bijwaard & Aartse Tuijn Expires December 13, 2007 [Page 10] Internet-Draft Third-party initiated PST requirements June 2007 7. Normative References [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. [aartsetuijn07] Aartse Tuijn, J. and D. Bijwaard, "A method for network initiated partial session transfers: draft-aartsetuijn-nipst-00", February 2007. [shacham06] Shacham, R., Schulzrinne, H., Thakolsri, S., and W. Kellerer, "Session Initiation Protocol (SIP) Session Mobility: draft-shacham-sipping-session-mobility-03", November 2006. Bijwaard & Aartse Tuijn Expires December 13, 2007 [Page 11] Internet-Draft Third-party initiated PST requirements June 2007 Authors' Addresses Dennis Bijwaard Alcatel-Lucent Capitool 5 Enschede 7521PL The Netherlands Email: bijwaard@alcatel-lucent.com Jasper Aartse Tuijn University of Twente / Care-Mail Calslaan 1-309 Enschede 7522MH The Netherlands Email: j.aartsetuijn@care-mail.nl Bijwaard & Aartse Tuijn Expires December 13, 2007 [Page 12] Internet-Draft Third-party initiated PST requirements June 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). Bijwaard & Aartse Tuijn Expires December 13, 2007 [Page 13]