Subject: [MMUSIC] material for RTSP spec clarification

From: [email-masked]
Date: Wed, 25 Jun 2003 18:38:04 +0200

A RTSP server MAY redirect a client in reply to DESCRIBE...

sure, but there are several ways to do that ...
after the last discussions on the reflector and during the
conference call,  I would like to try to re-sumarize
what I hope is a correct understanding of the consensus ;-)

 NB: this is intended as possible material for a
   clarification in the next release of the RTSP specification

1) SDP redirection

   The server MAY reply 200 with absolute URLs in the SDP response
   where another server is indicated by these absolute URLs.

   A client MUST be ready to examine the SDP for absolute URLs. The
   client (if it wants to...) SHOULD connect to the other server and
   MAY start the session with SETUP since the information in the SDP
   is deemed valid.

   The absolute URLs -in case there are several of them e.g. audio
   and video- MUST point to the same streaming server. <this last sentence
has  been recently proposed by Magnus>

      <This is a clarification that DESCRIBE is a commodity in RTSP for
   retrieving the session information in the sense that the same SDP
   may be obtained in several alternative ways. Specifically this
   "redirection" is actually similar to what happens when a
   streaming session is initiated by retrieving a SDP from a web
   (HTTP) server (or via Email etc) i.e. it would not make sense to
   exclude the case where that same SDP would be served by a RTSP
   server under the pretext that that server is not the final
   streaming server.>

   Example:

     C->M: DESCRIBE rtsp://foo/twister RTSP/1.0
           CSeq: 1

     M->C: RTSP/1.0 200 OK
           CSeq: 1
           Content-Type: application/sdp
           Content-Length: 164

           v=0
           o=- 2890844256 2890842807 IN IP4 172.16.2.93
           s=RTSP Session
           i=An Example of RTSP Session Usage
           a=control:rtsp://123.34.322.67:554/foo/twister
           t=0 0
           m=audio 0 RTP/AVP 0
           a=control:rtsp://123.34.322.67:554/foo/twister/audio
           m=video 0 RTP/AVP 26
           a=control:rtsp://123.34.322.67:554/foo/twister/video

2) Explicit RTSP redirection

   The server MAY reply 3xx (possible status values are described in
   RFC2616 section 10.3).

   This response MUST NOT contain any SDP. <this sentence is
   "really" missing>

   The alternate server MUST be indicated in the Location header.
   The client (if it wants to...) SHOULD connect to the other server
   and restart the session with DESCRIBE.

   For load balancing and other temporary redirection 307 SHOULD be
   used. <this line is a proposal, the idea is to guide implementors
   since the text in RFC2616 about the various 3xx status is pretty
   complicated (and very HTTP focused ;-)>

   Example:

     C->M: DESCRIBE rtsp://foo/twister RTSP/1.0
           CSeq: 1

     M->C: RTSP/1.0 307 Temporary Redirect
           CSeq: 1
           Location: rtsp://123.34.322.67:554/foo/twister

3) Explicit RTSP redirection (bis) using REDIRECT

<section 11.9 in the new draft  is long and detailed but
does not address explicitely the case>

   The server MAY reply by sending a REDIRECT instead of answering
   the DESCRIBE.

   The alternate server MUST be indicated in the Location header.
   The client (if it wants to...) SHOULD connect to the other server
   and start the session with DESCRIBE.

   Example:

     C->M: DESCRIBE rtsp://foo/twister RTSP/1.0
           CSeq: 1

     M->C: REDIRECT rtsp://foo/twister RTSP/1.0
           CSeq: 1
           Location: rtsp://123.34.322.67:554/foo/twister

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: Tom Marshall <[email-masked]>
Date: Wed, 25 Jun 2003 10:58:27 -0700

> has  been recently proposed by Magnus>

This is good.  But I would prefer SHOULD instead of MUST here.

It would also be good to mention and provide an example for redirection via
the Content-Base header.  An example for a load-balanced virtual server
foo.example.com with actual servers foo-1 .. foo-N might look like this
(note I did not recalculate Content-Length):

     C->M: DESCRIBE rtsp://foo.example.com/twister RTSP/1.0
           CSeq: 1

     M->C: RTSP/1.0 200 OK
           CSeq: 1
           Content-Base: rtsp://foo-3.example.com/twister/
           Content-Type: application/sdp
           Content-Length: 164

           v=0
           a=control:*
           t=0 0
           m=audio 0 RTP/AVP 0
           a=control:audio
           m=video 0 RTP/AVP 26
           a=control:video

And finally, a note that the client logic is the same in all of these cases
might be good.  This would clarify that each example is not a special case,
but rather that the client need only follow the rules set forth in C.1.1 to
compute the proper stream urls.

-- 
Old timer, n.:
        One who remembers when charity was a virtue and not an organization.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 25 Jun 2003 20:29:35 +0200

> has  been recently proposed by Magnus>

I think a MUST is to strong, a RECOMMENDED and then add a note in the 
minimal implementation for client that they do not need to handle 
redirections that result in that sessions must be setup as several 
non-aggregated sessions to different servers. This will in fact have the 
effect that no one will use unless they know they have support for it, 
based on client or application context.

>    This response MUST NOT contain any SDP. <this sentence is
I agree that we should clarify this. In the spec this will be formulated 
as a 3rr response SHALL NOT contain any body. I need to think a bit more 
about this and if no body at all is the right decision.

>    complicated (and very HTTP focused ;-)>

I don't think we need 307, when 302 is written as intended for this.

The current text for 302 from version 03 of the draft:

12.3.3 302 Found

    The requested resource reside temporarily at the URI given by the
    Location header. The Location header MUST be included. Is intended to
    be used for many types of temporary redirects, e.g.  load balancing.
    It is RECOMMENDED that one set the reason phrase to something more
    meaningful than "Found" in these cases.

> does not address explicitely the case>

I don't think this is how this should be solved. If a client has an 
outstanding request with the server, it should simply respond to the 
request. If one is going to shutdown a server, or other drastic things 
that forces a server to use REDIRECT, then he has probably some time to 
answer any request with REDIRECT codes. Then for the already established 
sessions it needs to send REDIRECT.

>            Location: rtsp://123.34.322.67:554/foo/twister

So scrape this case in my opinion.

Best Regards

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]