[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-cook-lemonade-streaming) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 RFC 5616

Lemonade                                                         N. Cook
Internet-Draft                                                    Noware
Updates: RFC 4240, RFC 4722                            February 16, 2007
(if approved)
Intended status: Informational
Expires: August 20, 2007


               Streaming Multimedia Messaging Attachments
                    draft-ietf-lemonade-streaming-01

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 August 20, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).












Cook                     Expires August 20, 2007                [Page 1]

Internet-Draft        Lemonade Multimedia Streaming        February 2007


Abstract

   This document describes a method for streaming multimedia attachments
   received by a resource constrained and/or mobile device from an IMAP
   server.  It allows such clients, which often have limits in storage
   space and bandwidth, to play video and audio e-mail content.

   The document describes a profile for making use of the IMAP URLAUTH
   extension (RFC 4467), the Network Announcement SIP Media Service (RFC
   4240), and the Media Server Control Markup Language (RFC 4722).  The
   document also defines a new IMAP METADATA entry.








































Cook                     Expires August 20, 2007                [Page 2]

Internet-Draft        Lemonade Multimedia Streaming        February 2007


Conventions Used in this Document

   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
   in this document are to be interpreted as defined in RFC 2119 [8].

   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.









































Cook                     Expires August 20, 2007                [Page 3]

Internet-Draft        Lemonade Multimedia Streaming        February 2007


1.  Introduction

   Email clients on resource and/or network constrained devices, such a
   mobile phones, may have difficulties in retrieving and/or storing
   large attachments received in a message.  For example, on a poor
   network link, the latency required to download the entire attachment
   may not be acceptable to the user.  Conversely, even on a high-speed
   network, the device may not have enough storage space to secure the
   attachment once retrieved.

   For certain media, such as audio and video, there is a solution: the
   media can be streamed to the device, using protocols such as SIP [5]
   and particularly the media server profile as specified in RFC 4240
   [1] or MSCML [14].  Streaming the media to the device addresses both
   the latency issue, since the client can start playing the media
   immediately, and the storage issue, since the client does not need to
   store the media locally.  A tradeoff is that the media cannot be
   viewed/played when the device is offline.

   Examples of the types of media that would benefit from the ability to
   stream such media to the device include:

      + Voice or Video mail messages received as an attachment

      + Audio clips such as ring tones received as an attachment

      + Video clips such as movie trailers received as an attachment

   The client may wish to present the user with the ability to use
   simple "VCR"-style controls such as pause, fast-forward and rewind.
   In consideration of this, the document presents two alternatives for
   streaming media - a simple mechanism which makes use of the
   announcement service of RFC 4240, and a more complex mechanism which
   allows VCR controls, based on MSCML (RFC 4722) [14].  The choice of
   which mechanism to use is up to the client.  The choice may be based
   on limitations of the client or the configured media server.  This
   document presents suggestions for determining which of these services
   are available.













Cook                     Expires August 20, 2007                [Page 4]

Internet-Draft        Lemonade Multimedia Streaming        February 2007


2.  Mechanism

2.1.  Overview of Mechanism

   The proposed mechanism for streaming media to messaging clients is a
   profile for making use of several existing mechanisms, namely:

   1.  IMAP URLAUTH Extension (RFC 4467) [2] - Providing the ability to
       generate an IMAP URL [4] that allows anonymous access from
       external systems to specific message parts; for example, an audio
       clip.

   2.  Media Server Announcement Service (RFC 4240) [1] - Providing the
       ability for a media server to stream media using a reference
       provided by the media server client in a URL.

   3.  Media Server Interactive Voice Response (IVR) Service (RFC 4722)
       [14] - Providing the ability to stream media as above, but with
       VCR-style controls.

   However, it should be noted that this document proposes an extension
   to the SIP Parameter Registry [9], in order to accommodate the
   passing of a content transfer encoding parameter.

   This document also proposes a new attribute for the IMAP METADATA
   Extension [15], which is used to provide information about zero or
   more suitable media servers for use with the IMAP [3] server.
























Cook                     Expires August 20, 2007                [Page 5]

Internet-Draft        Lemonade Multimedia Streaming        February 2007


   The approach is shown in the following figure:


   +--------------+
   |              |
   | Email Client |^
   |              | \
   +--------------+  \
       |           \  \
       |            \  \ (5)
       | (1),        \  \
       | (2)          \  \
       |           (3),\  \
       |           (6)  \  \
       |                 \  \
       v                  v  v
   +--------------+       +----------------+
   |              |  (4)  |                |
   | IMAP Server  |<------|  Media Server  |
   |              |       |                |
   +--------------+       +----------------+


                                 Figure 1

   The proposed mechanism has the following steps:

   1.  Client determines from headers of a particular message that a
       particular message part (attachment) should be streamed to the
       user.  Note that no assumptions are made about how/when/if the
       client contacts the user of the client about this decision.  User
       input MAY be required in order to initiate the proposed
       mechanism.

   2.  Client constructs an IMAP URL referencing the message part, and
       uses the GENURLAUTH [2] command to generate a URLAUTH authorized
       IMAP URL.  Client may optionally use the IMAP server to discover
       a suitable media server for streaming the media.

   3.  Client connects to a SIP Media Server using the Announcement
       Service as specified in RFC 4240 [1], or the IVR Service as
       specified in RFC 4722 [14], and passes the URLAUTH authorized URL
       to the media server.

   4.  Media Server connects to the IMAP Server specified in the
       referenced URL, and uses the IMAP URLFETCH [2] command to
       retrieve the message part.




