Subject: [MMUSIC] Pipelining RTSP SETUP

From: "Josh Perfetto" <[email-masked]>
Date: Mon, 20 Jan 2003 14:45:55 -0800

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?

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?

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.

-Josh

--
Josh Perfetto
Director of Architecture
Vidiator Technologies
[email-masked]
_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 22 Jan 2003 09:01:51 +0100

Hi Josh,

See comments below:

>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 sessi…
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.

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

>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 res…
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.

Regards

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]