Subject: RFC 2326 RTSP comments

From: Magnus Westerlund <[email-masked]>
Date: Thu, 20 Sep 2001 14:32:53 +0200

Hi,

I have found a number of issues realted to RTSP, RFC 2326. They belong
to three
categories; Errors in specification, these I belive are real errors.
Requests
for clarfications of the specification, contains issues that could be
better
explained and/or should be defined. Proposals for improvement, contains
my
suggestion on what would make the specification better.

It is possible that some has been raised before, but as the work to move
RTSP to Draft standard has started I believe it to be good to bring up
all known problems.

Errors in specification
-----------------------
1. Several references are misorderd.

2. Erronous example on page 36 last paragraph. Illegal values of range
header,
  The call for pause: range 16 will result in Illegal range response.

3. Page 38 first example: Example missing session header in response.
Should not the
  client respond with what session id the respond relates to, as the
request
  contained one.

4. Table with RTSP headers page 45, contains the following errors?:
  - A session header is not required when using describe.
  - Proxy Authenticate is missing all values on what it is.
  - The transport header is specifed as required in 12.0 table, but
    the text in 12.39 says it MAY be included in requests and responses.

5. Page 59, the "source:" paragrah what is the intention? Is it just
missing in the
  BNF for transport headers?

6. Page 61, Transport BNF: Should not multicast/unicast be proceeded by
a ";"? Is
  multiple entries of the same type allowed? Are there any requirement
on having
  multicast/unicast first?

7. Section 3.4 definition of session-id should it not be:
  session-id   =   8*( ALPHA | DIGIT | safe )
  instead of 1*?

8. SDP examples in spec is in wrong order:
  The SDP specifcation requires a certain order between the type names,
see
  section 6 in RFC 2327.

 14.4 Live Media Presentation Using Multicast
 ...
 m=audio 3456 RTP/AVP 0
 a=control:rtsp://live.example.com/concert/audio
 c=IN IP4 224.2.0.1/16

 and

 C.2 Aggregate Control Not Available
 ...
 s=I came from a web page
 t=0 0
 c=IN IP4 0.0.0.0

9. Transport ABNF, mode line, The "=" lacks " around it. There are also
  unclearities if you could actually have mode=""PLAY","RECORD"" ?
Anyway it
  need clarification

10. Page 68 example with transport header uses <mode=play> which does
not include
  " which the ABNF says it should be. Correct according to ABNF is
mode="PLAY"

11. npt-range sec 3.6 lacks "npt=" in the begining of the definition.

12. Sec 12.33 RTP info syntax of RTP info is wrong, compared to the
example. The
  current syntax specifec a comma separated list of URLS then follows
the
  parameters. Should it not be like this?
  RTP-Info        = "RTP-Info" ":" 1#rtp-info-spec
  rtp-info-spec   = stream-url 1*parameter
  stream-url      = "url" "=" url
  parameter       = ";" "seq" "=" 1*DIGIT | ";" "rtptime" "=" 1*DIGIT

Requests for clarfications of the specification
-----------------------------------------------
13. HTTP references
  RFC 2326 reference RFC 2068 which has been obsoleted by RFC 2616.
  How should you relate to the new RFC, and what to do with removed
header
  headers?

  Following things are missing in RFC2616
  - public header

14. What is the definition of 1\# in the BNF? I can't find it in either
RFC
  2068, 2234, 2326, or 2616.

15. Server can't respond to a bad request if no sequence number is
present in the
  request. Resulting in that the client does not know that the server
has
  received it and has issues. Please clarify when a server is allowed to
send
  response to bad request.

16. How shall the pause point be specifed? Is the only correct way to do

  it "(start time)- "? The use of range with time? It seem to be
unecessary as
  play with range works instead.

17. When you queue items that has a activation time, does that override
the order
  the events are queued? Play(1) has time A, Play(2) has time B time A
are
  after time B. Assumption on how it work: First Play(2) activated at
time B,
  then at time B Play(1) tries to start, if already playing, it is
queued as a
  normal untimed event.

18. NPT time in range is allowed to be specifed as "-nptime". No other
timeformat
  allows that, why?

19. Which connection models are required. Is non persitent TCP
connections a MUST
  support, or only RECOMMENDED?

20. A single media stream is playing. Then an aggregated control which
include
  this stream is issued a play. How should this be interpreted? We use
that it
  is queue and waits until all single streams under that aggregated
control finish their play.

Proposals for improvement
-------------------------

21. A complete ABNF of the RTSP specification could be collected in a
Appendix.
  This would make it easier to find how things are defined when doing
  implementation of the specification.

22. Shouldn't the example of RTP-Info page 56 contain timestamps?

Cheers

Magnus Westerlund

Audio Technology, Ericsson Research
----------------------------------------------------------------------
Ericsson Radio Systems AB  | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]