Cook                     Expires August 20, 2007                [Page 6]

Internet-Draft        Lemonade Multimedia Streaming        February 2007


   5.  Media server streams the retrieved message part to the client
       using RTP [7].

   6.  The media server or the client terminates the SIP session.

   It should be noted that the proposed mechanism makes several
   assumptions about the mobile device, as well as the network services,
   namely:

      + Mobile device is provisioned with, or obtains from the IMAP
      server, the address or addresses of a media server which supports
      either RFC 4240 [1] or RFC 4722 [14].

      + Media Server(s) used by the mobile device support the IMAP URL
      [4] scheme for the announcement and/or IVR services

      + IMAP Server used by the mobile device supports generating
      anonymous IMAP URLs using the URLAUTH mechanism

   This document assumes an Internet deployment where there are no
   network restrictions between the different components.  Specifically,
   it does not address issues that can occur when network policies
   restrict the communication between different components, especially
   between the media server and the IMAP server.

2.2.  Client use of GENURLAUTH Command

   The decision to make use of streaming services for a message part
   will usually be predicated on the content type of the message part.
   Using the capabilities of the IMAP FETCH command, clients determine
   the MIME [10] Content-Type of particular message parts and based on
   local policies or heuristics, decide that streaming for that message
   part will be attempted.

   Once the client has determined that a particular message part
   requires streaming, the client generates an IMAP URL that refers to
   the message part according to the method described in RFC 2192 [4].
   The client then begins the process of generating an URLAUTH URL, by
   appending ";EXPIRE=<datetime>" and ";URLAUTH=<access>" to the initial
   URL.

   The ";EXPIRE=<datetime>" parameter is optional, however it SHOULD be
   used, since the use of anonymous URLAUTH authorized URLs is a
   security risk, and doing so ensures that at some point in the future,
   permission to access that URL will cease.

   The <access> portion of the URLAUTH parameter SHOULD be 'authuser' if
   the media server discovery mechanism defined in Section 2.3 specifies



Cook                     Expires August 20, 2007                [Page 7]

Internet-Draft        Lemonade Multimedia Streaming        February 2007


   that the media server is an authorised user of the IMAP server.
   Without specific prior knowledge of such a configuration (either
   through the discovery mechanism or by an out of band mechanism), the
   client MUST use the 'anonymous' access identifier.

   The client uses the URL generated as a parameter to the GENAUTHURL
   command, using the INTERNAL authorization mechanism.  The URL
   returned by a successful response to this command will then be passed
   to the media server.  If no successful response to the GENURLAUTH
   command is received, then no further action will be possible with
   respect to streaming media to the client.

   Examples:

   C: a122 UID FETCH 24356 BODY[1.2.MIME]
   S: * 26 FETCH (BODY[1.2.MIME] {127}
   S: Content-Transfer-Encoding: base64
   S: Content-Type: video/mpeg;
   S: UID 24356 FLAGS (\Seen))
   S: a122 OK FETCH completed.
   C: a123 GENURLAUTH "imap://joe@example.com/INBOX/;uid=24356/;\
   section=1.2;expire=2006-12-19T16:39:57-08:00;\
   urlauth=anonymous" INTERNAL
   S: * GENURLAUTH "imap://joe@example.com/INBOX/;uid=24356/;\
   section=1.2;expire=2006-12-19T16:39:\57-08:00;\
   urlauth=anonymous:\
   internal:238234982398239898a9898998798b987s87920"
   S: a123 OK GENURLAUTH completed


   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/G729;
   S: UID 24359 FLAGS (\Seen))
   S: a122 OK FETCH completed.
   C: a123 GENURLAUTH "imap://joe@example.com/INBOX/;uid=24359/;\
   section=1.3;expire=2006-12-19T16:39:57-08:00;\
   urlauth=anonymous" INTERNAL
   S: * GENURLAUTH "imap://joe@example.com/INBOX/;uid=24359/;\
   section=1.3;expire=2006-12-20T18:31:\45-08:00;\
   urlauth=authuser:\
   internal:098230923409284092384092840293480239482"
   S: a123 OK GENURLAUTH completed







Cook                     Expires August 20, 2007                [Page 8]

Internet-Draft        Lemonade Multimedia Streaming        February 2007


