Noware

neil.cook@noware.co.uk

Applications Lemonade 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. The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined 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 the line breaks between those lines are for editorial clarity only and are not part of the actual protocol exchange.

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 and particularly the media server profile 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 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). 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.

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 that allows anonymous access from external systems to specific message parts; for example, an audio clip. 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 4722) - 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, in order to accommodate the passing of a content transfer encoding parameter. This document also proposes a new attribute for the IMAP METADATA Extension, which is used to provide information about zero or more suitable media servers for use with the IMAP server.

The approach is shown in the following figure:

The proposed mechanism has the following steps: 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. Client constructs an IMAP URL referencing the message part, and uses the GENURLAUTH 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. Client connects to a SIP Media Server using the Announcement Service as specified in RFC 4240, or the IVR Service as specified in RFC 4722, 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 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 or RFC 4722. + Media Server(s) used by the mobile device support the IMAP URL 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.

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 2192. 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 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. 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

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 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: 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 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 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: [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 . 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.

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 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 , the client SHOULD use a suitable end-to-end encryption method, such as S/MIME. 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.net SIP/2.0 < SIP Headers 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. 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 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 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.

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 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 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

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 . 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. 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. 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 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 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> 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

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 to encrypt the communication path, unless the client and server policy both allow for insecure communications. 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} S: U2kgdmlzIHBhY2VtLCBwYXJhIGJlbGx1bS4K 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. For simplicity, SIP session termination (BYE etc.) is not shown.

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. | | | GENURLAUTH | | |---------------------------->| | | | | | SIP INVITE | |===========================================================>| | | | | | URLFETCH | | |<-----------------------------| | | | | 200 OK | |<===========================================================| | ACK | |===========================================================>| | | | | Stream Message Part (RTP) | |<+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++| | | | ]]>

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. | | | 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) | |<===========================================================| ]]>

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: IMAP clients SHOULD use encryption such as TLS to secure the communication path to the IMAP server 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.

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 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.

The following syntax specification for the mediaServer METADATA entry value uses the Augmented Backus-Naur Form (ABNF) notation as specified in RFC 2234. 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")

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.

Cantata University of Washington University of Washington University of Washington