Lemonade N. Cook
Internet-Draft Cloudmark
Intended status: Informational February 25, 2008
Expires: August 28, 2008
Streaming Internet Messaging Attachments
draft-ietf-lemonade-streaming-04
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 28, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Cook Expires August 28, 2008 [Page 1]
Internet-Draft Streaming Messaging Attachments February 2008
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 28, 2008 [Page 2]
Internet-Draft Streaming Messaging Attachments February 2008
Conventions Used in this Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Overview of Mechanism . . . . . . . . . . . . . . . . . . 5
2.2. Client use of GENURLAUTH Command . . . . . . . . . . . . . 7
2.3. Media Server Discovery using the METADATA Extension . . . 8
2.4. Client Determination of Media Server Capabilities . . . . 10
2.5. Client Use of the Media Server Announcement Service . . . 11
2.6. Media Negotiation and Transcoding . . . . . . . . . . . . 12
2.7. Client Use of the Media Server MSCML IVR Service . . . . . 14
2.8. Media Server Use of IMAP Server . . . . . . . . . . . . . 18
2.9. Protocol Diagrams . . . . . . . . . . . . . . . . . . . . 19
2.9.1. Announcement Service Protocol Diagram . . . . . . . . 20
2.9.2. IVR Service Protocol Diagram . . . . . . . . . . . . . 20
3. Security Considerations . . . . . . . . . . . . . . . . . . . 22
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
5. Digital Rights Management (DRM) Issues . . . . . . . . . . . . 24
6. Deployment Considerations . . . . . . . . . . . . . . . . . . 25
7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 26
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.1. Normative References . . . . . . . . . . . . . . . . . . . 28
9.2. Informative References . . . . . . . . . . . . . . . . . . 29
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . . . 31
Cook Expires August 28, 2008 [Page 3]
Internet-Draft Streaming Messaging Attachments February 2008
1. Introduction
Email clients on resource and/or network constrained devices, such as
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 RTP [7].
Streaming can be initiated and controlled using protocols such as SIP
[5] and particularly the media server profiles as specified in RFC
4240 [1] or MSCML [12]. Streaming the media to the device addresses
both the latency issue, since the client can start playing the media
relatively quickly, 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:
o Voice or Video mail messages received as an attachment
o Audio clips such as ring tones received as an attachment
o 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) [12]. 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 28, 2008 [Page 4]
Internet-Draft Streaming Messaging Attachments February 2008
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. URLFETCH Binary Extension (URLFETCH BINARY) [16] - Providing the
ability to specify BINARY and STRUCTURE arguments to the URLFETCH
command.
3. 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.
4. Media Server Interactive Voice Response (IVR) Service (RFC 4722)
[12] - Providing the ability to stream media as above, but with
VCR-style controls.
This document proposes a new attribute for the IMAP METADATA
Extension [13], which is used to provide information about zero or
more suitable media servers for use with the IMAP [3] server.
Cook Expires August 28, 2008 [Page 5]
Internet-Draft Streaming Messaging Attachments February 2008
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 MIME 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 (see Section 2.3.
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 [12], 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 28, 2008 [Page 6]
Internet-Draft Streaming Messaging Attachments February 2008
5. Media server streams the retrieved message part to the client
using RTP [7].
6. The media server or the client terminate the media streaming, or
the streaming ends naturally. The SIP session is terminated by
either client or server.
It should be noted that the proposed mechanism makes several
assumptions about the mobile device, as well as the network services,
namely:
o 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 [12].
o Media Server(s) used by the mobile device support the IMAP URL [4]
scheme for the announcement and/or IVR services
o IMAP Server used by the mobile device supports generating
anonymous IMAP URLs using the URLAUTH mechanism
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 [9] 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 5092 [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
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.
Cook Expires August 28, 2008 [Page 7]
Internet-Draft Streaming Messaging Attachments February 2008
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 (BODYSTRUCTURE)
S: * 26 FETCH (BODYSTRUCTURE (("TEXT" "PLAIN"
S: ("CHARSET" "US-ASCII") NIL
S: NIL "7BIT" 1152 23)("VIDEO" "MPEG"
NIL NIL "BASE64" 655350)) UID 24356)
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 (BODYSTRUCTURE)
S: * 27 FETCH (BODYSTRUCTURE (("TEXT" "PLAIN"
S: ("CHARSET" "US-ASCII") NIL
S: NIL "7BIT" 1152 23)("AUDIO" "G729"
NIL NIL "BASE64" 87256)) UID 24359)
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
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.
Cook Expires August 28, 2008 [Page 8]
Internet-Draft Streaming Messaging Attachments February 2008
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
completely anonymous URLs. For example, the client could discover a
media server address that was an authorised user of the IMAP server,
which would allow 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 [13] 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 "value" attribute of the /mediaServers entry is formatted
according to the formalSyntax specified in Section 7. This consists
of a tuple of a URI and optional "authuser", where the URI is
surrounded by <> symbols, the URI and "authuser" are separated using
a colon ":", and tuples are separated using a ";".
For example:
"<sip:ivr@ms.example.net:5060>:authuser;<sip:annc@
ms1.example.net:5060>;<sips:ivr@ms2.example.net:5061>"
"<sip:ivr@192.0.2.40:5060>;<sip:192.0.2.41:5060>;<sips:annc@
192.0.2.42:5060>:authuser"
It should be noted that the URI specified in the ABNF is generic,
i.e. not restricted to SIP URIs; however this document only specifies
Cook Expires August 28, 2008 [Page 9]
Internet-Draft Streaming Messaging Attachments February 2008
how to make use of SIP URIs. Additionally, the "userinfo" (known as
the "service indicator" in RFC 4240 and 4722) component of the URI is
optional; if specified it gives the client additional information
about the media server capabilities. For example, a userinfo
component of "annc" indicates that the media server supports RFC
4240, and "ivr" indicates support for RFC 4722.
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
URIs. The servers are returned in order of preference as suggested
by the server, however it is left to the client to decide if a
different order is more appropriate when selecting the media
server(s) to contact, as well as the selection of alternates under
failure conditions.
Administrators configuring the values of the /mediaServers entry, who
do not know the capabilities of the media servers being configured,
SHOULD NOT put the service as part of of the URI, in which case the
client will determine which service to use as specified in Section
2.4. Note that if a media server supports multiple services, a URI
should be configured for each service.
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.
This section specifies the behaviour of clients that have not
determined, (either statically through configuration, or dynamically
through the discovery process specified in Section 2.3), the
capabilities of the media server with respect to the services (i.e.
RFC 4240 or 4722) supported by that media server. Clients that have
determined those capabilities should use the mechanisms described in
Section 2.5 or Section 2.7, as appropriate.
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].
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
Cook Expires August 28, 2008 [Page 10]
Internet-Draft Streaming Messaging Attachments February 2008
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 Header fields 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.
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;
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.
There are many possible response codes, however a 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
Cook Expires August 28, 2008 [Page 11]
Internet-Draft Streaming Messaging Attachments February 2008
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 [11]), 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
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>
Cook Expires August 28, 2008 [Page 12]
Internet-Draft Streaming Messaging Attachments February 2008
Call-ID: 8204589102@example.com
CSeq: 1 INVITE
Contact: <sip:UserA@192.0.2.40>
Content-Type: application/sdp
Content-Length: 481
v=0
o=UserA 2890844526 2890844526 IN IP4 192.0.2.40
s=Session SDP
c=IN IP4 192.0.2.40
t=3034423619 0
m=audio 9224 RTP/AVP 0 8 3 98 101
a=alt:1 1 : 01BB7F04 6CBC7A28 192.0.2.40 9224
a=fmtp:101 0-15
a=rtpmap:98 ilbc/8000
a=rtpmap:101 telephone-event/8000
a=recvonly
m=video 9226 RTP/AVP 105 34 120
a=alt:1 1 : 01BCADB3 95DFFD80 192.0.2.40 9226
a=fmtp:105 profile=3;level=20
a=fmtp:34 CIF=2 QCIF=2 MAXBR=5120
a=rtpmap:105 h263-2000/90000
a=rtpmap:120 h263/90000
a=recvonly
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@192.0.2.41>
Content-Type: application/sdp
Content-Length: 317
v=0
o=NetAnn 2890844527 2890844527 IN IP4 192.0.2.41
s=Session SDP
c=IN IP4 192.0.2.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
Cook Expires August 28, 2008 [Page 13]
Internet-Draft Streaming Messaging Attachments February 2008
a=fmtp:101 0-16
C:
ACK sip:netann@192.0.2.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
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.
An example SIP INFO request using the <playcollect> request is shown
at the end of this section.
Cook Expires August 28, 2008 [Page 14]
Internet-Draft Streaming Messaging Attachments February 2008
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 request. Upon receipt of the request, the media
server will acknowledge it, and then cease streaming of the media,
followed by a SIP INFO request containing the <playcollect> response.
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 header fields 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@192.0.2.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@192.0.2.41>
Content-Type: application/sdp
Content-Length: XXX
Cook Expires August 28, 2008 [Page 15]
Internet-Draft Streaming Messaging Attachments February 2008
<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@192.0.2.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
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">
</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@192.0.2.41>
Content-Length: 0
<Media Server retrieves media from IMAP Server and streams to client>
C:
Cook Expires August 28, 2008 [Page 16]
Internet-Draft Streaming Messaging Attachments February 2008
<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@192.0.2.40 SIP/2.0
From: IVR <sip:ivr@ms.example.com>
To: UserA <sip:UAA@example.com>
Call-ID: 3298420296@example.com
CSeq: 5 INFO
Contact: <sip:ivr@192.0.2.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@192.0.2.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>
Cook Expires August 28, 2008 [Page 17]
Internet-Draft Streaming Messaging Attachments February 2008
Call-ID: 3298420296@example.com
CSeq: 6 BYE
Contact: <sip:ivr@192.0.2.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 [10] to encrypt
the communication path.
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.
If the media server is not configured as an authorized user of the
IMAP server, then the behaviour specified in IMAP URL bis4 [4] MUST
be followed. That is, if the server advertises AUTH=ANONYMOUS IMAP
capability, the media server MUST use the AUTHENTICATE command with
ANONYMOUS [ANONYMOUS] SASL mechanism. If SASL ANONYMOUS is not
available, the user name "anonymous" is used with the "LOGIN" command
and the password is supplied as the Internet e-mail address of the
administrative contact for the media server.
Once authenticated, the media server issues the URLFETCH command,
using the URL supplied in the 'play' parameter of the SIP INVITE (or
audio tag of the MSCML). The IMAP server MUST advertise
URLAUTH=BINARY in its capability string, otherwise the media server
MUST return a response code of 404 to the client. Both the
additional parameters to the URLFETCH command specified in (URLFETCH
BINARY) [16] MUST be used, namely:
o BINARY - This requires the IMAP server to decode any Content
Transfer Encoding present before returning to the media server.
o BODYPARTSTRUCTURE - This requires the IMAP server to return
content type information to the media server, which enables the
media server to stream the media correctly and also perform any
required transcoding.
A successful URLFETCH command will return the message part containing
the media to be streamed. If the URLFETCH was unsuccessful, then the
Cook Expires August 28, 2008 [Page 18]
Internet-Draft Streaming Messaging Attachments February 2008
media server MUST return a response code of 404 to the client with an
appropriate reason code.
Assuming the content is retrieved 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"; BODYPARTSTRUCTURE
BINARY )
S: * URLFETCH "imap://joe@example.com/INBOX/;uid=24356/;
section=1.2;expire=2006-12-19T16:39:\57-08:00;urlauth=anonymous:
internal:238234982398239898a9898998798b987s87920";
(BODYPARTSTRUCTURE ("VIDEO" "MPEG" () NIL NIL "BINARY" 655350 ))
{655350}
S: [ 655350 octets of binary data, containing NUL octets ]
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.
Cook Expires August 28, 2008 [Page 19]
Internet-Draft Streaming Messaging Attachments February 2008
2.9.1. Announcement Service Protocol Diagram
The following diagram shows 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 (BODYSTRUCTURE) | |
|---------------------------->| |
| OK | |
|<----------------------------| |
| GENURLAUTH | |
|---------------------------->| |
| OK | |
|<----------------------------| |
| | |
| SIP INVITE |
|===========================================================>|
| | |
| | URLFETCH |
| |<-----------------------------|
| | OK |
| |----------------------------->|
| | |
| 200 OK |
|<===========================================================|
| ACK |
|===========================================================>|
| | |
| Stream Message Part (RTP) |
|<+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++|
| | |
| BYE |
|<===========================================================|
| 200 OK |
|===========================================================>|
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.
Cook Expires August 28, 2008 [Page 20]
Internet-Draft Streaming Messaging Attachments February 2008
Client IMAP Server Media Server
| FETCH (BODYSTRUCTURE) | |
|---------------------------->| |
| OK | |
|<----------------------------| |
| GENURLAUTH | |
|---------------------------->| |
| OK | |
|<----------------------------| |
| | |
| SIP INVITE |
|===========================================================>|
| | |
| 200 OK |
|<===========================================================|
| ACK |
|===========================================================>|
| | |
| SIP INFO (playcollect) |
|===========================================================>|
| | |
| 200 OK |
|<===========================================================|
| | |
| | URLFETCH |
| |<-----------------------------|
| | OK |
| |----------------------------->|
| | |
| Stream Message Part (RTP) |
|<+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++|
| | |
| SIP INFO (e.g., DTMF ff) |
|===========================================================>|
| 200 OK |
|<===========================================================|
| | |
| Continue streaming (RTP) |
|<+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++|
| | |
| (Streaming Ends or is terminated) |
| | |
| SIP INFO (playcollect response) |
|<===========================================================|
| BYE |
|===========================================================>|
| 200 OK |
|<===========================================================|
Cook Expires August 28, 2008 [Page 21]
Internet-Draft Streaming Messaging Attachments February 2008
3. Security Considerations
This document proposes the use of URLAUTH [2] "pawn tickets",
received over IMAP [3], and transmitted over SIP [5], possibly within
the MSCML payload of RFC 4722 [12], in order to stream media received
in messages. As such, the security considerations in all these
documents apply to this specification.
In summary, as the authorized URLs may grant access to data,
implementors of this specification need to consider the following:
o Use of an anonymous pawn ticket grants access to any client of the
IMAP server without requiring any authentication credentials.
Even if one grants an authorized pawn ticket, any client that
happens to be an authorized user of the IMAP server will have
access granted. The security mechanisms referenced above SHOULD
be used to prevent unauthorized access to the pawn ticket.
o If the announcement service is used to set up streaming, then RFC
4240 [1] specifies that the pawn ticket is passed in the Request-
URI. Thus, if the SIP communication channel is not secured with
TLS (e.g. using the sips URI scheme [5]), 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.
o To fully protect the pawn ticket, the IVR service, RFC 4722 [12],
which uses MSCML to carry the pawn ticket in the body of the
request, is RECOMMENDED, using an end-to-end encryption of the
MSCML payload, such as S/MIME [6].
o When the media server location is retrieved from the IMAP server
(see Section 2.3), there is an implicit level of trust in the
media server used, since the media server has access to both the
pawn ticket and the content to be streamed. Trust in media
servers configured by out-of-band mechanisms is beyond the scope
of this document.
Cook Expires August 28, 2008 [Page 22]
Internet-Draft Streaming Messaging Attachments February 2008
4. IANA Considerations
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:
[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
Cook Expires August 28, 2008 [Page 23]
Internet-Draft Streaming Messaging Attachments February 2008
5. 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 [2] command; any DRM required
thus should be implemented within the media itself, as implementing
checks within URLAUTH could affect any use of the URLAUTH command,
such as the BURL [17] command for message submission.
The use of URLAUTH in this specification is believed to be persuant
with, and used only for, the execution of those rights to be expected
when media is sent via traditional internet messaging, and causes no
duplication of media content which is not essentially provided by the
action of sending the message; that is, the use of the content for
downloading and viewing, which *is* implicitly granted by the sender
of the message, in as much as the sender has the right to grant such
rights.
The document authors believe that 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 28, 2008 [Page 24]
Internet-Draft Streaming Messaging Attachments February 2008
6. Deployment Considerations
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, and between the client
the media server. In particular, RFC 4722 states that "It is
unlikely, but not prohibited, for end-user SIP UACs to have a direct
signaling relationship with a media server." This caveat makes it
likely that firewalls and other network security mechanisms will be
configured to block direct end-user access to media servers.
In order for either of the streaming mechanisms described in this
document to work, local administrators MUST relax firewalls policies
such that appropriate SIP UACs running on mobile devices are
permitted to access the media servers directly using the SIP
protocol. The detail of how the restrictions are relaxed, (for
example, only allowing clients connecting from the network space
owned/maintained by the operator of the media server) is a matter of
local policy, and so is outside the scope of this document.
Cook Expires August 28, 2008 [Page 25]
Internet-Draft Streaming Messaging Attachments February 2008
7. Formal Syntax
The following syntax specification for the mediaServer METADATA entry
value uses the Augmented Backus-Naur Form (ABNF) notation as
specified in RFC 4234 [14] and the "absolute-URI" definition from RFC
3986 [15].
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)
ms-tuple = <absolute-URI> [":" "authuser"]
Cook Expires August 28, 2008 [Page 26]
Internet-Draft Streaming Messaging Attachments February 2008
8. 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 the IETF process.
Many people made helpful comments on the document, including Alexey
Melnikov, Dave Cridland, and a variety of folks in the Lemonade and
Sipping WGs.
Cook Expires August 28, 2008 [Page 27]
Internet-Draft Streaming Messaging Attachments February 2008
9. References
9.1. 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., Melnikov, A., and S. Maes, "IMAP URL Scheme",
RFC 5092, Jan 2007.
[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] Ramsdell, B. and B. Ramsdell, "S/MIME Version 3.1 Message
Specification"", RFC 3851, July 2004.
[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] 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.
[10] Dierks, T. and E. Rescorla, "The TLS Protocol", RFC 4346,
April 2006.
[11] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[12] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server Control
Markup Language", RFC 4722, Dec 2006.
[13] Daboo, C., "IMAP METADATA Extension",
draft-daboo-imap-annotatemore-12 (Work in progress) , Oct 2006.
[14] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Cook Expires August 28, 2008 [Page 28]
Internet-Draft Streaming Messaging Attachments February 2008
Specifications: ABNF", RFC 4234, Oct 2005.
[15] Berners-Lee, T., Fielding, R., and L. Masinter, "Generic URI
Syntax", RFC 3986, Jan 2005.
[16] Cridland, D., "URLAUTH Binary Extension",
draft-cridland-urlfetch-binary-01.txt (Work in Progress) ,
Sep 2007.
9.2. Informative References
[17] Newman, C., "Message Submission BURL Extension", RFC 4468,
May 2006.
Cook Expires August 28, 2008 [Page 29]
Internet-Draft Streaming Messaging Attachments February 2008
Author's Address
Neil L Cook
Cloudmark
Email: neil.cook@noware.co.uk
Cook Expires August 28, 2008 [Page 30]
Internet-Draft Streaming Messaging Attachments February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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 28, 2008 [Page 31]
