Subject: RTSP open issue: range: bytes= specification

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 30 Oct 1997 11:15:37 -0500

In the past, it has been suggested that Range: may also take a
non-time-based specification, such as the byte range found in HTTP. 

The application that was brought up was that of a cache server: The
cache server would "read ahead" at maximum (TCP) speed and buffer a
finite amount of data for its client. This makes sense, as it decreases
client delay and is more "network-friendly". 

ftp or http cannot be used here, since the names, locations, and access
permissions of the media object may well be different, if the files are
available via these services at all.

Instead of using Range requests in this case, however, the cache server
can just stop reading data from the origin server when its local buffer
is full and resume reading when the client has caught up.

Generally speaking, adding Range types is reasonably harmless, as not
all servers need to support all types for all types of files. Not all
range types make sense for all types of data. SMPTE and clock, for
example, cannot always be readily applied, so I see no problem in
principle with adding a range option of limited use. However, for the
cache example, this is only useful if very widely deployed by origin
servers, across all media types.

Unfortunately, for many media objects, byte range make little sense, as
they make be hard to determine (Do you count the QuickTime or ASF header
information? If not, positioning gets hard. Do you include any RTP
encapsulation information? What about non-file-based storage, e.g., as
frame objects in a database? If you position by 'seek', do you transmit
ADUs or just plain byte ranges?).

Unless there is a clearly defined need that cannot be addressed in any
other way, I would stay away from this for now.

Henning

---

From: Alagu Periyannan <[email-masked]>
Date: Thu, 30 Oct 1997 12:40:12 +0100

>client delay and is more "network-friendly".

On a separate note, I really like this idea of read ahead with TCP.

I would be interested in using such a TCP read ahead scheme
in regular clients. It can be used to download media data from the
closest key frame up to the current frame for a play spurt,
before starting to render at the client.

This will provide a better user experience and be more bandwidth
friendly than what is possible with RTSP/RTP today.

With RTSP as it is defined today, good servers will back up
to the closest key frame for every stream and start sending
from there rather than at the current play time. The server
can send this "pre-start" data in two ways,

1) as fast as possible
2) in real time

Choice 2 can lead to bad user experience if the key frames are
far apart. Choice 1 will lead to bandwidth violation.

However, Choice 1 with TCP download of the "pre-start" data
will be "network friendly". But now we're getting into sending
the "pre-start" data over TCP and after that using RTP/UDP.

Is this workable within current RTSP spec.? Probably not.

---------------------------------------------------
Alagu Periyannan                   [email-masked]

Interactive Multimedia Group
Apple Computer, Inc.

---

From: Rob Lanphier <[email-masked]>
Date: Thu, 30 Oct 1997 15:15:12 -0800

>Is this workable within current RTSP spec.? Probably not.

It is possible with the current spec, but it could be optimized in the
future (there are obviously fields missing, but I hope you get the idea):

SETUP rtsp://foo/bar RTSP/1.0
Transport: RTP/AVP/TCP;interleaved=0

PLAY rtsp://foo/bar RTSP/1.0
Range: npt=6-7
Speed: 255

SETUP rtsp://foo/bar RTSP/1.0
Transport: RTP/AVP/UDP;unicast;client_port=2020-2021

PLAY rtsp://foo/bar RTSP/1.0
Range: npt=7-

I'm handwaving out the teardown and everything else, but this should work.
The point is that we can handle this at the simplest level right up front.
If it turns out that everybody does this, then we can standardize a
shorthand for this.

Rob

---
Rob Lanphier ([email-masked])    Voice: (206)674-2322   Fax: (206)674-2699
RealNetworks:  http://www.real.com
RTSP Info:     http://www.real.com/rtsp
Firewall Info: http://www.real.com/help/firewall