2.3.  Media Server Discovery using the METADATA Extension

   There are two possibilities for clients with regard to determining
   the hostname and port number information of a suitable media server:

   1.  No discovery of media servers is required: clients are configured
       with suitable media server information in an out-of-band manner.

   2.  Discovery of media servers is required: clients use the discovery
       mechanism described in this section to determine a suitable media
       server to use for streaming multimedia message parts.

   There are several scenarios where media server discovery would be a
   requirement for streaming to be successful:

   o  Client is not configured with the address of any media servers.

   o  Client is configured with the address of one or more media
      servers, but the IMAP server is configured to only accept URLFETCH
      requests from specific media servers (for security or site policy
      reasons), and thus streaming would fail due to the media server
      not being able to retrieve the media from the IMAP server.

   There is also a scenario where media server location would improve
   the security of the streaming mechanism, by avoiding the use of
   anonymous or "pawn- ticket" URLs.  For example, the client could
   discover a tuple of a media server address and an IMAP username,
   which allowed the client to generate a URL which was secure in that
   it could *only* be accessed by a specific (presumably trusted) media
   server.

   This document proposes using the IMAP METADATA [15] extension, via
   the use of an entry that provides the contact information for
   suitable media servers for use with the IMAP server.  Media Server
   discovery is optional: clients are free to use pre-configured
   information about media servers, or to fall back to pre-configured
   information if they encounter IMAP servers that do not support either
   the METADATA extension or the proposed entry, or that do not provide
   a value for the entry.

   The following gives the proposed IANA submission for the METADATA
   server entry to be used for media server discovery.

   To: iana@iana.org

   Subject: IMAP METADATA Registration

   Please register the following IMAP METADATA item:



Cook                     Expires August 20, 2007                [Page 9]

Internet-Draft        Lemonade Multimedia Streaming        February 2007


   [X] Entry [] Attribute

   [ ] Mailbox [X] Server

   Name: /mediaServers

   Description: Defined in Streaming Multimedia Messaging Attachments

   Content-type: text/plain;charset=utf-8

   Contact person: Neil Cook

   email: neil.cook@noware.co.uk

   The "value" attribute of the /mediaServers entry is formatted
   according to the formalSyntax specified in Section 5.  This consists
   of a tuple of host, port and optional "authuser", where the host,
   port and authuser are separated using a colon ":", and tuples are
   separated using a ";".

   For example:

   "ms.example.net:5060:authuser;ms1.example.net:5060;ms2.example.net:
   5061"

   "10.20.30.40:5060;10.20.30.41:5060;10.20.30.42:5060:authuser"

   Clients SHOULD parse the value of mediaServers, (using either the
   value.priv or value.shared: whichever is available and/or
   appropriate), and contact a media server using one of the supplied
   values.  No particular preference order is implied by the ordering,
   and it is left to the client implementor to decide the algorithm to
   use when selecting the media server(s) to contact, and the selection
   of alternates under failure conditions.

2.4.  Client Determination of Media Server Capabilities

   Once an authorized IMAP URL has been generated, it is up to the
   client to pass that URL to a suitable media server that is capable of
   retrieving the URL via IMAP, and streaming the content to the client
   using the RTP [7] protocol.

   If the client supports the MSCML IVR service, then it MUST attempt to
   contact the media server using the MSCML protocol by sending a SIP
   INVITE which has the service indicator "ivr".  Due to issues
   described in Section 3, the client SHOULD use a suitable end-to-end
   encryption method, such as S/MIME [6].




Cook                     Expires August 20, 2007               [Page 10]

Internet-Draft        Lemonade Multimedia Streaming        February 2007


   Assuming the media server responds to the INVITE without error, the
   client can carry on using the MSCML IVR service as specified in
   Section 2.7.  If the media server responds with an error indicating
   that the "ivr" service is not supported, then if the client supports
   it, the client SHOULD attempt to contact the media server using the
   Announcement Service, as described in Section 2.5.

   The following example shows an example SIP INVITE using the "ivr"
   service indicator:

   C:
   INVITE sip:ivr@ms2.example.net SIP/2.0
   < SIP Headers omitted for reasons of brevity >

2.5.  Client Use of the Media Server Announcement Service

   Assuming the client or media server does not support use of the MSCML
   protocol, the media server announcement service is used, as described
   in RFC 4240 [1].  This service allows the client to send a SIP INVITE
   to a special username ('annc') at the media server (the
   "announcement" user), supplying the URL obtained as per Section 2.2.

   The SIP INVITE is constructed as shown in the examples below; note
   that as per RFC 4240, the play parameter is mandatory, and specifies
   the authorized IMAP URL to be played.

   The content-type parameter is optional in RFC 4240, however it MUST
   be supplied here, using the Content-Type header returned by the IMAP
   server for the message part.  The reason for supplying the content-
   type parameter is that when the media server issues a URLFETCH
   command to retrieve the message part, the message part will be
   returned without any content type information.  Since the media
   server is not likely to have authorized access to other sections in
   that message, for example the MIME section, then it may fail to
   stream the content if the content type is not supplied as a parameter
   to the SIP INVITE URI.

   Similarly, the message may well be encoded with a content transfer
   encoding such as base 64.  However, RFC 4240 does not include a
   method for communicating content transfer encoding to the media
   server as part of the announcement service, nor does the URLFETCH
   command include a mechanism for retrieving message parts without
   encoding (c.f. the BINARY [17] extension to IMAP).  Therefore, an
   extension parameter is required, namely a 'content-transfer-encoding'
   parameter, using the value of the Content-Transfer-Encoding MIME
   header returned by the IMAP server for the message part.  The
   content-transfer-encoding parameter MUST be supplied if a Content-
   Transfer-Encoding header for the message part existed in the original



