Streaming Internet
Messaging AttachmentsCloudmarkneil.cook@noware.co.uk
Applications
LemonadeThis 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 5022).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.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 some of the line breaks between those lines are for editorial
clarity only and may not be part of the actual protocol exchange.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. Streaming can be initiated and controlled using protocols such as
SIP and particularly the media server profiles as
specified in RFC 4240 or MSCML. 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: Voice or Video mail messages received as an attachmentAudio clips such as ring tones received as an attachmentVideo clips, such as movie trailers, received as an
attachmentThe 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 5022). The
choice of which mechanism to use is up to the client, for
example it may be
based on limitations of the client or the configured media server. This
document presents suggestions for determining which of these
streaming services are available.The proposed mechanism for streaming media to messaging clients is
a profile for making use of several existing mechanisms,
namely:
IMAP URLAUTH Extension (RFC 4467)
- Providing the ability to generate an IMAP
URL (RFC 5092) that allows anonymous access from external systems to
specific message parts, e.g. an audio clip.URLFETCH Binary Extension
- Providing the ability to specify BINARY and
BODYPARTSTRUCTURE arguments to the URLFETCH command. Media Server Announcement Service (RFC
4240) - Providing the ability for a media server to stream
media using a reference provided by the media server client in a
URL.Media Server Interactive Voice Response (IVR) Service (RFC 5022) - Providing the ability to stream
media as above, but with VCR-style controls.The proposed mechanism has the following steps: 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.Client constructs an IMAP URL referencing the message part, and
uses the GENURLAUTH command to
generate a URLAUTH authorized IMAP URL.Client connects to a SIP Media Server using the Announcement
Service as specified in RFC 4240, or
the IVR Service as specified in RFC
5022, and passes the URLAUTH authorized URL to the media
server.Media Server connects to the IMAP Server specified in the
referenced URL, and uses the IMAP URLFETCH command to retrieve the message
part.Media server streams the retrieved message part to the client
using RTP.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 available network services,
namely: Mobile device is provisioned with, or obtains via some
dynamic mechanism (see Section ), the location of a media
server which supports either RFC
4240 and/or RFC 5022.Media Server(s) used by the mobile device support the IMAP URL scheme for the announcement
and/or IVR servicesIMAP Server used by the mobile device supports generating
anonymous IMAP URLs using the URLAUTH mechanism as well as
the IMAP URLFETCH BINARY extensionThis section discusses possibilities for the automatic
discovery of suitable media servers to perform streaming
operations, and provides for such a mechanism using the IMAP
METADATA extension.
There are two possibilities for clients with regard to determining
the hostname and port number information of a suitable media server:
No discovery of media servers is required: clients are
configured with suitable media server information in an
out-of-band manner.Discovery of media servers is required: clients use a
discovery mechanism to determine a
suitable media server that will be used for streaming multimedia
message parts.There are several scenarios where media server discovery would be a
requirement for streaming to be successful: Client is not configured with the address of any media
servers.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 discovery 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 for streaming purposes, which would allow the client to generate a URL,
which was secure in that it could *only* be accessed by an
entity that is trusted by the IMAP Server to retrieve
content. The isse of trust in media servers is discussed more
fully in This document describes using the IMAP METADATA extension, via the use of a server 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.A METADATA entry with the name of "/public/mediaServers" is
used to store the locations of suitable media servers known to
the IMAP server. The entry is formatted
according to the formalSyntax specified in . This consists of a tuple of a URI
and optional "submit+" string, where the URI is surrounded by <> symbols,
the URI and "submit+" are separated using a colon ":", and
tuples are separated using a ";".The "submit+" string (c.f. the "submit+" access prefix
identifier from ) is
used to identify media servers capable of connecting to the
IMAP server as users authorized to retrieve URLs constructed
using the "submit+" prefix. It indicates that the client MUST
create the content URI using the "submit+" prefix. See for a description of how the
client should make use of the prefix when generating IMAP
URLs.)Example values of the /public/mediaServers METADATA entry:
"<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 how to make use of SIP
URIs. Additionally, the "userinfo" (known as the "service
indicator" in RFC 4240 and RFC 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.
further describes how clients should behave if the
"userinfo" component is not present.
Clients SHOULD parse the value of the /public/mediaServers
entry, and contact a media server using one of the returned
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 include a userinfo component as part of
of the URI, in which case the client will determine which
service to use as specified in Section . Note that
if a media server supports multiple services, a URI with the
appropriate userinfo component SHOULD be configured for each
service. 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 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. 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 (see , and
doing so ensures that at some point in the
future, permission to access that URL will cease. IMAP server
implementors may choose to reject anonymous URLs that are
considered insecure (for example with an EXPIRE date too far
in the future), as a matter of local security policy. To
prevent this causing interoperability problems, IMAP servers
that implement this profile MUST NOT reject GENURLAUTH commands
for anonymous URLs on the basis of the EXPIRE time, if that
time is equal to, or less than 1 hour in the future.The <access> portion of the URLAUTH URL MUST be
'submit+' (see ) if an out of
band mechanism or the media server discovery mechanism
discussed in specifies that the
media server is an authorized user of the IMAP server for the purposes of
retrieving content via URLFETCH. Without specific prior knowledge
of such a configuration (either through a suitable discovery
mechanism or by an out of band mechanism), the client SHOULD
use the 'submit+' access identifier, which will cause
streaming to fail if the media server is not an authorized
user of the IMAP server for the purposes of streaming.
However, if the client wishes to take
the risk associated with generating a URL that can be used by
any media server (see ), it MAY
use 'anonymous' as the <access> portion of the URLAUTH
URL passed to the GENURLAUTH command. For example, the client
may have been preconfigured with the address of media servers
in the local administrative domain, (thus implying a level of
trust in those media servers), without knowing whether those
media servers have a pre-existing trust relationship with the
IMAP server to be used (which may well be in a different
administrative domain). See
for a full discussion of the security issues.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 completedOnce 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 protocol.
This section specifies the behaviour of clients that have not determined,
(either statically through configuration, or dynamically through a discovery process
as discussed in Section ),
the capabilities of the media server with respect to the services (i.e. RFC 4240 or 5022)
supported by that media server. Clients that have determined those capabilities should use
the mechanisms described in Section
or Section , as appropriate.
If the client supports the MSCML IVR service, then it SHOULD 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 , the client SHOULD use a suitable
end-to-end encryption method, such as S/MIME, as described in the SIP
Specification .Assuming the media server responds to the INVITE without error, the
client can carry on using the MSCML IVR service as specified in . 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 .The following example shows an example SIP INVITE using the "ivr"
service indicator:
C: INVITE sip:ivr@ms2.example.com SIP/2.0
< SIP Header fields omitted for reasons of brevity >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. 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 .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:C: sip:annc@ms2.example.net;
play=imap://joe@example.com/INBOX/%3Buid=24356/%3Bsection=1.2%3B
expire=2006-12-19T16:39:57-08:00%3Burlauth=anonymous:
internal:238234982398239898a9898998798b987s87920
C: sip:annc@ms1.example.net;
play=imap://fred@example.com/INBOX/%3Buid=24359/%3Bsection=1.3%3B
expire=2006-12-20T18:31:45-08:00%3Burlauth=authuser:
internal:098230923409284092384092840293480239482
Notice that the ; characters that are used as parameters of
the IMAP URI are escaped as %3B, as otherwise they would change the
meaning of the enclosing SIP URI, by being regarded as SIP
URI parameters instead of IMAP URL parameters.If the client 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 required message part.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 ), advertising support for a range of
audio and video codecs (using SDP), 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 NegotiationC: INVITE sip:annc@ms2.example.com;
play=imap://joe@example.com/INBOX/%3Buid=24356/%3Bsection=1.2%3B
expire=2006-12-19T16:39:57-08:00%3Burlauth=anonymous:
internal:238234982398239898a9898998798b987s87920 SIP/2.0
C: From: UserA <sip:UAA@example.com>
C: To: NetAnn <sip:annc@ms2.example.com>
C: Call-ID: 8204589102@example.com
C: CSeq: 1 INVITE
C: Contact: <sip:UAA@192.0.2.40>
C: Content-Type: application/sdp
C: Content-Length: 481
C:
C: v=0
C: o=UserA 2890844526 2890844526 IN IP4 192.0.2.40
C: s=Session SDP
C: c=IN IP4 192.0.2.40
C: t=3034423619 0
C: m=audio 9224 RTP/AVP 0 8 3 98 101
C: a=alt:1 1 : 01BB7F04 6CBC7A28 192.0.2.40 9224
C: a=fmtp:101 0-15
C: a=rtpmap:98 ilbc/8000
C: a=rtpmap:101 telephone-event/8000
C: a=recvonly
C: m=video 9226 RTP/AVP 105 34 120
C: a=alt:1 1 : 01BCADB3 95DFFD80 192.0.2.40 9226
C: a=fmtp:105 profile=3;level=20
C: a=fmtp:34 CIF=2 QCIF=2 MAXBR=5120
C: a=rtpmap:105 h263-2000/90000
C: a=rtpmap:120 h263/90000
C: a=recvonly
S: SIP/2.0 200 OK
S: From: UserA <sip:UAA@example.com>
S: To: NetAnn <sip:annc@ms2.example.com>
S: Call-ID: 8204589102@example.com
S: CSeq: 1 INVITE
S: Contact: <sip:netann@192.0.2.41>
S: Content-Type: application/sdp
S: Content-Length: 317
S:
S: v=0
S: o=NetAnn 2890844527 2890844527 IN IP4 192.0.2.41
S: s=Session SDP
S: c=IN IP4 192.0.2.41
S: t=3034423619 0
S: m=audio 17684 RTP/AVP 0 8 3 18 98 101
S: a=rtpmap:0 PCMU/8000
S: a=rtpmap:8 PCMA/8000
S: a=rtpmap:3 GSM/8000
S: a=rtpmap:18 G729/8000
S: a=fmtp:18 annexb=no
S: a=rtpmap:98 iLBC/8000
S: a=rtpmap:101 telephone-event/8000
S: a=fmtp:101 0-16
C: ACK sip:netann@192.0.2.41 SIP/2.0
C: From: UserA <sip:UAA@example.com>
C: To: NetAnn <sip:annc@ms2.example.com>
C: Call-ID: 8204589102@example.com
C: CSeq: 1 ACK
C: Content-Length: 0Once 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 . 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.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 shows the high-level
message flow between all the components, including the IMAP
server.)C: INVITE sip:ivr@ms.example.com SIP/2.0
C: From: UserA <sip:UAA@example.com>
C: To: IVR <sip:ivr@ms.example.com>
C: Call-ID: 3298420296@example.com
C: CSeq: 1 INVITE
C: Contact: <sip:UAA@192.0.2.40>
C: Content-Type: application/sdp
C: Content-Length: XXX
C:
C: <SDP Here>
S: SIP/2.0 200 OK
S: From: UserA <sip:UAA@example.com>
S: To: IVR <sip:ivr@ms.example.com>
S: Call-ID: 3298420296@example.com
S: CSeq: 1 INVITE
S: Contact: <sip:ivr@192.0.2.41>
S: Content-Type: application/sdp
S: Content-Length: XXX
S:
S: <SDP Here>
C: ACK sip:ivr@ms.example.com SIP/2.0
C: From: UserA <sip:UAA@example.com>
C: To: IVR <sip:ivr@ms2.example.com>
C: Call-ID: 3298420296@example.com
C: CSeq: 1 ACK
C: Content-Length: 0
C: INFO sip:ivr@192.0.2.41 SIP/2.0
C: From: UserA <sip:UAA@example.com>
C: To: IVR <sip:ivr@ms.example.com>
C: Call-ID: 3298420296@example.com
C: CSeq: 2 INFO
C: Content-Type: application/mediaservercontrol+xml
C: Content-Length: 423
C:
C: <?xml version="1.0"?>
C: <MediaServerControl version="1.0">
C: <request>
C: <playcollect id="332985001"
C: firstdigittimer="0ms" interdigittimer="0ms" extradigittimer="0ms"
C: skipinterval="6s" ffkey="6" rwkey="4" escape="*">
C: <prompt stoponerror="yes"
C: locale="en_US" offset="0" gain="0" rate="0"
C: delay="0" duration="infinite" repeat="0">
C: <audio url="imap://joe@example.com/INBOX/;uid=24356/;section=1.2;
expire=2006-12-19T16:39:57-08:00;urlauth=anonymous:
internal:238234982398239898a9898998798b987s87920">
C: </prompt>
C: </playcollect>
C: </request>
C: </MediaServerControl>
S: SIP/2.0 200 OK
S: From: UserA <sip:UAA@example.com>
S: To: IVR <sip:ivr@ms.example.com>
S: Call-ID: 3298420296@example.com
S: CSeq: 2 INFO
S: Contact: <sip:ivr@192.0.2.41>
S: Content-Length: 0
S: <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@192.0.2.40 SIP/2.0
S: From: IVR <sip:ivr@ms.example.com>
S: To: UserA <sip:UAA@example.com>
S: Call-ID: 3298420296@example.com
S: CSeq: 5 INFO
S: Contact: <sip:ivr@192.0.2.41>
S: Content-Type: application/mediaservercontrol+xml
S: Content-Length: XXX
S:
S: <?xml version="1.0"?>
S: <MediaServerControl version="1.0">
S: <response id="332985001" request="playcollect" code="200"
S: reason="escapekey" playduration="34s"
S: playoffset="34s" digits="" />
S: </MediaServerControl>
C: SIP/2.0 200 OK
C: From: IVR <sip:ivr@ms.example.com>
C: To: UserA <sip:UAA@example.com>
C: Call-ID: 3298420296@example.com
C: CSeq: 5 INFO
C: Content-Length: 0
C: BYE sip:ivr@192.0.2.41 SIP/2.0
C: From: UserA <sip:UAA@example.com>
C: To: IVR <sip:ivr@ms.example.com>
C: Call-ID: 3298420296@example.com
C: CSeq: 6 BYE
C: Content-Length: 0
S: SIP/2.0 200 OK
S: From: UserA <sip:UAA@example.com>
S: To: IVR <sip:ivr@ms.example.com>
S: Call-ID: 3298420296@example.com
S: CSeq: 6 BYE
S: Contact: <sip:ivr@192.0.2.41>
S: Content-Length: 0This 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 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 MUST be followed. That is, if the server advertises AUTH=ANONYMOUS
IMAP capability, the media server MUST use the AUTHENTICATE command
with 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). If the IMAP server does not advertise URLAUTH=BINARY in its
post-authentication capability string, then the media server returns a
suitable error code to the client.The additional parameters to the URLFETCH command
specified in (URLFETCH
BINARY) are used by the media server to tell the IMAP
server to remove any transfer encoding and return the content
type of the media (as content type information is not
contained in the IMAP URL).
A successful URLFETCH command will return the message part
containing the media to be streamed.
If the URLFETCH was unsuccessful, then the media server MUST return an
appropriate error code 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
)) (BINARY ~{655350}
S: [ ~655350 octets of binary data, containing NUL
octets ])
S: a002
OK URLFETCH completed. C: a003 LOGOUT S: a003 OK
LOGOUT completed.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.This document proposes the use of URLAUTH
"pawn tickets", received over IMAP, and transmitted
over SIP, possibly within the MSCML payload of
RFC 5022, 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 with respect to
the security implications of using IMAP URLs:
Use of an anonymous pawn ticket grants
access to any client of the IMAP server without requiring any
authentication credentials. The security mechanisms
referenced above (with the caveats specified below) SHOULD
be used to prevent unauthorized access to the pawn
ticket.
Use of pawn tickets that contain the "submit+" access
restricts access to the content to those entities that are
authorized users of the IMAP server for the purposes of
retrieving content. Use of such pawn tickets is thus
desirable and so
describes when such pawn tickets should be used.
If the announcement service is used to set up streaming, then
RFC 4240 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), 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.
To fully protect the pawn ticket, the IVR service,
RFC 5022, 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. Information on how to use S/MIME to
protect SIP payloads can be found in .
This document describes a mechanism that makes use of two
separate servers to achieve the goal of streaming the content
desired by the client. A major security implication of this is
that the media server and IMAP server may well be located in
separate administrative domains. This leads us to consider the
security implications of a three-way protocol exchange, and
the potential trust model implicit in that tripartate
relationship. The security implications of the individual
protocols have already been referenced, therefore this section
describes the security considerations specific to the
three-way data exchange, specifically:
The client grants the media server full access to the
potentially-private media content specified by the IMAP URL. As a
result, the client is responsible for verifying the authenticity of
the media server to a degree it finds acceptable for the
content (we can refer to this process as determining the
"trust" that the client has in a particular media server).
The security mechanisms provided by SIP and RTP may be
used for this purpose, as well as out of band
mechanisms such as pre-configuration.
However, since the media server will retrieve content
from an IMAP server on the users behalf, the issue of
security between the IMAP server and the media server
also needs to be considered. A client has no way of
determining (programatically at least) the security of the
exchanges between the media server and the IMAP
server. However, it can determine, using the "submit+" token
that is part of the media server
discovery mechanism described in , that the media server has a
pre-existing authentication relationship with the IMAP
server for the purposes of retrieving content using IMAP
URLs.The above two security considerations will influence the decision
the client makes with regards to generation of the pawn ticket
that is subsequently passed to the media server. This
document mandates the use of URLs protected with the
"submit+" access prefix where the client knows in advance
that the "submit+" authentication relationship
between media server and IMAP server exists. However, it
does allow the use of anonymous pawn tickets where the
possibility exists that use of "submit+" would cause
streaming to fail.
There exists the possibility of an attack by a malicious
media server against pawn tickets protected with the
"submit+" access prefix. In this attack, the client
contacts a media server, MS1 (note this is not a
man-in-the-middle attack per-se, as the client is
intentionally contacting the media server in question),
and that media server then proxies the streaming request
to a second media server, MS2 that it has determined or guessed to
have "submit+" authentication credentials with the IMAP server
specified in the pawn ticket. While this attack would
technically defeat the protection of the "submit+" access
prefix, the security mechanisms inherent in SIP would
prevent unauthorized access to MS2 by malicious clients.
TODO:
- S/MIME encrypted attachments - what does this do?
- IMAP URL logging on media servers
Additionally, many of the security considerations in the
Message Submission BURL Extension apply to this document,
particularly around the use of pawn tickets and prearrange trust
relationships such as those described above.
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 Entry Registration Type: ServerName: /pubic/mediaServers
Description: Defines a set of URIs containing the locations of suitable media
servers for streaming multimedia content
Content-type: text/plain;charset=utf-8
Contact: ncook@cloudmark.comThis 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;
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 command for message
submission.The use of URLAUTH in this specification is believed to be pursuant 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.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 5022 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.
The following syntax specification for the mediaServer METADATA entry
value uses the Augmented Backus-Naur Form (ABNF) notation as specified
in RFC 4234 and the "absolute-URI" definition from
RFC 3986.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"] Eric Burger, eburger@standardstrack.comEric Burger provided the initial inspiration for this document, along
with advice and support on aspects of the media server IVR and
Announcement services, as well as help with the
IETF process.Many people made helpful comments on the document, including Alexey Melnikov,
Dave Cridland, Martijn Koster, and a variety of folks in the Lemonade and Sipping WGs. Basic Network Media Services with SIPInternet Message Access Protocol (IMAP) - URLAUTH
ExtensionUniversity of WashingtonInternet Message Access Protocol - Version 4rev1University of WashingtonIMAP URL SchemeUniversity of WashingtonIsode Ltd.Oracle CorporationSIP: Session Initiation ProtocolS/MIME Version 3.1 Message Specification"RTP: A Transport Protocol for Real-Time ApplicationsKey words for use in RFCs to Indicate Requirement
LevelsMultipurpose Internet Mail Extensions (MIME)The TLS ProtocolSDP: Session Description ProtocolMedia Server Control Markup LanguageURLAUTH Binary ExtensionIMAP METADATA ExtensionAppleAugmented BNF for Syntax Specifications: ABNFGeneric URI SyntaxAnonymous SASL Mechanism
OpenLDAP FoundationMessage Submission BURL Extension