Subject: [MMUSIC] RTSP redirection

From: [email-masked]
Date: Mon, 2 Jun 2003 15:57:40 +0200

dear MMUSICers,

following the post last week on RTSP redirection
there was a discussion during the last RTSP phone call

here are the results (please comment/correct )

********************************************************

1) The core RTSP spec needs a few clarifications about redirection
(that -in short- [redirection=failure])

1.A) There is a need for a piece of text explaining that in general the server providing
the RTSP streaming service (i.e. SETUP etc ...)  is assumed to also be the one
that provides the session description (i.e. DESCRIBE) [reasons: simplicity/logic,
easier to do interrop testing, backward compatibility]

1.B) Specifically a minimal RTSP client implementation does not need to expect
that the response to DESCRIBE would be used to point to another server
whatever mean would be used for that (i.e. content-location, absolute URL
is SDP etc) unless it is signaled *explicitely* as a redirection:

1.C) Specifically if a server wishes to redirect a client at DESCRIBE time
(e.g. for load balancing etc) it MUST issue a 3xx code (TBD) and the answer
MUST NOT contain any SDP (i.e. this is the single minimal interoperable RTSP
redirection behavior)

Open Issue: what is the most appropriate way to signal the alternate server ?
is it Content-Location ?

1.D) following which a minimal RTSP client implementation MUST issue
a DESCRIBE on the alternate server (i.e. start from scratch)

2) However a separately documented (and separately interop tested)
improvement would be to define "implicit RTSP redirection" i.e.
-in short- [redirection=success]

2.A) "implicit RTSP redirection" is an *optional* "optimization" which usage
involves a *feature tag*. Such advanced client would issue the DESCRIBE
with the corresponding feature tag (TBD) signaling that it is able to receive
an "implicit redirection" (servers MUST NOT use implicit RTSP
redirection if the feature tag was not present in the DESCRIBE request)

2.B) An "implicit redirection" is defined as a DESCRIBE response with a
2XX code (TBD) -because it contains a valid SDP-
and it also contains a mean to redirect the client  toward
another (alternate) server.

2.C) The exact mean to indicate redirection is TBD.
Content-location  has been proposed.

2.D) The client MAY then directly SETUP to the alternate server.

Note1:The purpose is to save one round trip.(RTSP suffers from being
slow to setup due to the large number of required round trips)

Note2: It was discussed in the conf call that there are other ways to do that
(e.g.  use round robin DNS load balanced HTTP to retreive the SDP etc)
....the rationale for doing it in RTSP is that the redirection can be made
really "smart" in the sense that we have then a RTSP client talking
to a RTSP "service" (service is because there are several "machines",
all with a RTSP external interface but that are some how coordinated)
...which may have additional terminal profiling etc ... This is especially
relevant in the 3GPP context where: (1)RTT are large (2) UAPROF
provides extensive terminal capabilities signaling

*************************************

Unless there are objections I will attempt to formulate the corresponding
required pieces of text ASAP.

*************************************

regards,

Philippe Gentric
Software Architect
Philips MP4Net
[email-masked]
http://www.platform4.philips.com

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

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 02 Jun 2003 16:21:27 +0200

Hi Phillipe,

Comments below.

> here are the results (please comment/correct )

This is not an open isssue. When one use REDIRECT or a 3rr response to 
redirect, the "Location" header MUST be used to point out the new 
server. This MUST level may not be totally clear in draft-03 and should 
be reviewed.

> another (alternate) server.
What would be the motivation behind using a differnet 2xx code than 200? 
  Please elaborate with pro and cons.

> Content-location  has been proposed.

The usage of Content-Base may actually be more appropriate as it has not 
any semantic meaning more than being the base for any relative URL. 
Content-Location has a semantic meaning that the content actually 
hides/(also present) behind the used URL and instead can be 
found/referenced using the URL present i Content-Location. Further input 
into the matter is desired.

> provides extensive terminal capabilities signaling

Best 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]

---

From: Tom Marshall <[email-masked]>
Date: Mon, 2 Jun 2003 09:16:26 -0700

> into the matter is desired.

I agree that Content-Base is the way to go.

I discussed this matter with Rob Lanphier and others last week.  The wording
in 2326 was designed to discourage redirection via the Content-Base header
out of a desire to reduce complexity (or at least not add more complexity). 

On the other hand, it seems to be more consistent to allow redirection via
the Content-Base header.  First, it is more consistent with the way SDP is
handled when retrieved via HTTP.  If the HTTP server sends a Content-Base
header, the host portion is expected to be honored, so why not with RTSP? 
If the SDP contains absolute control urls, why should the client connect to
different servers depending on how it got the SDP?  Second, it is more
consistent when a proxy is involved.  The client will receive the DESCRIBE
response with Content-Base header that points to a different server.  It
will then request a SETUP on the url resulting from the Content-Base header
and the control url.  The proxy will connect to the other server to send the
SETUP request.  Why should the client alone act any differently?

The Content-Base method requires minimal changes to the spec.  It would
mostly require some text that makes it clear the client MUST (or at the very
least SHOULD) honor the host portion in the resulting stream url(s).  And a
couple of examples would be nice, of course.

-- 
Another war ... must it always be so?  How many comrades have we lost
in this way? ...  Obedience.  Duty.  Death, and more death ...
        -- Romulan Commander, "Balance of Terror", stardate 1709.2