Cook                     Expires August 20, 2007               [Page 11]

Internet-Draft        Lemonade Multimedia Streaming        February 2007


   message.

   Examples of valid SIP INVITE URIs sent to the media server
   announcement service:

   sip:annc@ms2.example.net; \
   play=imap://joe@example.com/INBOX/;uid=24356/;section=1.2;\
   expire=2006-12-19T16:39:\57-08:00;urlauth=anonymous:\
   internal:238234982398239898a9898998798b987s87920; \
   content-type=video/mpeg; \
   content-transfer-encoding=base64


   sip:annc@ms1.example.net; \
   play=imap://fred@example.com/INBOX/;uid=24359/;section=1.3;\
   expire=2006-12-20T18:31:\45-08:00;urlauth=authuser:\
   internal:098230923409284092384092840293480239482; \
   content-type=audio/G729; \
   content-transfer-encoding=base64

   If the receives a 200 OK response, the media server has successfully
   retrieved the content from the IMAP server and the negotiated RTP
   stream will shortly begin after the ACK.

   An unsuccessful response code of 404 received from the media server
   indicates that the content could not be found or could not be
   retrieved for some reason.  For example, the media server may not
   support the use of IMAP URLs.  At this point, there are several
   options to the client, such as using alternate media servers, or
   giving up in attempting to stream the required message part.

2.6.  Media Negotiation and Transcoding

   This document uses standards and protocols from two traditionally
   separate application areas: Mobile Email (primarily IMAP) and
   Internet Telephony/Streaming (e.g.  SIP/RTP).  Since the document
   primarily addresses enhancing the capabilities of mobile email, it is
   felt worthwhile to give some examples of simple SIP/SDP exchanges,
   and discussing capabilities such as media negotiation (using SDP) and
   media transcoding.

   In the below example, the client contacts the media server using the
   SIP INVITE command to contact the Announcement service (see
   Section 2.5), advertising support for a range of audio and video
   codecs (using SDP [12]), and in response the media server advertises
   only a set of audio codecs.  This process is identical for the IVR
   service, except that the IVR service does not use the SIP Request-URI
   to indicate the content to be played; instead this is carried in a



Cook                     Expires August 20, 2007               [Page 12]

Internet-Draft        Lemonade Multimedia Streaming        February 2007


   subsequent SIP INFO request.

   The client and server now know from the SDP advertised by both client
   and server that communication must be using the subset of audio
   codecs supported by both client and server (in the example SDP, it is
   clear that the server does not support any video codecs).  The media
   server may perform transcoding (i.e. converting between codecs) on
   the media received from the IMAP server in order to satisfy the
   codecs supported by the client: for example the media server may
   downgrade the video retrieved from the IMAP server to the audio
   component only.

   For clients using the Announcement service, the media server MUST
   return an error to the INVITE if it cannot find a common codec
   between the client, server and media, and it cannot transcode to a
   suitable codec.  Similarly, for clients using the MSCML IVR service,
   the media server MUST return a suitable error response to the
   <playcollect> request.

   Example SIP INVITE and SDP Media Negotiation

   C: INVITE sip:annc@ms2.example.net; \
   play=imap://joe@example.com/INBOX/;uid=24356/;section=1.2;\
   expire=2006-12-19T16:39:\57-08:00;urlauth=anonymous:\
   internal:238234982398239898a9898998798b987s87920; \
   content-type=video/mpeg; \
   content-transfer-encoding=base64 SIP/2.0
   From: UserA <sip:UAA@example.com>
   To: NetAnn <sip:annc@ms2.example.com>
   Call-ID: 8204589102@example.com
   CSeq: 1 INVITE
   Contact: <sip:UserA@10.20.30.40>
   Content-Type: application/sdp
   Content-Length: 481
   v=0
   o=UserA 2890844526 2890844526 IN IP4 10.20.30.40
   s=Session SDP
   c=IN IP4 10.20.30.40
   t=3034423619 0
   m=audio 9224 RTP/AVP 0 8 3 98 101
   a=alt:1 1 : 01BB7F04 6CBC7A28 10.20.30.40 9224
   a=fmtp:101 0-15
   a=rtpmap:98 ilbc/8000
   a=rtpmap:101 telephone-event/8000
   a=sendrecv
   m=video 9226 RTP/AVP 105 34 120
   a=alt:1 1 : 01BCADB3 95DFFD80 10.20.30.40 9226
   a=fmtp:105 profile=3;level=20



Cook                     Expires August 20, 2007               [Page 13]

