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]