Streaming

["Kirchhoff, Lee" <lee.kirchhoff@xxxxxxxx>]

In reviewing the goals and current approach of VPIM v3 I applaud the efforts
to support unified messaging by introducing the primary content type notion
and adopting codecs that are usable on a PC. However there is an important
need that is not yet being adequately addressed -- streaming. Responsiveness
in the delivery of message content is important to users. Downloading an
entire body part before presenting it is not a very responsive way to
present a message whose primary content is audio, especially over modem
connections  Streaming is much more effective since it removes total message
size as a factor in responsiveness.

To date there has been some discussion on the IMAP and VPIM lists about how
to introduce support for streaming. The basic need is to give the messaging
client more control over how the content is retrieved. The proprosal on the
IMAP list by John Haxby to introduce a BINARY fetch capability helps
streaming by eliminating base64 overhead but it still assumes that the media
flows over the IMAP session's TCP connection. That has the advantage of
staying within the security framework of IMAP but it has the disadvantage of
using TCP, which is not a very effective base for streaming (UDP is much
better), and it is not necessarily easy for the IMAP client to hand off the
stream of data being received to a separately invoked media player. Another
proprosal on the IMAP list by Glen Parsons introduces a DATA fetch specifier
with the client having the option to specify an address for the server to
deliver the content via RTP. That looks attractive in certain situations but
does not fit well with most existing commercial media players that are
structured around being given a handle for initiating a connection to a
media source. This approach also potentially encounters additional firewall
difficulties since the server is connecting to the client, rather than
sticking with client initiated connections and only having to deal with
firewalls in one direction.

An approach that seems more effective in meeting the general streaming needs
is sketched below. It does not affect the MIME structuring of the message.
It centers around a new IMAP4 extension called STREAM.

-- Introduce a new IMAP4 extension named STREAM that a server declares in a
CAPABILITY response.
-- A server supporting this extension responds to STREAM as a BODY part
specifier in a FETCH; for example, "A001 FETCH 3 BODY[1.2.STREAM]" would
request to
stream the second body part of the first multipart of the third message.
-- When an IMAP4 client requests a STREAM for a body part, the server does
not respond with the body part data itself but rather information about how
the body part can be streamed over a separate connection.
-- The client can then put this fetched streaming setup information in a
file (i.e., a redirector file) and pass it to the media player configured
for streaming. The streaming setup information could include several
alternatives for establishing a streaming connection. Basically it looks
like a prioritized list of URLs.
-- The media player connects to the server using one of the specified
choices, receives media packets on the established stream, and presents the
data to the user appropriately for the given media type.
-- The STREAM specifier would only be valid for certain MIME body part
types, presumably only audio and video.
-- If the client requested STREAM on a body part for which the server could
not support streaming, the server would return a NO response. The client
would then use a standard non-streaming FETCH to get the body part.
-- The client would not use streaming in situations where the message was
being forwarded or being downloaded for viewing during disconnected
operation.
-- The security of the streaming connection could be managed by passing a
security token as part of the streaming information. The IMAP4 server shares
this token with the media server so that the media server can properly
accept or reject the connection from the media player.

The above approach is aimed at empowering an IMAP4 messaging client to offer
streaming as an option to users. It does this by giving the client the
option of fetching a pointer to the message content rather than fetching the
content itself. One of the details to be worked out with this approach is
how this "pointer" is communicated. This approach to streaming does not
affect the MIME formatting of the message. 

So what form does the "pointer" take? A possible starting point is ASF
(Advanced Streaming Format). This format defines a redirector file for
communicating the streaming source and protocol to the media player. It
nicely fills the need. But rather than settling on a single redirector file
format, we may want to consider supporting a registration of different
formats. In that case it would be necessary to expand upon the server's
STREAM declaration of capability or the client would need a way to declare
the format it wanted to use in the FETCH request.

The redirector file approach cleanly separates IMAP4 from the details of the
streaming. It leaves those details to the media player and the media server.
This can include management of stream security. It potentially could also
include negotiation of the media encoding to be used (e.g., PCM vs. GSM)
during stream setup in cases where the server can support media
transformation.

This proposal obviously requires messaging client adoption for it to be
useful, but that is generally true of the other proposed unified messaging
related enhancements in VPIM v3.  I am seeking feedback to fine tune this
approach and make it workable for a broad set of implementations.

Lee Kirchhoff
PulsePoint Communications
lee.kirchhoff@xxxxxxxx