Date: Wed, 21 Jan 1998 10:02:47 -0800 Resent-Date: Wed, 21 Jan 1998 18:04:48 +0000 (GMT) Resent-From: Ian Wakeman From: Ian Wakeman To: schulzrinne@cs.columbia.edu, anup@netscape.com, robla@progrnet.com Cc: mhandley@cs.ucl.ac.uk, jon@cs.ucl.ac.uk Subject: rtsp draft X-Mailer: VM 6.33 under 19.16 "Lille" XEmacs Lucid Resent-To: robla@prognet.com I'm scribbling some words on rtsp for a project with jon and mark, and I've got a few comments and questions on draft 7 of the spec. 1. PLAY requests are assumed to be queued up at the the server, and its stated that PAUSE requests stops NOW or at the given time. Sending a PLAY continues from the paused point. What happens when a PLAY with a range is sent at this point? Does it get queued behind the other PLAY requests, starting from the paused point? Is the queue of outstanding PLAY requests trashed? Which leads to another question - how can outstanding requests be trashed in the general case. 2. The use of the session header to refer to the current instance is well-hidden. There should be some descriptive text int he first few pages talking about the use of the session id, and the examples in 10-5 and 10-6 should include the session header. 3. The proposal is vague about when session identifiers are generated especially for aggregate sessions. If a SETUP request to a sserver includes a SESSION id, must the server bundle this setup request into the existing session? 4. In the case of only aggregate control of a container, its ugly that there is no indication that this is the case. Having a client respond to being told on attempting to control the stream that only "aggregate control is available" means that either the user interface constructed for this stream will be broken, or will change after the presentation has started. Or is there some unspoken assumption in the protocol that the client will first query the server to discover the OPTIONS available for control on a particular control URI? I've probably got more questions, but these will do for starters. cheers ian ------ >From owner-iesg@ISI.EDU Tue Jan 6 13:19:36 1998 Date: Tue, 6 Jan 1998 13:14:45 -0800 From: iana@ISI.EDU Posted-Date: Tue, 6 Jan 1998 13:14:45 -0800 To: iesg@ISI.EDU Subject: Re: Last Call: Real Time Streaming Protocol (RTSP) to Proposed Standard Cc: iana@ISI.EDU, rfc-ed@ISI.EDU Content-Length: 1212 X-Lines: 37 IESG: The IANA has reviewed the following Internet-Draft which is in Last Call: draft-ietf-mmusic-rtsp-06.txt, has the following comments/concerns over the publication of this document. 1) This document mentions/references two protocols which are not yet RFCs: SDP and TLS. Both appear to be "normative" references. SDP is currently an I-D. SDP is cited on pages 10, 85, and 86 of this RTSP I-D. TLS was sent back to the IESG by the RFC Editor via the IANA on 29 Dec 97 for various problems with the document. The RFC Editor is holding publication of TLS until the problems can be rectified. TLS is cited on page 9 of this RTSP I-D. 2) In section 3.2, "RTSP URL". Upon checking our records, this URL has not yet been registered with the IANA. 3) The port number assignment listed on page 16 of this I-D is correct with the IANA records. 4) The RTSP "Registering New Option Tags with IANA" on page 20 is noted and looks good. 5) On page 87, there is a notation of "RFC XXXX". What is this in reference to? (SDP?). We cannot find what this refers to either on that page, nor in the "References" section. THE END Joyce K. Reynolds IANA Liaison to the IESG ------------- Date: Tue, 06 Jan 1998 16:33:36 -0800 To: hgs@cs.columbia.edu, anup@netscape.com, Allyn.Romanow@eng.Sun.COM, mjh@isi.edu From: Rob Lanphier Subject: Couple of security recommendations Cc: ogud@tis.com I ran RTSP by Olafur Gudmundsson from Trusted Information Systems. Here's Olafur's security recommandations for the RTSP draft: * (section 16) Concentrated Denial Of Service Attack: it should be explicitly stated that it is acceptable to drop suspicious connections. * (section 3.4) Change "SHOULD" use large session ids to "MUST" I think these are both reasonable suggestions, but do these constitute a recycling of anything? I'm also going to dig back through the mail archives and see if the SHOULD/MUST thing was described before (I might have been the one that insisted on "SHOULD" :) ----------- To: robla@real.com From: Philipp Hoschka Subject: bug in RTSP spec Date: Fri, 19 Dec 1997 19:39:38 +0100 npt-range = ( npt-time "-" [ npt-time ] ) | ( "-" npt-time ) npt-time = "now" | npt-sec | npt-hhmmss npt-sec = 1*DIGIT [ "." *DIGIT ] npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ] npt-hh = 1*DIGIT ; any positive number npt-mm = 1*2DIGIT ; 0-59 npt-ss = 1*2DIGIT ; 0-59 the last two examples are illegal according to the BNF, since they don't contain a "-" Examples: npt=123.45-125 npt=12:05:35.3 npt=now ===================================================================== Pre draft06 issues (these *should* already be resolved) ------------------------------ Eric Fleischman Tue, 25 Feb 1997 15:09:34 -0800 I believe that the second paragraph of section 1.1 needs a bit of work in its first two sentences. Perhaps what you mean to say is: "RTSP-based communications occur within the context of a RTSP session. Specific RTSP sessions are identified by a session identifier (see Section X.X). RTSP sessions are unrelated to transport-layer sessions. They are also unrelated to transport-layer "connections"...." AR: I dont believe so. --------------- Eric Fleischman Tue, 25 Feb 1997 15:09:34 -0800 The bullet at the top of the Post Script page 5 is not entirely clear. Perhaps the "because of" sentence can be altered somewhat? AR: Not clear what this is, since things have changed. The only one that I think may be referring to is the issue of absolute URI in section 1.1, which seems pretty clear. --------------- Eric Fleischman Tue, 25 Feb 1997 15:09:34 -0800 The paragraph starting with "HTTP-friendly:" on page 7 refers to items about which I am ignorant. Ignorant people such as myself would appreciate reference pointers to what is meant by JEPI and PICS - especially because these acronyms have different meanings in other parts of the data comm world. AR: JEPI removed, reference to PICS added. --------------- Eric Fleischman Tue, 25 Feb 1997 15:09:34 -0800 In section 3.2 it may be desirable to include within the rtsp_URL the ability to refer to a specific frame (i.e., an optional "&&frame" reference). Frames may conceivably be used for reference tracks in URLs. Did you intend to omit such a possibility on purpose? --------------- Eric Fleischman Tue, 25 Feb 1997 15:09:34 -0800 First paragraph of section 3.4 refers to SMTPE time codes. Please provide a reference pointer to what you mean by "SMTPE time codes" so that we can all be sure we are referring to the same thing here. AR: need one ourselves. I will try and get from SMPTE/ANSI. --------------- Eric Fleischman Tue, 25 Feb 1997 15:09:34 -0800 The first sentence at the top of page 13 of the Post Script version refers to "the 'chunked' transfer coding". I don't understand what you mean by the word "chunked". Could you provide an example so that us naove individuals would understand this point? AR: Reference to H3.6 put in. --------------- Eric Fleischman Tue, 25 Feb 1997 15:09:34 -0800 In section 5 I believe that you have a typo: you say "extendion-method" when I suspect you want to say "extension-method. AR: This seems to be fixed. --------------- Eric Fleischman Tue, 25 Feb 1997 15:09:34 -0800 The references for section 6 are: Status-line - section 6.1 General-header - I didn't find what that referred to. Response-header - section 6.1.2 Entity-header - section 7.1 Message-body- I didn't find what that referred to AR: This seems to be fixed. --------------- Eric Fleischman Tue, 25 Feb 1997 15:09:34 -0800 Section 8.1 could perhaps do with a discussion of potential problems with pipelining within a connectionless-mode. --------------- Eric Fleischman Tue, 25 Feb 1997 15:09:34 -0800 The second to the last sentence within section 8.2 refers to a method header. What is a "method header" and if it is defined elsewhere in the document then I'd appreciate a pointer to that section. AR: Fixed. Should be message header rather than method header. --------------- Eric Fleischman Tue, 25 Feb 1997 15:09:34 -0800 In the first GET example in section 9.2, what is the 312 (e.g., is a port number or a sequence number or a timestamp or what?)? --------------- Eric Fleischman Tue, 25 Feb 1997 15:09:34 -0800 The second paragraph of section 9.4 currently implies that a PLAY containing a Range header following a PAUSE will have the Range Header ignored - that the playing will resume from where the pause left off without having an offset from that pause indicated by the range header. Is this what you intended? AR: I dont understand this. --------------- Eric Fleischman Tue, 25 Feb 1997 15:09:34 -0800 In section 9.4, readers may be interested in why a media server supporting playback must support the smpte format but only optionally support the clock format. AR: Changed to SHOULD by Henning. --------------- Eric Fleischman Tue, 25 Feb 1997 15:09:34 -0800 The Get parameter of section 9.8 reminds me of RTCP's functionality. Do you desire to address why a GET is needed if RTP/RTCP is being used to stream the data? --------------- Eric Fleischman Tue, 25 Feb 1997 15:09:34 -0800 The first sentence of section 9.13 implies that RTP data follows a "$". Is this really what you intended to say? AR: Fixed by Henning. --------------- Eric Fleischman Tue, 25 Feb 1997 15:09:34 -0800 What is the meaning of the "o" and "?" within the tables given in Section 11? AR: Fixed at some point by some one. --------------- Eric Fleischman At 06:27 PM 6/27/97 -0700, Eric Fleischman wrote: >Certain elements of the current RTSP spec confuse me. I suspect that >this is due to inexact wording in the spec which would be easy for you >to remidy. Here they are: > >1) Many of the examples currently do not have absolute URIs. Take for >example most of the method examples in section 9 (e.g., >"S->C: REDIRECT /fizzle/foo RTSP/1.0 732" in section 9.9 is lacking >"RTSP://". If absolute URIs are required, then all of the examples >should be correct. I checked in a change to this. I don't know that that has been updated in the generated text/postscript version on Henning's site though. >2) The example in section 9.2 in which the server "pushes" the DESCRIBE >method did not include a response by the client. Perhaps this is >intentional but if there is no response from the client, how will the >Server know that the method was received if the control session is >hosted via an unreliable transport? Thus, a response is necessary >otherwise the Server may feel compelled to repeatedly "push" the same >DESCRIBE to the client -- A Bad Thing to do. Thus, in addition to adding >the response from the client in the example, the text should explicitly >state that a response is always given for every request -- and a "push" >from the server is a request. Noted. We should probably take that out. We used to have the SESSION method, and in the rush to get the March draft out, we changed it to another varient of DESCRIBE. That issue hadn't been revisited since then, to the best of my knowledge. We are presuming, though, that the description will have some unique identifier, ala SDP, that will make it so that the client will know when it's just getting a repeat of the old stuff, and when there is a genuinely new version coming down. >3) Most of the Method examples use a session ID and a URI. Isn't this >redundant? Why not only require the Session ID UNLESS YOU ARE SPECIFYING >A SPECIFIC MEDIA STREAM ONLY WITHIN THAT SESSION? I'd appreciate an >explanation as to what you were/are thinking in this. The idea is that it may be possible, within a single RTSP/TCP connection to a server, to have multiple sessions, all maintaining state (timeline, play/paused, etc). Two of these sessions may in fact be referencing the same URL, so it's useful to know which actual instance of the URL to perform a given method on. >4) The State Machine is inconsistent in Appendix A for the SETUP method. >The server permits multiple SETUPs to be received but the client only >permits a single SETUP to be sent. Please make it consistent. Noted. >5) Shouldn' it be possible for the client to send multiple SETUPs to >handle the 1-1-N situation? We're working on that right now. I'll send you a private draft of what we have. Robla --------------- From examples.tex: "Even though the audio and video track are on two different servers, and may start at slightly different times and may drift with respect to each other, the client can synchronize the two using standard RTP methods, in particular the time scale contained in the RTCP sender reports." Is this true? This assumes that the two sources have very tightly synchronized NPTs. --------------- Robla 7/8 There are still open issues as to how the state machine in RTSP is supposed to handle starting over for authentication. Here's the most HTTP-like way of doing things: C->S DESCRIBE S->C 401 Unauthorized WWW-Authenticate: fjdksla; C->S DESCRIBE Authorize: lsdkjf;lasdjf S->C OK C->S SETUP Authorize: lsdkjf;lasdjf S->C OK Session: 1234 C->S PLAY Authorize: lsdkjf;lasdjf Session: 1234 Now, this would be rather silly if our server required the Authorize with every subsequent message, since we are maintaining a persistant TCP connection. The good news is that there really doesn't need to be a requirement of servers to insist on that Authorize. The bad news is that we may need to respect other server implementors' desire to require an Authorize. One solution to this is to require clients to handle the 401 Unauthorized error for any method. Another (less desirable) solution is for the client to *always* send the authorization with every request to a given URL, and that the server *always* expects Authorization: with every method. Regardless of how we skin this, I want to make sure that it's clear what happens with error messages. Section A.1 claims that all errors except 401 and 402 lead to the "Init" state. I'm not sure that I buy that (I think all error messages should leave state unchanged unless otherwise specified). Thoughts? ------ Robla 8/13 Need a section for requirements for underlying transport. ------- Anup 11/24 Need to fix examples, values in RTP-Info "seq" need to be 0-65535 ------- Mark/Robla 11/25 Mark wrote: >Page 11, S3.2 > Not an error, but did you actually register the protocol types >"rtsp", etc? ------- Mark/Robla 11/25 Mark wrote: >Page 12, examples of RTSP URL > The examples imply semantic intent behind the "file" naming, but the >(small text) sentence afterwards says this isn't so. That's sort of the point, although you'll notice that there are no file extensions in the name. We then follow up by saying "what you see above may imply file name semantics, but don't be fooled". We could present other examples that don't have such semantics, I suppose. I'd just as soon leave it the way it is for the time being. ------- Mark 11/25 >Page 13, S3.3, S3.4 and Page 15 S3.8 > It's not really obvious whether your allow control characters and >NUL (0x00) octets as valid ids. S3.3 says standard URI encoding, but >S3.4 only comments on LWS. It's not obvious to me if LWS includes >CRLF (OK, found this in the appendix now), and I'm pretty sure it >doesn't include NUL. ------- Mark/Robla 11/25 Mark wrote: >Page 20, S8 > "Entity" is not defined anywhere. I know it's in HTTP, but add it > to the glossary or something please! Actually, the problem is worse than it appears. We use "entity" in two different ways. One is the definition in the HTTP spec: entity The information transferred as the payload of a request or response. An entity consists of metainformation in the form of entity-header fields and content in the form of an entity-body, as described in section 7. The other is as sort of a pronoun for "client" or "server". I'm not sure how to fix this right now (other than the Webster's way of "1. .... 2. ....") ------- Mark/Robla 11/25 Mark wrote: >Page 28, S10.6 > It seems like PAUSE never times out. This seems bad. This is server implementation specific behavior, though it may be nice to have a parameter so that the client knows how the server would deal with that. This one seems more than a typo, though, so I don't think we should try to slip that in. ------- Mark/Robla 11/25 Mark wrote: >Page 33, S11.3.7 > Should the server return a response saying which which header field > is not valid? If so, which header does it use in the response? Err, uh, I dunno :) We really should have a new header. Bleh. Not fixed. ------- Mark 11/25 Mark wrote: >Page 34, S12 > First para of S12 says unknown fields are ignored. Third para says > sending a 456 error code is a MUST if the field content does not > apply. But the client can't assume it will get a 456 error code for > anything other than required header fields. This isn't actually > contradictory, but seems to come close to me. Jennifer Rexford Thu, 13 Aug 1998 Preroll: A relative time (in seconds or in frame slots) should do the trick. So, the proxy or the server could tell the client to start playout some Delta seconds or frame slots from now. Or, some Delta seconds (or frame slots) plus any extra jitter tolerance desired at the client. This would allow either a proxy or a server to precompute a start-up delay, to allow for smoothing (prefetching) or other policies, such as retransmission to recover from packet losses.