Internet-Draft        Lemonade Multimedia Streaming        February 2007


   a=fmtp:34 CIF=2 QCIF=2 MAXBR=5120
   a=rtpmap:105 h263-2000/90000
   a=rtpmap:120 h263/90000
   a=sendrecv

   S:
   SIP/2.0 200 OK
   From: UserA <sip:UAA@example.com>
   To: NetAnn <sip:annc@ms2.example.com>
   Call-ID: 8204589102@example.com
   CSeq: 1 INVITE
   Contact: <sip:netann@10.20.30.41>
   Content-Type: application/sdp
   Content-Length: 317
   v=0
   o=NetAnn 2890844527 2890844527 IN IP4 10.20.30.41
   s=Session SDP
   c=IN IP4 10.20.30.41
   t=3034423619 0
   m=audio 17684 RTP/AVP 0 8 3 18 98 101
   a=rtpmap:0 PCMU/8000
   a=rtpmap:8 PCMA/8000
   a=rtpmap:3 GSM/8000
   a=rtpmap:18 G729/8000
   a=fmtp:18 annexb=no
   a=rtpmap:98 iLBC/8000
   a=rtpmap:101 telephone-event/8000
   a=fmtp:101 0-16

   C:
   ACK sip:netann@10.20.30.41 SIP/2.0
   From: UserA <sip:UAA@example.com>
   To: NetAnn <sip:annc@ms2.example.com>
   Call-ID: 8204589102@example.com
   CSeq: 1 ACK
   Content-Length: 0

2.7.  Client Use of the Media Server MSCML IVR Service

   Once the client has determined that the media server supports the IVR
   service, it is up to the client to generate a suitable MSCML request
   to initiate streaming of the required media.

   When using the IVR service, the initial SIP invite is used only to
   establish that the media server supports the MSCML IVR service, and
   to negotiate suitable media codecs.  Once the initial SIP INVITE and
   response to that INVITE have been completed successfully, the client
   must generate a SIP INFO request with MSCML in the body of the



Cook                     Expires August 20, 2007               [Page 14]

Internet-Draft        Lemonade Multimedia Streaming        February 2007


   request to initiate streaming.

   The <playcollect> request is used, as this allows the use of DTMF
   digits to control playback of the media, such as fast-forward or
   rewind.

   Since the playcollect request is used purely for its VCR
   capabilities, there is no need for the media server to perform DTMF
   collection, therefore the playcollect attributes "firstdigittimer",
   "interdigittimer" and "extradigittimer" SHOULD all be set to "0ms",
   which will have the effect of causing digit collection to cease
   immediately the media has finished playing.

   The "ffkey" and "rwkey" attributes of <playcollect> are used to
   control fast forward and rewind behaviour, with the "skipinterval"
   attribute being used to control the 'speed' of these actions.

   The <prompt> tag is used to specify the media to be played, and
   SHOULD have a single <audio> tag that gives the URL of the media, as
   per the Section 2.2.  The audio-specific name of the tag is
   historical, as the tag can be used for video as well as audio
   content.  The "stoponerror" attribute SHOULD be set to "yes", as then
   meaningful error messages will be returned by the media server in the
   event of problems such as retrieving the media from the IMAP server.

   The <audio> tag in RFC 4722 has no attributes that specify the
   content-type or content-transfer-encoding of the media to be played.
   Therefore this document proposes two new attributes for this purpose,
   namely a "contenttype" attribute, and a "contenttransferencoding"
   attribute.  The syntax of these attributes is identical to the syntax
   of their counterparts in MIME [10].

   An example SIP INFO request using the <playcollect> request is shown
   at the end of this section.

   It should be noted that under normal (i.e. non-error) conditions, the
   response to the <playcollect> request is a SIP "200 OK" response.
   The media server then streams the media, and only when the media has
   finished playing (naturally or due to a user request), does the media
   server send a <playcollect> response, which includes details of the
   media played, such as length, and any digits collected.

   The client may suspend playback of the media at any time by either
   sending the DTMF escape key (specified as an attribute to the
   <playcollect> request) or by sending a <stop> request to the media
   server in a SIP INFO message.  Upon receipt of the request, the media
   server will acknowledge it, and then cease streaming of the media,
   followed by a SIP INFO message containing the <playcollect> response.



Cook                     Expires August 20, 2007               [Page 15]

Internet-Draft        Lemonade Multimedia Streaming        February 2007


   If the media server cannot play the media for any reason, for example
   if it cannot retrieve the media from the IMAP server, streaming will
   not take place, and the <playcollect> response will be sent, usually
   with meaningful values in the <error_info> element.

   The following gives an example dialog between a client and media
   server, including a rewind request, and termination of the playback
   by use of the escape key.  Some elements of the SIP dialog such as
   full SIP headers and SDP are omitted for reasons of brevity.  (The
   protocol diagram in Section 2.9.2 shows the high-level message flow
   between all the components, including the IMAP server.)

   C:
   INVITE sip:ivr@ms.example.com SIP/2.0
   From: UserA <sip:UAA@example.com>
   To: IVR <sip:ivr@ms.example.com>
   Call-ID: 3298420296@example.com
   CSeq: 1 INVITE
   Contact: <sip:UserA@10.20.30.40>
   Content-Type: application/sdp
   Content-Length: XXX
   <SDP Here>

   S:
   SIP/2.0 200 OK
   From: UserA <sip:UAA@example.com>
   To: IVR <sip:ivr@ms.example.com>
   Call-ID: 3298420296@example.com
   CSeq: 1 INVITE
   Contact: <sip:ivr@10.20.30.41>
   Content-Type: application/sdp
   Content-Length: XXX
   <SDP Here>

   C:
   ACK sip:ivr@ms.example.com SIP/2.0
   From: UserA <sip:UAA@example.com>
   To: IVR <sip:ivr@ms2.example.com>
   Call-ID: 3298420296@example.com
   CSeq: 1 ACK
   Content-Length: 0

   C:
   INFO sip:ivr@10.20.30.41 SIP/2.0
   From: UserA <sip:UAA@example.com>
   To: IVR <sip:ivr@ms.example.com>
   Call-ID: 3298420296@example.com
   CSeq: 2 INFO



