Subject: [MMUSIC] RTSP REDIRECT (1) , when can it be received ??

From: [email-masked]
Date: Tue, 14 May 2002 17:55:20 +0200

Hi,

I have problem understanding *when* a user agent can receive a REDIRECT
request.

When reading RFC 2326, I understood receipt/transmission of a REDIRECT
request could happen at virtually anytime. As such, the following scenario
could happen:

C -> S: DESCRIBE rtsp://server.com/movies/BeautifulMind.mp4
CSeq: 1400
Accept: application/sdp

S -> C: REDIRECT rtsp://server.com/movies/BeautifulMind.mp4
CSeq: 1401
Location: rtsp://server.com/mpaa/pg13/BeautifulMind.mp4

S -> C: RTSP/1.0 404 Not Found
CSeq: 1400
Connection: Close

However one can also notify redirection in such a context by using a 3xx
response, right ?
C -> S: DESCRIBE rtsp://server.com/movies/BeautifulMind.mp4
CSeq: 1400
Accept: application/sdp

S -> C: RTSP/1.0 301 Moved
CSeq: 1400
Location: rtsp://server.com/mpaa/pg13/BeautifulMind.mp4
Connection: Close

However when reading the RTSP state machine spec (version 0.5) contributed
by Mr Westerlund, it seems like a REDIRECT can only happen (or at least
should be used) when a presentation is being played or is paused (at least
all streams are SETUP). Therefore using the state machine REDIRECT
semantics, scenarii like the first one exposed above are erroneous.

So should REDIRECT be sent/received when an RTSP session is being
played/paused only, or can it be sent/received any time ??

Thanks for your time and response,

Olivier

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

---

From: Rob Lanphier <[email-masked]>
Date: Tue, 14 May 2002 10:52:07 -0700 (Pacific Daylight Time)

The user agent should be prepared to receive a redirect at any time.
We'll need to fix up the state machine to reflect that.

Thanks for pointing that out.

Rob
----
Rob Lanphier, Program Manager -- Interoperability, RealNetworks
http://realnetworks.com http://rtsp.org http://interop.real.com

---

From: Jonathan Sergent <[email-masked]>
Date: Tue, 14 May 2002 10:18:32 -0700

> played/paused only, or can it be sent/received any time ??

I don't think you can send REDIRECT without a session header referring
to the session you want to redirect.  After all, a client can
participate in more than one session on the same TCP connection (let
alone UDP).  So the model you present above should cause the client to
respond to the server's REDIRECT request with an error.

And regardless, the client still expects a response from its DESCRIBE
request.  The REDIRECT method is for telling a client to
*asynchronously* switch to another URL.  If the client has a DESCRIBE
request pending, there is no need to send a REDIRECT request, since you
can immediately redirect the client to the new URL with a 302
response.

I don't think it's legal to send a REDIRECT request and then a response
to a pending request in any circumstance.  Notice that the sequence
numbers coming back from the server go backwards; this is not allowed;
messages must be in order.  So, ignoring the session ID problem, the
server could not send the REDIRECT until it had finished processing and
responding to the pending DESCRIBE.

The 302 response tells the client to resend the request but with the new
URL (and possibly to a new server).

It is less than clear how REDIRECT interacts with aggregate control, in
particular what to do if the URL in the REDIRECT request is for one
stream in an aggregate presentation.  This would seem to be impossible
if the redirected-to Location is on another server, so that case would
have to be an error.  The only conclusion I can come to is that it is
under-specified right now.  The example in the RFC uses non-aggregate.

I suspect the best thing would be to only use REDIRECT requests that
have the same URL in them than was used in the initial PLAY request
for the same session (i.e. that redirect the entire presentation).

--jss.