Subject: [MMUSIC] RTSP REDIRECT (3), continuation after TEARDOWN

From: [email-masked]
Date: Tue, 14 May 2002 19:18:49 +0200

Hi :-),

RFC 2326 specifies that upon receipt of a REDIRECT request, "if the client
wants to continue to [send or] receive media for this URI, the client MUST
issue a TEARDOWN request for the current session and a SETUP for the new
session at the designated host".

My question here is about context persistence. Indeed, in many cases, the
aborted session (prior to REDIRECT) was set up thanks to configuration
information obtained during media init (e.g. DESCRIBE or out of band ways).
Among this info were the various control URIs to submit along with SETUPs.

In order for SETUPs to be re-run at once, we need to be sure that control
URIs have not changed between will be unchanged since the original
(pre-REDIRECT) session. I did not see this stated throughtout RFC 2326, so
do we have such a guarantee of control URIs persistence ?? IMHO, such
persistence is cannot be guaranteed because it depends on the way programs
are configured when generating content files, yet I'd like to be sure. I've
included a problematic scenario to illustrate this in the post scriptum.

Thanks for your feedback,

Olivier

P.S.: sample scenario

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

S -> C: RTSP/1.0 200 OK
CSeq: 110
//SDP description follows

In the SDP description, we have two media descriptions (audio & video). The
aggregate control URI:
   - rtsp://server.com/movies/NG/
   - audio stream control URI: english.au
   - video stream control URI:  video.mp4

C -> S: SETUP rtsp://server.com/movies/NG/english.au
CSeq: 111

S -> C: RTSP/1.0 200 OK
CSeq: 111
Session: XXXXXX

C -> S: SETUP rtsp://server.com/movies/NG/video.mp4
CSeq: 112
Session: XXXXXX

S -> C: RTSP/1.0 200 OK
CSeq: 112
Session: XXXXXX

C -> S: PLAY rtsp://server.com/movies/NG/
CSeq: 113
Session: XXXXXX
Range: npt:0.0-

S -> C: RTSP/1.0 200 OK
CSeq: 113
Session: XXXXXX

...Playing for some time
...PG&E on strike (example) -> shutdown

S -> C: REDIRECT rtsp://server.com/movies/NG/
CSeq: 114
Location: rtsp://backup.server.com/movies/NakedGun.mp4

At this point:
- do we have to assume that the new aggregate control URI will be
rtsp://backup.server.com/movies/NG/ (by ways of some automatic derivation
from the prior aggregate control URI),and the media streams control URI are
still "english.au" and "video.mp4" ? If so, this could cause the
redirection to fail if the people in charge of producing content files did
not think the way we did.

- or do we have to re-run the media init phase using DESCRIBE, SETUP things
accordingly, and then do a "resume" PLAY (beginning where we left it in the
previous RTSP session)

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

---

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

> accordingly, and then do a "resume" PLAY (beginning where we left it in the

The spec doesn't say, but I think the only reasonable answer is the
second case, where you have to do DESCRIBE (or look at a cached copy of
the DESCRIBE results from the new URL) to know what to expect.  With
some payload types there are codec setup parameters embedded in the
SDP, and it would be undesirable to restrict redirections to media with
the same set of payload types and codec setup parameters (and a=range
line, and ...)

I think we need to look into clarifying REDIRECT in the new RTSP RFC.

I suspect the example for REDIRECT in the RFC was a non-aggregate-control
example, in which case there is only one SETUP to be done, and at the same
URL that is used for DESCRIBE.

--jss.