Subject: Notes from the RTSP Interoperability Pilot

From: Rob Lanphier <[email-masked]>
Date: Tue, 21 Oct 1997 20:06:48 -0700

Notes from RTSP Interoperability Pilot Oct. 16-17 Seattle, WA

Last week, engineers from Apple, Columbia University, IBM, Netscape,
RealNetworks, and Sun/JavaSoft met to test the interoperability of early
RTSP implementations.  We were able to demonstrate limited interoperability
between most of the implementations represented, and were convinced that
with a small amount of additional work, all implementations would work
together as expected.  Thus, we came to the conclusion that the current
draft-04 specification, with the clarifications listed below, is
implementable and a sufficient means of obtaining interoperability.

The editors of the RTSP specification will be integrating the
clarifications that were introduced last week into the spec, fix any minor
inconsistancies and typos, and issue draft-05.  After issuing draft-05, we
would like to then place a last call on the resulting document, placing it
on track to be submitted to the IESG for consideration as a proposed
standard 4 weeks later.

Here's the list of issues that we ran into:

1.  There was some confusion about DESCRIBE being an optional method.
    Though not stated as such, support for at least one session description
    format is a practical necessity.  There are three ways that a client
    may receive this:

    a.  Via RTSP's DESCRIBE method
    b.  Via some other protocol (HTTP, etc.)
    c.  Via the command line or standard input (thus working as a browser
        helper app launched with an sdp file)

    The spec does not specify which of these methods is the minimum, and
    may not need to.  However, many clients at the interoperability pilot
    only supported (a), and there was one server did not support the
    DESCRIBE method.  This made interoperability with this server
    impossible.

    Therefore, from a practical standpoint, there needs to at least needs
    to be a cautionary note about this.  It should be highly recommended
    that minimal servers support the DESCRIBE method, and highly
    recommended that minimal clients support (c) above.  The two separate
    models that these methods encompass should also be explained somewhere
    in the specification.

2.  How many DESCRIBEs are required?

    We never really nailed down how many DESCRIBES should be done, and
    implementations varied on this front. The attendees agreed that the
    best way to deal with initial versions of SDP is the all or nothing
    approach.  In initial implementations, all SDP should be completely
    valid SDP, and given complete information about a set of streams,
    implementations should trust that information and forgo doing another
    DESCRIBE.

3.  Mapping RTP timestamps to NTP timestamps (wall clock) to NPT timestamps
    (movie time)

    There was some confusion about the different types of timestamps
    associated with a stream.  It was generally agreed upon that the
    currently specified mechanism is fine, but probably should be
    clarified.

    RTP timestamps map to NTP timestamps via RTCP.  RTP timestamps map onto
    NPT timestamps via the RTSP RTP-Info field.  NTP timestamps map to NPT
    timestamps via calculation through their common association to the RTP
    timestamps.  In the future, we may wish to provide the NTP timestamp
    directly in parallel with the RTP-Info field, but we decided that it
    probably wouldn't be necessary for the time being.

4.  New error message "461 Transport not supported"

    An oversight in the current specification is a lack of a way to say
    that none of the provided transports are supported by the server.  This
    is a simple addition to the spec.

5.  Making seeking work correctly with standard user interfaces

    There are a couple of fields that MUST be implemented in order for
    clients to be expected to support seek functionality in the standard
    way (a slider bar)

    -  a=length: attribute in SDP
    -  RTP->NPT mapping via the RTP-Info field

    It should be noted in RTSP draft-05 that the RTP timestamp in the
    RTP-Info field may not necessarily map to the first sequence number,
    but instead maps to the NPT time from the start value in the Range
    field.

6.  Single stream SDP

    There were questions as to whether servers should be required to
    support single-stream files with a single URL throughout.  This would
    mean that multistream servers would need to special case this
    particular case.  Here's an example of how a multi-stream server might
    expect a single-stream file to be served:

    C->S  DESCRIBE rtsp://foo.com/test.wav RTSP/1.0
          Accept: application/x-rtsp-mh, application/sdp
          CSeq: 2
          
    S->C  RTSP/1.0 200 OK
          CSeq: 2
          Content-base: rtsp://foo.com/test.wav/
          Content-type: application/sdp
          Content-length: 681
          
          v=0
          o=- 872653257 872653257 IN IP4 172.16.2.187
          s=mu-law wave file
          i=audio test
          t=0 0
          m=audio 0 RTP/AVP 0
          a=control:streamid=0
          
    C->S  SETUP rtsp://foo.com/test.wav/streamid=0 RTSP/1.0
          Transport: rtp/avp/udp;client_port=6970-6971;mode=play
          CSeq: 3
          
    S->C  RTSP/1.0 200 OK
          Transport: rtp/avp/udp;client_port=6970-6971;
                     server_port=6970-6971;mode=play
          CSeq: 3

    C->S  PLAY rtsp://foo.com/test.wav RTSP/1.0
          CSeq: 4

    S->C  RTSP/1.0 200 OK
          CSeq: 4

    Note the different URL in the SETUP command, and then the switch back
    to the aggregate URL in the PLAY command.  This makes complete sense
    when there are multiple streams with aggregate control (the proverbial
    1-1-n), but is less than intuitive in the special case where the number
    of streams is one (n=1).

    In this special case, we would hope that servers would be forgiving of
    implementations that send:

    C->S  PLAY rtsp://foo.com/test.wav/streamid=0 RTSP/1.0
          CSeq: 4

    In the worst case, servers should send back:

    S->C  RTSP/1.0 460 Only aggregate operation allowed
          CSeq: 4

    One would also hope that server implementations are also forgiving of
    the following:

    C->S  SETUP rtsp://foo.com/test.wav RTSP/1.0
          Transport: rtp/avp/udp;client_port=6970-6971;mode=play
          CSeq: 3

    Since there is only a single stream in this file, it's not ambiguous
    what this means.

7.  Multiple PLAYs on different URLs after a single SETUP

    One of the functions that one of the implementors would like to have is
    the ability to issue a single SETUP, and then multiple PLAY messages on
    different URLs.  The idea would be to leverage the first SETUP to
    stream multiple presentations over the same path.

    It was felt that as long as such implementations were robust enough to
    handle those implementations that didn't support this functionality,
    there shouldn't be a problem with supporting this between matched
    clients and servers.  However, implementations which overload existing
    methods in a non-standard way or add new methods do so at their own
    risk, and future versions of RTSP are not encumbered with maintaining
    backward compatibility with such implementations.

8.  Should there be a MUTE method, or should we overload PAUSE:

    How should implementations handle stream-level control of aggregate
    streams if they choose to support it?  In other words, if an aggregate
    PLAY command is issued, then if a client wishes to shut off one of the
    streams, how should this be done?  - PAUSE on the stream URL - MUTE on
    the stream URL - some other means (turn the "bandwidth" knob on the
    stream down to zero, for instance)

    We will not actually specify how this should be done, but we should at
    least provide a recommendation to shape future versions of the
    specification and to avoid overloading where it shouldn't occur.

    Once again, it was felt that as long as such implementations were
    robust enough to handle those implementations that didn't support this
    functionality, there shouldn't be a problem with supporting this
    between matched clients and servers.  However, implementations which
    overload existing methods in a non-standard way or add new methods do
    so at their own risk, and future versions of RTSP are not encumbered
    with maintaining backward compatibility with such implementations.

Each of these issues will be clarified in draft-05 of RTSP.

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