Internet DRAFT - draft-burger-lemonade-streamctrls
draft-burger-lemonade-streamctrls
LEMONADE E. Burger
Internet-Draft Cantata Technology, Inc.
Expires: January 19, 2007 July 18, 2006
Lemonade Protocol for Streaming Media With Controls
draft-burger-lemonade-streamctrls-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 January 19, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes a method for providing streaming multimedia
servives in the lemonade architecture. The method provides for
third-party streaming, as well as object playback control. It
leverages SIP for providing stream negotiation and media control.
Conventions used in this document
RFC2119 [1] provides the interpretations for the key words "MUST",
"MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
Burger Expires January 19, 2007 [Page 1]
Internet-Draft STREAMING July 2006
"RECOMMENDED", "MAY", and "OPTIONAL" found in this document.
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively. If a single "C:" or "S:" label applies to
multiple lines, then the line breaks between those lines are for
editorial clarity only and are not part of the actual protocol
exchange.
All examples use the host name "me.example.com" for the client,
"ms.example.net" for the media server, and "imap.example.net" for the
IMAP server.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol Behavior . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Email Client . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Media Server Behavior . . . . . . . . . . . . . . . . . . . 5
2.3. IMAP Server Behavior . . . . . . . . . . . . . . . . . . . 6
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Normative References . . . . . . . . . . . . . . . . . . . 6
5.2. Informative References . . . . . . . . . . . . . . . . . . 6
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Burger Expires January 19, 2007 [Page 2]
Internet-Draft STREAMING July 2006
1. Introduction
The lemonade architecture [7] proposes to enable forward-without-
download by creating a mechanism for a submit server to securely
fetch an IMAP [8] body part for later submission. The LEMONADE
Profile [9] describes this mechanism in detail. In particular, the
mechanism uses the URLAUTH [2] token to give access to the body part
in question to the submit server. The submit server uses the
URLFETCH command as described by RFC4467 to download the body part
from the IMAP Server.
The streaming media with controls approach is to use the same trust
triangle established by URLAUTH, but have a media server fetch the
content, perform appropriate content and protocol transformations,
and stream the result to the client. The three components of
interest for our purposes is a URLAUTH-aware client that supports SIP
[3] and MSCML [4]; an IMAP server that supports URLAUTH, URLFETCH and
the IMAP BINARY [5] extension; and a media server that supports SIP,
MSCML, URLFETCH, and the IMAP BINARY extension.
Shamelesly lifting a drawing from LEMONADE Streaming [10], we have
the following diagram.
+----------------+
| |<
| Email Client | \
| me.example.com | \
| |\ \
+----------------+ \ \
| \ \
| \ \ (5)
| (1), \ \
| (2) \ \
| (3),\ \
| (6) \ \
| \ \
v v \
+------------------+ +----------------+
| | (4) | |
| IMAP Server |<------| Media Server |
| imap.example.net | | ms.example.net |
+------------------+ +----------------+
Shamelessly lifting Neil's text, as the call flow is nearly
identical, we have the following protocol steps.
1. The Email Client determines that it wants to stream a particular
message part (attachment).
Burger Expires January 19, 2007 [Page 3]
Internet-Draft STREAMING July 2006
2. The Email Client constructs an IMAP URL referencing the message
part and requests the IMAP Server to generate a URLAUTH
authorized IMAP URL.
3. The Email Client, takes the IMAP URL, constructs an appropriate
MSCML request referencing the desired object, and uses the IVR
service as described by RFC4240 [6] to establish a SIP sessoin
with the Media Server.
4. The Media Server connects to the IMAP Server specified in the
referenced URL, and uses the IMAP URLFETCH command to retrieve
the message part that the Email Client requested.
5. The Media server streams the retrieved message part to the client
as negotiated by SIP.
6. Either the Media server terminates the SIP session after playing
the object or the Email Client terminates the session by issuing
the SIP BYE method.
The key difference betwenn LEMONADE Streaming [10] and this document
is step (3) above. In LEMONADE Streaming, using raw RFC4240 means
that the Email Client does not have controls such as pause, rewind,
skip-ahead, speed-up, slow-down, or replay. In this document, we
will describe how to implement such controls.
The codec (data format) conversion, if required, is a matter for the
Media Server and Email Client to negotiate, using SIP. The Media
Server fetches the content in the format specified by the Email
Client, which presumably is the format returned by the BODYSTRUCTURE.
That is, it should be the format the IMAP Server has stored the body
part. This means the IMAP Server does not have to do any media
conversion. Moreover, the Media Server fetches the content using
IMAP, which means the IMAP Server does not need to do streaming.
2. Protocol Behavior
2.1. Email Client
In an IMAP session, the client sees a body part it would like to
stream. For example, it may have seen the following result to the
BODYSTRUCTURE IMAP command. We have formatted the BODYSTRUCTURE
result to be more readable for the purposes of this exposition.
Burger Expires January 19, 2007 [Page 4]
Internet-Draft STREAMING July 2006
(
("TEXT" "PLAIN"
("CHARSET" "US-ASCII")
NIL NIL "7BIT" 4946 139)
("AUDIO" "BASIC"
"<messagedeposit074a3b7f@ms.example.net>"
"Voice Message Object"
"BASE64" 1774064 23343)
"MIXED"
)
Fetching the headers
C: a122 UID FETCH 24359 BODY[1.2.MIME]
S: * 26 FETCH (BODY[1.3.MIME] {127}
S: Content-Transfer-Encoding: base64
S: Content-Type: audio/basic;
S: UID 24359 FLAGS (\Seen))
S: a122 OK FETCH completed.
Here the Email client sees there is an audio/basic body part that is
a little bit less than 1.7 megabytes. The client decides it wants to
stream that object.
C: a123 GENURLAUTH "imap://joe@imap.example.com/INBOX/;uid=24359/;
section=1.3;expire=2006-12-19T16:39:57-08:00;
urlauth=submit+ms" INTERNAL
S: * GENURLAUTH "imap://joe@imap.example.com/INBOX/;uid=24359/;
section=1.3;expire=2006-12-20T18:31:\45-08:00;
urlauth=submit_ms:
internal:0a9823092c34092b84092d3840ff928402934c8023d948c2"
S: a123 OK GENURLAUTH completed
The Email client then forumlates the SIP INVITE to initiate the MSCML
session. Note the content is in G.711 (audio/basic) format; the
Email client wants the content in G.729.
INVITE sip:ivr@ms.example.net
this is where the MSCML would go IF and only IF my net connection
didn't die so I could put in real MSCML in time!!!
2.2. Media Server Behavior
Receive the INVITE.
Execute the MSCML. Note that the imap: URL scheme works just fine.
Note the availability of VCR controls.
Burger Expires January 19, 2007 [Page 5]
Internet-Draft STREAMING July 2006
2.3. IMAP Server Behavior
The beauty of it all: nothing changes!
3. IANA Considerations
4. Security Considerations
5. References
5.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Crispin, M., "Internet Message Access Protocol (IMAP) - URLAUTH
Extension", RFC 4467, May 2006.
[3] 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.
[4] Dyke, J., "Media Server Control Markup Language (MSCML) and
Protocol", draft-vandyke-mscml-09 (work in progress), June 2006.
[5] Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516,
April 2003.
[6] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media
Services with SIP", RFC 4240, December 2005.
5.2. Informative References
[7] Wong, J., "Goals for Internet Messaging to Support Diverse
Service Environments", RFC 4416, February 2006.
[8] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[9] Maes, S. and A. Melnikov, "Internet Email to Support Diverse
Service Environments (Lemonade) Profile", RFC 4550, June 2006.
[10] Cook, N., "Streaming Multimedia Messaging Attachments",
June 2006.
Burger Expires January 19, 2007 [Page 6]
Internet-Draft STREAMING July 2006
Appendix A. Acknowledgements
Lifted lots of text from Neil.
Burger Expires January 19, 2007 [Page 7]
Internet-Draft STREAMING July 2006
Author's Address
Eric Burger
Cantata Technology, Inc.
18 Keewaydin Dr.
Salem, NH 03079
USA
Email: eburger@cantata.com
Burger Expires January 19, 2007 [Page 8]
Internet-Draft STREAMING July 2006
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.
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 (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Burger Expires January 19, 2007 [Page 9]