Cook                     Expires August 20, 2007               [Page 16]

Internet-Draft        Lemonade Multimedia Streaming        February 2007


   Content-Type: application/mediaservercontrol+xml
   Content-Length: 423
   <?xml version="1.0"?>
   <MediaServerControl version="1.0">
   <request>
   <playcollect id="332985001"
   firstdigittimer="0ms" interdigittimer="0ms" extradigittimer="0ms"
   skipinterval="6s" ffkey="6" rwkey="4" escape="*">
   <prompt stoponerror="yes"
   locale="en_US" offset="0" gain="0" rate="0"
   delay="0" duration="infinite" repeat="0">
   <audio url="imap://joe@example.com/INBOX/;uid=24356/;section=1.2;\
   expire=2006-12-19T16:39:\57-08:00;urlauth=anonymous:\
   internal:238234982398239898a9898998798b987s87920;"
   contenttype="video/mpeg"
   contenttransferencoding="base64">
   </prompt>
   </playcollect>
   </request>
   </MediaServerControl>

   S:
   SIP/2.0 200 OK
   From: UserA <sip:UAA@example.com>
   To: IVR <sip:ivr@ms.example.com>
   Call-ID: 3298420296@example.com
   CSeq: 2 INFO
   Contact: <sip:ivr@10.20.30.41>
   Content-Length: 0

   <Media Server retrieves media from IMAP Server and streams to client>

   C:
   <Client streams 6 key>

   S:
   <Media Server fast forwards media by 6 seconds>

   C:
   <Client streams * key>

   S:
   <Media Server stops streaming>

   S:
   INFO sip:UAA@10.20.30.40 SIP/2.0
   From: IVR <sip:ivr@ms.example.com>
   To: UserA <sip:UAA@example.com>



Cook                     Expires August 20, 2007               [Page 17]

Internet-Draft        Lemonade Multimedia Streaming        February 2007


   Call-ID: 3298420296@example.com
   CSeq: 5 INFO
   Contact: <sip:ivr@10.20.30.41>
   Content-Type: application/mediaservercontrol+xml
   Content-Length: XXX
   <?xml version="1.0"?>
   <MediaServerControl version="1.0">
   <response id="332985001" request="playcollect"
   code="200" reason="escapekey" playduration="34s"
   playoffset="34s" digits="" />
   </MediaServerControl>

   C:
   SIP/2.0 200 OK
   From: IVR <sip:ivr@ms.example.com>
   To: UserA <sip:UAA@example.com>
   Call-ID: 3298420296@example.com
   CSeq: 5 INFO
   Content-Length: 0

   C:
   BYE sip:ivr@10.20.30.41 SIP/2.0
   From: UserA <sip:UAA@example.com>
   To: IVR <sip:ivr@ms.example.com>
   Call-ID: 3298420296@example.com
   CSeq: 6 BYE
   Content-Length: 0

   S:
   SIP/2.0 200 OK
   From: UserA <sip:UAA@example.com>
   To: IVR <sip:ivr@ms.example.com>
   Call-ID: 3298420296@example.com
   CSeq: 6 BYE
   Contact: <sip:ivr@10.20.30.41>
   Content-Length: 0

2.8.  Media Server Use of IMAP Server

   This section describes how the media server converts the IMAP URL
   received via the announcement or IVR service into suitable IMAP
   commands for retrieving the content.

   The media server first connects to the IMAP server specified in the
   URL.  Once connected, the media server SHOULD use TLS [11] to encrypt
   the communication path, unless the client and server policy both
   allow for insecure communications.




Cook                     Expires August 20, 2007               [Page 18]

