Subject: Re: REDIRECT in RTSP

From: "Ram Kordale" <[email-masked]>
Date: Thu, 3 Sep 1998 17:39:45 -0700

Actually, the spec allows the server to include the following in its
response to a client's SETUP request:
 1) a "redirection" status code that redirects to a new RTSP server
 2) specify a different media server (source port, RTP related info)

Thus, it appears that the following is possible:
  1) the front end server can forward the client's request to the appropriate
        RTSP/media server.
  2) The second server processes the request, sets up the relevant data
     connections, and returns the response (to the first server).
  3) The first server can return relevant "transport info" it got from the
     second server along with the "redirect" status code.

However, to make this work, the second server should be able to relate the new
session that the client sets up with the data connections it has already
opened.
How can this be done?

Passing the session id on second server to the client which could then use it
seems like one way. Any thoughts on this?

Thanks.
Ram

-- 
Ram Kordale

---

From: Clinton Wong <[email-masked]>
Date: Thu, 3 Sep 1998 18:58:54 -0700 (PDT)

> seems like one way. Any thoughts on this?

There are a few possible ways to do what you describe, depending
on what you want to achieve.

For the purposes of load balancing, the server can issue a 301 or 302
response (Moved permanently, Moved temporarily).  The client
would disconnect and then go to the server specified in the 
Location header.

C->S:
SETUP rtsp://media.apple.com/imac_ad.mov RTSP/1.0
CSeq: 1
Transport: RTP/AVP;unicast;client_port=6660-6661
S->C:
RTSP/1.0 302 Moved Temporarily
CSeq: 1
Location: rtsp://mirror5.apple.com/imac_ad.mov RTSP/1.0

The client would disconnect from media.apple.com and then do
a SETUP request on mirror5.apple.com.

If you want to do a proxy server, the client would do a setup
on the proxy server, the proxy server would do a setup
on the destination server, and when RTP packets flow
from the destination server to the proxy (after a PLAY),
the proxy would forward a copy of the packet to the client.

Or it is possible to have one RTSP server that controls
many RTP servers.  The RTSP server would pick one of the
RTP servers and put the RTP server's IP address in
the Transport header.  The RTSP server would have
to keep track of what RTP servers are assigned to what
Session ID's, though.

Clinton

---

From: Anup Rao <[email-masked]>
Date: Thu, 03 Sep 1998 19:41:11 -0700

> seems like one way. Any thoughts on this?

The expected model is that the client goes to server1, gets redirected
to server2 via a 3xx response(and location info). It then makes the same
request to server2, which is treated as a new session. 

Any reason why the above model will not work for you ?

I dont recall quite the same thing as you are mentioning being
discussed, but it is possible that variants were. For eg.,  in your
scenario, you could make  server1  a Proxy, and have the client always
talk to it(rather than the first request going to server1 and all other
going to server2), while data always comes from server2.

-Anup.

---

From: Stephen Casner <[email-masked]>
Date: Thu, 3 Sep 1998 22:55:16 -0700 (PDT)

> request to server2, which is treated as a new session. 

This procedure is what we implemented at Precept (now Cisco), though
the exchange happens at the DESCRIBE stage rather than SETUP.

There was one consideration that we ran across that I think is not
discussed anywhere: we've returned a cookie from the initial server to
be included in the redirected request to the second server so the
latter can verify that the request did go through the initial server.
The method for doing this is not standardized.
							-- Steve

---

From: "Ram Kordale" <[email-masked]>
Date: Fri, 4 Sep 1998 08:56:30 -0700

On Sep 3, 10:55pm, Stephen Casner wrote:
> Subject: Re: REDIRECT in RTSP
>-- End of excerpt from Stephen Casner

Exactly. Something like this is what we are looking for though the server
should be able to return the cookie while responding to SETUP as well.

The proxy model tends to make the front end server "a bottleneck".

The redirection model expected by the spec has the following problems:
1) Extra round trip.
2) More importantly, the client's request can potentially be redirected a
number of times. For example, when the client's request arrives at the server
to which it was redirected:
  a) may be loaded when the client's request arrives.
  b) the media asset on the second server is staged to tertiary storage.
