Subject: Re: Submission of RTSP V1.0 (Real Time Streaming Protocol) for MMUSIC Working Group of IETF

From: [email-masked] (Atri Chatterjee)
Date: Wed, 09 Oct 1996 16:27:23 -0700

Congratulations on a commendable team effort.

--Atri

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 10 Oct 1996 18:18:37 +0100

coupolke of things (before i have read this properly)
1/ the name -there is a near clash with NTT's Real Time Stream
Pipeline Protocol, RSTP (which has some of the same functionality
somewhere in it...)

2/ this is really a Control protocol, in fact its really a VCR control
protocol so it'd be neat if it looked a bit more abstract (transport
protocol independance for the Control part, as well as the data part,
which you've obviously done very nicely....)
and its name should reflect that (i was jumping up and fdown shouting
about it in the lab til someone pointed this out and made me read it
properly:-)

comments later when i've read it in detail...

but looks v. interesting....

regards

jon

---

From: Mark Handley <[email-masked]>
Date: Thu, 10 Oct 1996 18:19:50 +0100

>We are pleased to submit the following Internet-Draft of the
>RTSP - Real Time Streaming Protocol, which we at Netscape and
>Progressive Networks have been working on.

Thanks for sending the draft - clearly a significant amount of work
has gone into it.

This isn't strictly within the charter of the MMUSIC group, but as
previous discussion on similar topics has occurred here, I think it is
appropriate to discuss it on this mailing list.  We should discuss
whether this area is appropriate for the MMUSIC sessions at the
upcoming IETF, but I haven't had a chance to talk to my co-chairs or
AD about this.

I have several comments, in no particular order...

- This overlaps heavily with the work Jeff Smith has been coordinating
on server control, although Jeff also addresses controlling servers to
*record* real-time sessions.  It would be good to see both efforts
come together into a single framework/protocol if there is enough
common ground.  Some notes on his work are available from:
  http://alicia.nttlabs.com/people/sumisu/streams-bof/

- the options mechanism is pretty complicated - as a general rule I
(personally) prefer protocols without complicated option mechanisms.
Telnet implementations (which you base the negotitation OK) often
don't bother to implement any of the options these days.

- can a single fetch give multiple stream-header replies?  if not, how
do you do *multi*media sessions?

- in the stream-header flags, you can specify U, ie that the server
can send UDP if required.  There's no equivalent T flag.  Does this
mean that you assume the stream can alwasy be sent by "reliable
means"?

- how does the client know whether reliable transfer is *recommended*
over unreliable transfer (or vice-versa) from this flag?

- in set-transport, you specify the SSRC.  Perhaps this really should
be the CNAME as the SSRC can change during a session if a clash
occurs.

- in play-range, the timestamp is in ms.  This doesn't give sufficient
accuracy to specify exact video frames unambiguously based on a 90KHz
video clock as used by RTP.  

- udp-resend is kind-of wierd.  Requesting a resend of a UDP packet
via a TCP control protocol that may add an aribtrary delay seems
strange.

 - in the RTSP-Audio family, reserving a codec ID range for Microsoft
Audio Compression Manager but not referencing RTP AV profile payload
types or ITU standards seems odd, particularly as there are likely to
be overlaps.

- I can't figure out where the stuff in Appendix D fits in, but
perhaps I just haven't read the spec through closely enough.

- Appendix C duplicates work done in the Session Description Protocol.

In general, my main reservation about this is the use of TCP (which
provides arbitrary delays to achieve reliability) to control real-time
UDP based streams where timing is all important.  I'd prefer to see a
mapping of this protocol over UDP...

Mark

---

From: Stephen Casner <[email-masked]>
Date: Thu, 10 Oct 1996 13:05:32 -0700 (PDT)

Mark,

> upcoming IETF, but I haven't had a chance to talk to my co-chairs or

It was my suggestion to the folks at Netscape that MMUSIC would be the
right WG to consider this protocol.  I hold this opinion because I
believe RTSP is primarily a control protocol, as Jon Crowcroft also
notes.  I've also suggested that the name be changed to ma
e that
control functionality more clear, though I didn't have any brilliant
ideas for a new name to offer.

Yes, there is one aspect of this proposal that falls more in the AVT
domain, specifically that it defines a compressed form of RTP that may
be selected as an alternative to RTP.  However, at the Montreal
meeting, the AVT group concluded that a combined IP/UDP/RTP
compression should be standardized instead and that defining an
RTP-only compression as an interim measure did not make sense as an
IETF standardization activity because of the time it would take.  In
essence, we left it to the vendors to take interim steps if they felt
it was necessary.  My personal preference would be to just have this
proposal specify the use of real RTP all the time, and I don't think
that defining an interim RTP compression as part of a higher-layer
protocol ameliorates the problems discussed in Montreal.

>   http://alicia.nttlabs.com/people/sumisu/streams-bof/

Yes.  This is why I think MMUSIC is the right working group.

							-- Steve

---

From: Mark Handley <[email-masked]>
Date: Thu, 10 Oct 1996 18:19:50 +0100

Mark

---

From: Mark Handley <[email-masked]>
Date: Thu, 17 Oct 1996 16:32:22 +0100

Mark Handley writes
>upcoming IETF, but I haven't had a chance to talk to my co-chairs or

Just for the record, Allison Mankin (our AD) came back to us on this
agreeing that we should regard RTSP and similar *control* protocols as
being within the scope of the MMUSIC working group.  If such a
protocol can re-use existing MMUSIC work (such as SDP) then that would
be ideal.

However, work on compressed RTP (as included in the current RTSP
draft) should be in the AVT WG, and a resulting RTSP or RTSP-like
specification should reference the compressed RTP work coming out of
the AVT WG.

This isn't supposed to be dogma - just an attempt to avoid too much
duplication of effort.

Mark