Subject: Re: [MMUSIC] RTSP: Improved pipelining to speed up session establishment

From: Magnus Westerlund <[email-masked]>
Date: Mon, 16 Apr 2007 17:44:13 +0200

Chris Steck skrev:
> Is there any reason MMUSIC can't define the pipelining mechanism so it can
> be backported to work with RTSP 1.0 as well?  
> 
> We would like to leverage pipelining in 3GPP Rel 7 PSSe work, but are
> reluctant to have a dependency on RTSP 2.0.  It would be great if this
> proposal could account for this backport so that there is no need to extract
> pipelining from RTSP 2.0 to define a superset of 1.0 in SA4, where we
> reference the pipelining section of 2.0, as we all know how those things
> tend to fall out of sync easily.
> 

Hi Chris,

The reason we avoid doing anything with RTSP 1.0 is due to that the 
protocol and what points of extensibility that exist isn't well defined. 
If you actually look on what is used in RTSP 1.0 that is far from the 
required functionality from the specification. Secondly it only works 
because people have spent weeks in different interoperability events 
fixing their implementations to handle different variations to different 
servers or clients.

Trying to do specification work from that has been impossible. That is 
why we quite sometime ago decided to go for a new version that we could 
specify such that we can build extension on it.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 16 Apr 2007 18:01:42 +0200

[email-masked] skrev:
> Hi David,
> 
> The problems I see with the other 3 proposals:
> 
> 1) Magnus's proposal: if one of the SETUP fails, one of the streams
> might already be playing out and a PAUSE, SETUP, PLAY will cause the
> playout to start from a position other than the requested one. The
> server will also need to seek again to locate a RAP.

Yes, but as this only should happen in error cases I don't see the 
problem. And in most common cases we are talking about seeking to the 
beginning of the stream. How often are you actually seeing that SETUP 
fails? There are already mechanisms in RTSP that is built around being 
fast when things go right and slower when there are errors.

[snip]

> 
> Regarding my proposal: the embedded requests are identical to normal
> requests. The transaction request is simply an envelope that is used as
> delimiter. It is also used to signal options about the transaction. E.g.
> if any SETUP request fails, PLAY should not be performed (or should fail
> as well).
> 

Imed, I still doesn't see how embedding the request in an envelope helps 
anyone. You would get the same responses from the individual messages. 
The roleback would probably require more. And the only thing you have 
saved is the amount of resources required to perform the playback during 
the time. And if that is really you desire I have a solution on how to 
make the PLAY conditional on earlier request being successful. In that 
case I would introduce a header that indicate which sequence number that 
needs to have completed successfully before performing the request.

However I removed it because it requires more state in the server, would 
very seldom be exercised, and that there existed good ways of cleaning 
up if something went wrong.

I would also like to point out that the minute we start using ICE style 
NAT traversal we are likely to end up doing pipelined SETUP and then 
wait with PLAY until we have confirmed that the connectivity checks have 
completed.

Cheers

Magnus Westerlund