Internet-Draft        Lemonade Multimedia Streaming        February 2007


   If the media server is configured as an authorized user of the IMAP
   server, it SHOULD authenticate to the IMAP server using the
   credentials for that user.  This document does not go into the
   details of IMAP authentication, but the authentication SHOULD NOT use
   the LOGIN command over a non-encrypted communication path, unless the
   client's and server's policy both allow for insecure communications.

   If the media server is not configured as an authorized user of the
   IMAP server, it MUST authenticate to the IMAP server using the LOGIN
   command, with the username of "anonymous".  However, in this case, if
   the URL supplied in the 'play' parameter of the SIP INVITE specifies
   an authorization of 'authuser', then the media server SHOULD NOT
   attempt to contact the IMAP server, but SHOULD instead immediately
   return a response code of 404 to the client with a reason phrase of
   'Not authorized to access resource' reason.

   Once authenticated, the media server issues the URLFETCH command,
   using the URL supplied in the 'play' parameter of the SIP INVITE.  A
   successful URLFETCH command will return the message part, which must
   be decoded by the media server, according to the content-transfer-
   encoding header provided by the client (if any).  If the URLFETCH was
   unsuccessful, then the media server MUST return a response code of
   404 to the client with an appropriate reason code.

   Assuming the content is retrieved and decoded successfully, the media
   server returns a 200 OK response code to the client.  After an ACK is
   received, an RTP stream is delivered to the client using the
   parameters negotiated in the SDP.

   If appropriate, the media server MAY choose to implement connection
   caching, in which case connection and disconnection from the IMAP
   server are handled according to whatever algorithm the media server
   chooses.  For example, the media server may know, a priori, that it
   will always access the same IMAP server using the same login
   credentials with an access pattern that would benefit from connection
   caching, without unduly impacting server resources.

   Examples:

   C: a001 LOGIN anonymous null
   S: a001 OK LOGIN completed.
   C: a002 URLFETCH
   "imap://joe@example.com/INBOX/;uid=24356/;section=1.2; \
   expire=2006-12-19T16:39:\57-08:00;urlauth=anonymous:\
   internal:238234982398239898a9898998798b987s87920"
   S: * URLFETCH "imap://joe@example.com/INBOX/;uid=24356/; \
   section=1.2;expire=2006-12-19T16:39:\57-08:00;urlauth=anonymous: \
   internal:238234982398239898a9898998798b987s87920" {36}



Cook                     Expires August 20, 2007               [Page 19]

Internet-Draft        Lemonade Multimedia Streaming        February 2007


   S: U2kgdmlzIHBhY2VtLCBwYXJhIGJlbGx1bS4K
   S: a002 OK URLFETCH completed.
   C: a003 LOGOUT
   S: a003 OK LOGOUT completed.

2.9.  Protocol Diagrams

   This section gives examples of using the mechanism described in the
   document to stream media from a media server to a client, fetching
   the content from an IMAP server.  In all of the examples, the IMAP,
   SIP and RTP protocols use the line styles "-", "=", and "+",
   respectively.  For simplicity, SIP session termination (BYE etc.) is
   not shown.

2.9.1.  Announcement Service Protocol Diagram

   The following diagram shows a simplified view of the protocol
   interactions between the email client, the IMAP server and the media
   server when the client uses the Announcement Service.

   Client                     IMAP Server                   Media Server
     |   FETCH BODY[MIME]          |                              |
     |---------------------------->|                              |
     |   GENURLAUTH                |                              |
     |---------------------------->|                              |
     |                             |                              |
     |                          SIP INVITE                        |
     |===========================================================>|
     |                             |                              |
     |                             |          URLFETCH            |
     |                             |<-----------------------------|
     |                             |                              |
     |                          200 OK                            |
     |<===========================================================|
     |                          ACK                               |
     |===========================================================>|
     |                             |                              |
     |                    Stream Message Part (RTP)               |
     |<+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++|
     |                             |                              |











Cook                     Expires August 20, 2007               [Page 20]

Internet-Draft        Lemonade Multimedia Streaming        February 2007


2.9.2.  IVR Service Protocol Diagram

   The following diagram shows a simplified view of the protocol
   interactions between the email client, the IMAP server and the media
   server when the client uses the MSCML IVR Service.

   Client                     IMAP Server                   Media Server
     |   FETCH BODY[MIME]          |                              |
     |---------------------------->|                              |
     |   GENURLAUTH                |                              |
     |---------------------------->|                              |
     |                             |                              |
     |                          SIP INVITE                        |
     |===========================================================>|
     |                             |                              |
     |                          200 OK                            |
     |<===========================================================|
     |                          ACK                               |
     |===========================================================>|
     |                             |                              |
     |                          SIP INFO (playcollect)            |
     |===========================================================>|
     |                             |
     |                          200 OK                            |
     |<===========================================================|
     |                             |                              |
     |                             |          URLFETCH            |
     |                             |<-----------------------------|
     |                             |                              |
     |                    Stream Message Part (RTP)               |
     |<+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++|
     |                             |                              |
     |                          SIP INFO (e.g., DTMF ff)          |
     |===========================================================>|
     |                          200 OK                            |
     |<===========================================================|
     |                             |                              |
     |                (Streaming Ends or is terminated)           |
     |                             |                              |
     |                          SIP INFO (playcollect response)   |
     |<===========================================================|










Cook                     Expires August 20, 2007               [Page 21]

Internet-Draft        Lemonade Multimedia Streaming        February 2007


3.  Security Considerations

   This document proposes the use of URLAUTH "pawn tickets" to grant
   access to message parts.  The goal is for the media server to stream
   these parts.  INote that f one uses an anonymous pawn ticket, that
   grants access to any client of the IMAP server without requiring any
   authentication credentials.  Even if one grants an authorized pawn
   ticket, any client will have access granted that happens to be an
   authorized user of the IMAP server.

   Clearly, any third parties that gain access to the pawn tickets can
   potentially access private data.  To minimise this, implementors
   should consider the following:

   o  IMAP clients SHOULD use encryption such as TLS [11] to secure the
      communication path to the IMAP server

   o  The media server SHOULD use encryption such as TLS secure the
      communication path to the IMAP server

   Note that the communication path between the client and the media
   server uses SIP.  The announcement service (RFC 4240) passes the pawn
   ticket in the Request-URI.  Thus, if the SIP communication channel is
   not secured with TLS or sips, untrusted third-parties may be able to
   intercept the pawn ticket.

   Using sips in this situation protects the pawn ticket from untrusted
   third-parties.  However, it still allows proxies access to the pawn
   ticket.  Thus, to fully protect the pawn ticket, the IVR service (RFC
   4722) is RECOMMENDED, using an end-to-end encryption of the MSCML
   payload, such as with S/MIME.




















