SIPPING WG Xu Mingqiang Internet Draft Daisaku Komiya Expires: September 2005 Sachiko Kawaguchi Mahfuzur Rahman Brijesh Kumar Panasonic March 31, 2005 Indicating Media Handling Feature in Session Initiation Protocol (SIP) for Seamless Session Mobility draft-mingqiang-sipping-session-mobility-media-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 September 30, 2005. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract Session mobility allows a user to transfer an ongoing communication session from one device to another device. Seamless session mobility is very important for real time multimedia applications. This document defines a new option tag in SIP to indicate media handling feature during the transfer of communication session from one device to another device to achieve seamless session transfer without disruption of media streams. Mingqiang, et al. Expires September, 2005 [Page 1] Internet Draft session-mobility-media March 31, 2005 The new media handling option tag is to be used in the Require SIP header. This document also defines a new media feature tag, which can be used in the Contact header field (instead of the new option tag) to enable seamless session transfer without disruption of media. Table of Contents 1. Introduction.................................................3 2. Terminology and Conventions..................................5 3. Scope........................................................5 4. Application Scenario.........................................6 5. Examples and Message Flow Diagrams...........................8 5.1. Example of new Option-Tag..................................9 5.2. Example of New Media Feature Tag..........................11 6. IANA Considerations.........................................12 6.1. SIP Option Tag Registration...............................12 6.2. Media Feature Tag Registration............................12 7. Security Considerations.....................................13 8. References..................................................13 9. Authors' Addresses..........................................14 Mingqiang, et al. Expires September, 2005 [Page 2] Internet Draft session-mobility-media March 31, 2005 1. Introduction Session mobility allows a user to transfer an ongoing communication session from one device to another device. The general approach to achieve session mobility in SIP [1] including discovery process to locate transfer target devices, and signaling needed for the transfer of session has been described in [2]. One of the requirements for session mobility is: o REQ: Session transfer should be as seamless as possible. It should involve minimum disruption of media flow and should not appear to the remote participant as a new call [2]. This document addresses this particular requirement. One of the most critical issues of session mobility is to avoid disruption of media distribution while tearing down an existing media stream and establishing a new stream. Session transfer from one device to another needs to deal with two types of delays both of which need to be dealt with to have seamless mobility from one device to another device. The first source of potential session discontinuity is the time to complete the necessary control signaling for session transfer between communicating devices including discovering and selecting a target device for session transfer. The second source of discontinuity is the media stream interruption caused by the session transfer from an original receiving device to the new one. The discontinuity in media stream is typically referred as playing "lapse", and is explained in the next paragraph. Mingqiang, et al. Expires September, 2005 [Page 3] Internet Draft session-mobility-media March 31, 2005 Starting a streaming application at the receiver usually takes some time which MAY involve reading system parameters and initializing local buffer. Streaming clients typically have a receiver buffer that is capable of storing a relatively large amount of data [8]. Initially, when a streaming session is established, a client does not start playing the stream back immediately. Rather, it typically buffers the incoming data in a play back buffer for a short duration. This duration could range from a few milliseconds to a few seconds depending upon the property of the decoder at the receiver. This buffering at the receiver helps maintain continuous playback. In the event of occasional increased transmission delays or network throughput drops, the client can decode and play buffered data. Otherwise, without initial buffering, the client has to freeze the display, stop decoding, and wait for incoming data. Therefore, in order for a session transfer to be seamless, we need to parallelize the process of selecting the transfer target device and creating the necessary playback buffer at the target device to eliminate pre-roll delay. We define pre-roll delay as the time that it takes for the receiver buffer to fill to a desired level so that playback can begin instantly. The SIP REFER based session transfer mechanism as specified in [2] clearly is inadequate to deal with the lapse caused by the disruption of media stream at the new receiver. This document proposes a new mechanism, which prepares the target receiver in advance of session transfer to receive the media stream so that the session switching is done with minimal delay. This mechanism also ensures that buffering delay is no longer an issue, and the user can enjoy the continuous media stream without any loss of contents. This document defines a new option tag in SIP namely "bufferonly" to indicate how to handle media such as whether to display or buffer the media during the transfer of session. We also define a new media feature tag, namely "mediahandling", that can also be used in the Contact header field to indicate to the SIP UA how to handle the media. The use of Contact header to indicate capability or features has already been discussed in RFC 3840 [3]. When the Contact header field contains the "mediahandling" tag, it should be treated as an indication to the SIP UA that the value of the tag will indicate whether the media should be displayed or buffered. The mechanisms of how to use the new option tag and the new media feature tag to accomplish seamless session mobility are described in the following sections. Mingqiang, et al. Expires September, 2005 [Page 4] Internet Draft session-mobility-media March 31, 2005 2. Terminology and Conventions Device: A software or hardware appliance, which is represented by a SIP UA. PAN (Personal Area Network): PAN is a collection of one or more logically associated devices that share the same physical communication medium within a close proximity of each other (e.g., network formed by devices that can be accessed by near field radio like Bluetooth). Session [4]: A set of media senders and receivers and the data streams flowing from senders to receivers. Session Mobility: The mechanism that allows a user to transfer an ongoing communication session from one device to another device. Seamless Session Mobility: The mechanism of transferring an ongoing communication session with minimal delay from one device to another device without any perceivable disruption of media streams from a user's perspective. Target Device: A device to which a user wishes to switch an existing session. In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [5] and indicate requirement levels for compliant implementations. 3. Scope The new SIP option tag and new media feature tag are only defined to indicate to a SIP UA how the media of a communication session should be handled during the process of session transfer. These two SIP extensions are intended to transfer an ongoing communication session from one device to another device without disruption of media flow and they can be also used in other applications where indications of such media handling features are necessary. Mingqiang, et al. Expires September, 2005 [Page 5] Internet Draft session-mobility-media March 31, 2005 4. Application Scenario Figure 1 shows a typical application scenario of session mobility, which is achieved using SIP REFER [6] method. There are three components in this application participating in session mobility: The Correspondent Node (CN), Mobile Node (A) and a Target Device (B). The Correspondent Node (CN) is a basic multimedia content endpoint and the Mobile Node (A) is a basic SIP user agent capable of receiving content from the Correspondent Node (CN) by establishing a SIP session. The Mobile Node (A) chooses the Target Device (B) to transfer session from A to B. The Mobile Node (A) discovers the Target Device (B) using a suitable service/device discovery mechanism after A forms a Personal Area Network with devices around it. The Target Device (B) is also a typical SIP user agent capable of handling REFER mechanism. In this application scenario the Mobile Node (A) has established a video call with the Correspondent Node (CN). A moves to a new location and forms a PAN with devices around it. A then discovers the device B that has higher display resolution. A decides to continue the session on A with CN, but would like to watch the video on B instead of A. In the typical case, A would send a REFER message to B asking B to establish a session with CN. B will send an INVITE message to CN to establish a session with CN so that B can receive media stream directly from CN. Once the session is established between CN and B, B will start receiving the media stream and the user can view the video on device B. +-----+ | CN | +-----+ | +-----------------------+ | Network | +-----------------------+ | | +-----+ Refer +-----+ | A |--------> | B | +--+--+ +--+--+ Figure 1: Session mobility using REFER Even though the REFER method can be used to receive media from CN to B, the launch of the application in B usually takes some time after the REFER is accepted. There is also an unexpected delay to establish a session between CN and B. Moreover, there is also delay to buffer media in B, therefore, it may take several seconds before the user can actually view the video on B by just using the REFER method. Mingqiang, et al. Expires September, 2005 [Page 6] Internet Draft session-mobility-media March 31, 2005 To solve the problem of application setup delay and ensure non- disruptive transfer of a session several additional steps are needed in addition to using the SIP REFER method. To initiate a seamless session transfer, the Mobile Node (A) first forms a PAN (Personal Area Network) with the devices around it. After device discovery process is completed, A starts sending media streams using multicast to all the devices in the PAN which could be a potential target for the session transfer. For example, a mobile device may discover multiple devices with large screen display in its PAN. The user input or some other criteria may be used to select the actual session transfer target device. By establishing media sessions in advance of actual target selection, each device is ready to receive the session by building necessary buffer. Before A selects a Target Device media stream sent by A should not be displayed on the potential target devices around A. The devices in the PAN needs an indication that the received media are only to be used for buffering purposes and should not be displayed on the device. We propose a new option tag in SIP to accomplish this goal. We also propose a new media handling feature tag that could also be used instead of the new option tag to indicate media handling feature. The new option tag and the media feature tag are defined in the IANA considerations section. Once A selects the Target Device B by sending another INVITE message, only then can B start displaying the media stream. Once B starts displaying the media, REFER will be sent to B by A, and B can start receiving media directly from CN by establishing a session with CN. Mingqiang, et al. Expires September, 2005 [Page 7] Internet Draft session-mobility-media March 31, 2005 5. Examples and Message Flow Diagrams Figure 2 shows the message flow diagram for seamless session transfer without disruption of media stream displayed to the user. +------+ +-------+ +--------+ | A | | B | | CN | +------+ +-------+ +--------+ |<====================================| | F1 INVITE | | |---------------->| | | 200 OK | | |<----------------| | | ACK | | |---------------->| | |================>| | | F2 INVITE | | |---------------->| | | 200 OK | | |<----------------| | | ACK | | |---------------->| | | REFER | | |---------------->| | | 202 Accepted | | |<----------------| | | | INVITE | | |-----------------> | | | 200 OK | | |<----------------- | | | ACK | | |-----------------> | | |<================= | Figure 2: Example flow for seamless session mobility Mingqiang, et al. Expires September, 2005 [Page 8] Internet Draft session-mobility-media March 31, 2005 5.1. Example of new Option-Tag According to Figure 2, A is receiving media streams from CN. F1 is sent by A to all possible target devices around it (including B) to establish sessions with devices in PAN. The F1 INVITE message includes "bufferonly" option-tag and it is carried in the Require header field. The devices receiving this INVITE request interpret this INVITE message as a "bufferonly" media session and hence do not display the media streams. As a result of this INVITE, the media application at the receiver is started, the media playback buffer is initialized and the stream is buffered in the local buffer. These steps MAY take some time at the receiver. Since the receiver at B is not required to play the stream at this point, the delay in these steps is hidden from the user. Mingqiang, et al. Expires September, 2005 [Page 9] Internet Draft session-mobility-media March 31, 2005 F1: INVITE A -> B INVITE sips:bob@pdnl.example.com SIP/2.0 Via:SIP/2.0/TLS client.pdnl.example.com:5061;branch=z9hG4bK74bf9 Max-Forwards: 70 From: Alice ;tag=1234567 To: Bob Call-ID: 12345600@ndc.example.com CSeq: 314159 INVITE Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Require: bufferonly Content-Type: application/sdp Content-Length:... Once A selects B as the target device for session transfer, A sends F2 INVITE (re-Invite) message to B to update the session between A and B. The F2 message does not include "bufferonly" SIP option-tag in this instance and hence media streams for this session are displayed in B. Since B has an existing buffer, the media is played instantly without any delay. F2: INVITE A->B INVITE sips:bob@pdnl.example.com SIP/2.0 Via: SIP/2.0/TLS client.pdnl.example.com:5061;branch=z9hG4bK74bf9 Max-Forwards: 70 From: Alice ;tag=1234567 To: Bob ;tag=7654321 Call-ID: 12345600@ndc.example.com CSeq: 314160 INVITE Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Content-Type: application/sdp Content-Length: ... Once the session between A and B is updated and media streams are being displayed in B, A sends REFER message to B. Once B receives the REFER, B sends INVITE message to CN to establish a session with CN, and start receiving media streams directly from CN. Because B already has the buffer, it can instantly and seamlessly switch to CN to be the source of the media stream. Mingqiang, et al. Expires September, 2005 [Page 10] Internet Draft session-mobility-media March 31, 2005 5.2. Example of New Media Feature Tag According to Figure 2, A is receiving media streams from CN. F1 is sent by A to all the possible target devices around it (including B) to establish media sessions with devices in PAN. The Contact header field of F1, includes the media feature tag, mediahandling="bufferonly". The devices receiving this INVITE request interpret this INVITE message as a "bufferonly" session and hence do not display the media streams. F1: INVITE A -> B INVITE sips:bob@pdnl.example.com SIP/2.0 Via: SIP/2.0/TLS client.pdnl.example.com:5061;branch=z9hG4bK74bf9 Max-Forwards: 70 From: Alice ;tag=1234567 To: Bob Call-ID: 12345600@ndc.example.com CSeq: 314159 INVITE Contact: ; audio; video; mediahandling="bufferonly" Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Content-Type: application/sdp Content-Length: ... Once A selects B as the target device for session transfer, A sends F2 INVITE (re-Invite) message to B to update the session between A and B. The F2 message does not include mediahandling feature tag in the Contact header and hence media streams for this session are displayed on B. F2: INVITE A->B INVITE sips:bob@pdnl.example.com SIP/2.0 Via: SIP/2.0/TLS client.pdnl.example.com:5061;branch=z9hG4bK74bf9 Max-Forwards: 70 From: Alice ;tag=1234567 To: Bob ;tag=7654321 Call-ID: 12345600@ndc.example.com CSeq: 314160 INVITE Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Content-Type: application/sdp Content-Length: ... Mingqiang, et al. Expires September, 2005 [Page 11] Internet Draft session-mobility-media March 31, 2005 Once the session between A and B is updated and media streams are being displayed in B, A sends REFER message to B. Once B receives the REFER, B sends INVITE message to CN to establish a session with CN, and start receiving media streams directly from CN. Because B already has the buffer, it can instantly and seamlessly switch to CN to be the source of the media stream. 6. IANA Considerations There are two IANA considerations associated with this document. 6.1. SIP Option Tag Registration This document requires registration of a new option tag, "bufferonly". The required information for this registration, as specified in RFC 3261 [1], is: Name: bufferonly Description: This option tag is used for indicating media handling feature while transferring a session seamlessly from one device to another device. While present in a Require header, it indicates the UA should only buffer the multimedia content rather than displaying it. 6.2. Media Feature Tag Registration This document requires registration of a new feature tag according to the procedures of RFC 2506 [7]. This registration will be made in the SIP tree for media feature tags. This registration is as follows: Media feature tag name: sip.mediahandling ASN.1 Identifier: New assignment by IANA. Summary of the media feature indicated by this tag: The sip.mediahandling feature tag indicates a SIP UA on how to handle the media sent by another SIP UA. Values appropriate for use with this feature tag: Token with an equality relationship. Typical values include: String value, "bufferonly". The media is to be used only for buffering. Mingqiang, et al. Expires September, 2005 [Page 12] Internet Draft session-mobility-media March 31, 2005 7. Security Considerations There are some security concerns that must be addressed while a Mobile Node intends to establish communication sessions with devices in PAN. The Mobile Node needs to authenticate itself with the devices in PAN in order to limit the accessibility of devices in PAN by unauthorized users. Some of the security concerns are already addressed in [2] and additional security concerns will be addressed in the future revision. 8. 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] Shacham, R., Schulzrinne, H., Thakolsri, S., Kellerer, W., "Session Initiation Protocol (SIP) Session Mobility," IETF Internet Draft (Work in Progress), February 2005. [3] Rosenberg, J., "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)," RFC 3840, August 2004. [4] Handley, M., Jacobson, V., "Session Description Protocol ( SDP)," RFC 2327, April 1998. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997. [6] Sparks, R., "The Session Initiation Protocol (SIP) REFER Method," RFC 3515, April 2003. [7] Holtman, K., Mutz, A., and Hardie, T., "Media Feature Tag Registration Procedure," BCP 31, RFC 2506, March 1999. [8] Wenger S., et. al., "RTP Payload Format for H.264 Video," RFC 3984, February 2005. Mingqiang, et al. Expires September, 2005 [Page 13] Internet Draft session-mobility-media March 31, 2005 9. Authors' Addresses The addresses of authors are listed below. Xu Mingqiang Matsushita Electric Industrial Co., Ltd.(Panasonic) 4-5-15 Higashi-shinagawa Shinagawa-ku, Tokyo Japan Phone: +81 3 5460 2741 E-mail: xu.mingqiang@jp.panasonic.com Daisaku Komiya Matsushita Electric Industrial Co., Ltd.(Panasonic) 4-5-15 Higashi-shinagawa Shinagawa-ku, Tokyo Japan Phone: +81 3 5460 2741 E-mail: komiya.daisaku@jp.panasonic.com Sachiko Kawaguchi Matsushita Electric Industrial Co., Ltd.(Panasonic) 4-5-15 Higashi-shinagawa Shinagawa-ku, Tokyo Japan Phone: +81 3 5460 2741 E-mail: kawaguchi.sachiko@jp.panasonic.com Mahfuzur Rahman Panasonic Digital Networking Laboratory Two Research Way Princeton, New Jersey 08550, USA Email: mahfuz@research.panasonic.com Brijesh Kumar Panasonic Digital Networking Laboratory Two Research Way Princeton, New Jersey 08550, USA Email: kumarb@research.panasonic.com Mingqiang, et al. Expires September, 2005 [Page 14] Internet Draft session-mobility-media March 31, 2005 Intellectual Property Statement 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. Mingqiang, et al. Expires September, 2005 [Page 15] Internet Draft session-mobility-media March 31, 2005 The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Mingqiang, et al. Expires September, 2005 [Page 16]