Hi Josh, See comments below: Josh Perfetto wrote:
Yes, you are correct. The first SETUP can't be pipelined with any subsequent SETUP. Also a PLAY request can't be sent until all outstanding SETUP request has been responded to.Hello All, As I read RFC2326, in the typical DESCRIBE followed by multiple SETUPs, the server will first assign the RTSP session ID in response to the first SETUP. The player is supposed to include this session ID in all subsequent requests. However, this seems to preclude the possibility of pipelining a second SETUP request with the first one, as the session ID for the second SETUP wouldn't be known at the time it is sent. Is this correct?
I agree that it results in long setup delays. You are welcome to come in with proposals that would improve the setup phase. However remember that any changes needs to be backwards compatible towards a RFC 2326 client. If that can't be achieved, I think such a improvement must be done in the context of a protocol extension.If it is, I would think it is a significant shortcoming, as pipelining is essential when streaming over high-latency wireless networks. Is this something that could be looked at in 2326bis?
I can't remember that text, nor find it in the RFC. Please point out the section where it is written. It is of course possible to use something else to identify sessions. However today the only standardized solution is the session ID.
RFC2326 does say that the server doesn't need to generate session identifiers if it has another means of identifying requests, but the player wouldn't know this until it receives the first SETUP response.