This may require the client to be redirected again.
3) Possible duplication of work such as re-authenticating etc.

Thus, spanning the notion of session across the connection to the two servers
can help. Again, one could do this outside RTSP but it seems worthwhile to get
this into the spec.

Thanks.
Ram

-- 
Ram Kordale

---

From: Jeffrey Lo <[email-masked]>
Date: Fri, 4 Sep 1998 10:49:19 -0700 (PDT)

Hi,
I have a related question. Let's say in the following scenario:

RTSP clients always talk to server A which then replies with REDIRECT to
the respective media servers (Anup's scenario). For load balancing and
scalability of a popular title, if we have an architecture where different
portion of a long presentation is located on different media servers, is
there anyway to carry this information within a single REDIRECT response?
Server A now needs to inform client not only location of the media
servers, but also the portion of the presentation each media server
stores.

Please help.

Jeffrey Lo

---

From: Anup Rao <[email-masked]>
Date: Tue, 08 Sep 1998 16:39:07 -0700

> should be able to return the cookie while responding to SETUP as well.

There is a difference between what you are suggesting and the above.
What Steve has described does not imply spanning a session between two
servers. Any resources are setup only when server2 receives a request
from the client, and not server1.

> The proxy model tends to make the front end server "a bottleneck".

This point is understood, but does not seem to me to be a pivotal one.
If the proxy has to see(ie redirect) the first request anyway, doing an
average of 2-3 more during the life of the playback does not seem a
whole lot. See more arguments below. 

> The redirection model expected by the spec has the following problems:
Agreed. For the first request only.

> This may require the client to be redirected again.

I dont understand how spanning the session across 2  servers solves this
problem. If the client goes to server1, who then makes the request to
server2 in your model, what prevents server2 from being redirected.

> can help. Again, one could do this outside RTSP but it seems worthwhile to get

I'm arguing that this may not be a good idea. Reasons :

a) Most importantly, it will break current implementations since these
expect nothing to have been setup on receiving a 3xx response. (If no
implementors object, then it is a different issue...)
b) The benefit seems to be  one round-trip only for the first request.
If a) is true, then it does not seem worth it.

-Anup.

---

From: Anup Rao <[email-masked]>
Date: Tue, 08 Sep 1998 16:49:51 -0700

> servers, but also the portion of the presentation each media server

Jeffrey,

I dont believe what you have asked for is currently possible. The
Location header in 3xx(redirect) responses and REDIRECT requests comes
from HTTP, and it is my understanding that there can be only one of
them.

The options that I see are :

a) Enhance the RTSP spec to allow multiple Location-Range header pairs.
b) The client goes to server1 and plays section1 of the clip. At some
point, server1 then sends a REDIRECT request to the client, sending it
to server2 after section1 and so on.
c) Use another session description type in response to DESCRIBE, that
can convey the fact the the clip is available from N different servers.
I dont think SDP can do this. One option is
SMIL(http://www.w3.org/AudioVideo/)

-Anup.

---

From: Jeffrey Lo <[email-masked]>
Date: Tue, 8 Sep 1998 21:29:01 -0700 (PDT)

Hi Anup,

> from HTTP, and it is my understanding that there can be only one of

I agree. This is what I think.

> a) Enhance the RTSP spec to allow multiple Location-Range header pairs.
Unlike HTTP, RTSP manages resources that span over long duration and has
high likelihood for a resource to be distributed over multiple locations.
Restricting to a single Location header similar to HTTP would limit the
capability of RTSP. Having Location-Range header pairs, on the other hand, 
would be a good solution and it does not interfere with current
implementations.

> to server2 after section1 and so on.

This is technically feasible. But it would be tedious from the content
management point of view. Updating a single title in this case would
demand updating the database on each media server. Also, media servers
would be loaded the unnecessary overhead of timer management for each
session requesting distributed resource.

> SMIL(http://www.w3.org/AudioVideo/)

This is also a solution. But a solution base on this approach alone may
restrict the type of session description format usable by a distributed
resource. I don't see any contradictions in having a) and c)
implemented simultaneously.

Hence the possibility of multiple Location-Range header pairs would be a
nice feature to have within RTSP.