MMUSIC WG Xu Mingqiang
Internet Draft Daisaku Komiya
Expires: September 2005 Sachiko Kawaguchi
Mahfuzur Rahman
Brijesh Kumar
Panasonic
March 31, 2005
Buffer Handling Media Attribute in Session Description Protocol (SDP)
for Seamless Session Mobility
draft-mingqiang-mmusic-session-mobility-attribute-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 buffer handling property attribute in Session
Description Protocol (SDP) to indicate media handling feature. This
new attribute will enable seamless transfer of SIP communication
session from one device to another device without disruption of
media streams.
Mingqiang, et al. Expires September, 2005 [Page 1]
Internet Draft session-mobility-attribute March 31, 2005
Table of Contents
1. Introduction.................................................3
2. Terminology and Conventions..................................5
3. Scope........................................................5
4. Application Scenario.........................................6
5. Example and Message Flow Diagrams............................8
6. IANA Considerations.........................................11
6.1. New SDP property Attribute Registration...................11
7. Security Considerations.....................................12
8. References..................................................12
9. Authors' Addresses..........................................13
Mingqiang, et al. Expires September, 2005 [Page 2]
Internet Draft session-mobility-attribute 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-attribute 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 [3].
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 SDP [4] property attribute of the form
"a=<flag>" to indicate the property of the session. As property
attributes are basically binary attributes, our proposed new
attribute will indicate how to handle media such as whether to
display or buffer the media during the transfer of session. The
mechanisms of how to use the property attribute to accomplish
seamless session mobility are described in the following sections.
Mingqiang, et al. Expires September, 2005 [Page 4]
Internet Draft session-mobility-attribute 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 SDP property attribute is defined to indicate to a SIP UA
how the media of a SIP communication session should be handled
during the process of session transfer. The goal of this new SDP
attribute to accomplish the transfer of an ongoing communication
session from one device to another device without disruption of
media flow and this new attribute can be also used in other
applications where indications of such media handling feature is
necessary.
Mingqiang, et al. Expires September, 2005 [Page 5]
Internet Draft session-mobility-attribute 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 (PAN) with
the 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-attribute 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, the 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 SDP property attribute to accomplish
this goal. The new property attribute tag of the form "a=bufferonly"
is 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-attribute March 31, 2005
5. Example 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
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 "a=bufferonly" attribute in the SDP part of the INVITE
message. The devices receiving this INVITE request interpret this
INVITE message as a "bufferonly" media session and hence do not
display the media streams.
Mingqiang, et al. Expires September, 2005 [Page 8]
Internet Draft session-mobility-attribute March 31, 2005
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.
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 <sips:alice@ndc.example.com>;tag=1234567
To: Bob <sips:bob@pdnl.example.com>
Call-ID: 12345600@ndc.example.com
CSeq: 314159 INVITE
Contact: <sips:alice@client.ndc.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Content-Type: application/sdp
Content-Length:...
v=0
o=alice 2890844526 2890844526 IN IP4 client.ndc.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
a=bufferonly
m=video 4004 RTP/AVP 32
a=rtpmap:32 MPV/90000
m=audio 4006 RTP/AVP 0
a=rtpmap:0 PCMU/8000
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 "a=bufferonly" attribute in
SDP and hence media streams for this session are displayed on B.
Since B has an existing buffer, the media is played instantly
without any delay.
Mingqiang, et al. Expires September, 2005 [Page 9]
Internet Draft session-mobility-attribute March 31, 2005
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 <sips:alice@ndc.example.com>;tag=1234567
To: Bob <sips:bob@pdnl.example.com>;tag=7654321
Call-ID: 12345600@ndc.example.com
CSeq: 314160 INVITE
Contact: <sips:alice@client.ndc.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Content-Type: application/sdp
Content-Length: ...
v=0
o=alice 2890844527 2890844527 IN IP4 client.ndc.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=video 4004 RTP/AVP 32
a=rtpmap:32 MPV/90000
m=audio 4006 RTP/AVP 0
a=rtpmap:0 PCMU/8000
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-attribute March 31, 2005
6. IANA Considerations
This memo calls for IANA to register a new property attribute for
Session Description Protocol (SDP).
6.1. New SDP property Attribute Registration
This document requires registration of a new property attribute in
SDP, "a=bufferonly". The required information for this registration,
as specified in RFC 2327 [4], is:
Contact Name: Xu Mingqiang
Email Address: xu.mingqiang@jp.panasonic.com
Phone: +81 3 5460 2741
Attribute Name: a=bufferonly
Type of Attribute: Both session and media level
Description: This new property attribute is used to indicate
media handling feature while transferring a session seamlessly
from one device to another device. This attribute specifies
that the tolls at the receiver SHOULD reserve buffer for media
streams and SHOULD not display the media streams. It can be
either a session or media attribute, and is not dependent on
charset.
Mingqiang, et al. Expires September, 2005 [Page 11]
Internet Draft session-mobility-attribute 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] Wenger S., et. al., "RTP Payload Format for H.264 Video,"
RFC 3984, February 2005.
[4] Handley, H., Jacobson, V.,"SDP: Session Description Protocol,"
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.
Mingqiang, et al. Expires September, 2005 [Page 12]
Internet Draft session-mobility-attribute 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 13]
Internet Draft session-mobility-attribute 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 14]
Internet Draft session-mobility-attribute 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 15]