Cook                     Expires August 20, 2007               [Page 22]

Internet-Draft        Lemonade Multimedia Streaming        February 2007


4.  Digital Rights Management (DRM) Issues

   This document does not specify any Digital Rights Management (DRM)
   mechanisms for controlling access to and copying of the media to be
   streamed.  This is intentional.  A reference to a piece of media
   content is created using the URLAUTH command; it is expected that
   creation of a reference which is explicitly allowed by the URLAUTH
   command also implicitly gives the creator the right to pass that
   reference on to any third party it desires.  It would be up to the
   implementation of URLAUTH to enforce any such DRM checks, and such a
   mechanism is outside the scope of this document, as it would affect
   any use of the URLAUTH command, such as the BURL [13] command for
   message submission.

   The document authors believe that encapsulating DRM issues within the
   URLAUTH command gives DRM semantics that are at least equal to those
   in existing IETF messaging standards.  If DRM is a requirement for
   Internet messaging, then a suitable DRM mechanism should be created.
   How such a mechanism would work is outside the scope of this
   document.































Cook                     Expires August 20, 2007               [Page 23]

Internet-Draft        Lemonade Multimedia Streaming        February 2007


5.  Formal Syntax

   The following syntax specification for the mediaServer METADATA entry
   value uses the Augmented Backus-Naur Form (ABNF) notation as
   specified in RFC 2234 [16].

   Except as noted otherwise, all alphabetic characters are case-
   insensitive.  The use of upper or lower case characters to define
   token strings is for editorial clarity only.  Implementations MUST
   accept these strings in a case-insensitive fashion.

   media-servers = ms-tuple *(";" ms-tuple)

   host = astring

   port = nstring

   ms-tuple = host ":" port (":" "authuser")

































Cook                     Expires August 20, 2007               [Page 24]

Internet-Draft        Lemonade Multimedia Streaming        February 2007


6.  Contributors

   Eric Burger, BEA Systems, Inc., eburger@standardstrack.com

   Eric Burger provided the initial inspiration for this document, along
   with advice and support on aspects of the media server IVR and
   Announcement services, along with help with IANA registration and the
   IETF process.











































Cook                     Expires August 20, 2007               [Page 25]

Internet-Draft        Lemonade Multimedia Streaming        February 2007


7.  Normative References

   [1]   Burger, E., "Basic Network Media Services with SIP", RFC 4240,
         December 2005.

   [2]   Crispin, M., "Internet Message Access Protocol (IMAP) - URLAUTH
         Extension", RFC 4467, May 2006.

   [3]   Crispin, M., "Internet Message Access Protocol - Version
         4rev1", RFC 3501, March 2003.

   [4]   Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.

   [5]   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.

   [6]   , B., "S/MIME Version 3 Message Specification"", RFC 2633,
         June 1999.

   [7]   Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
         "RTP: A Transport Protocol for Real-Time Applications",
         RFC 3550, July 2003.

   [8]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", RFC 2119, BCP 14, March 1997.

   [9]   Camarillo, G., "The Internet Assigned Number Authority (IANA)
         Uniform Resource Identifier (URI) Parameter Registry for the
         Session Initiation Protocol (SIP)", RFC 3969, BCP 99,
         December 2004.

   [10]  Freed, N., Borenstein, N., Moore, K., Klensin, J., and J.
         Postel, "Multipurpose Internet Mail Extensions (MIME)",
         RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049,
         November 1996.

   [11]  Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246,
         January 1999.

   [12]  Handley, M. and V. Jacobson, "SDP: Session Description
         Protocol", RFC 2327, April 1998.

   [13]  Newman, C., "Message Submission BURL Extension", RFC 4468,
         May 2006.

   [14]  Van Dyke, J., Burger, E., and A. Spitzer, "Media Server Control
         Markup Language", RFC 4722, Dec 2006.



Cook                     Expires August 20, 2007               [Page 26]

Internet-Draft        Lemonade Multimedia Streaming        February 2007


   [15]  Daboo, C., "IMAP METADATA Extension",
         draft-daboo-imap-annotatemore-10 (Work in progress) , Oct 2006.

   [16]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
         Specifications: ABNF", RFC 2234, Nov 1997.

   [17]  Nereberg, L., "IMAP4 Binary Content Extension", RFC 3516,
         Apr 2003.











































Cook                     Expires August 20, 2007               [Page 27]

Internet-Draft        Lemonade Multimedia Streaming        February 2007


Author's Address

   Neil L Cook
   Noware

   Email: neil.cook@noware.co.uk













































Cook                     Expires August 20, 2007               [Page 28]

Internet-Draft        Lemonade Multimedia Streaming        February 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).





Cook                     Expires August 20, 2007               [Page 29]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/