Subject: Re: [MMUSIC] material for RTSP spec clarification

From: Magnus Westerlund <[email-masked]>
Date: Thu, 26 Jun 2003 10:33:57 +0200

Hi Philippe,

See below:

[email-masked] wrote:
> magnus you wrote:
> 
> 
>>>3) Explicit RTSP redirection (bis) using REDIRECT
>>
>>[...big piece missing here]
>>
>>So scrape this case in my opinion.
>>
> 
> 
> 
> What would be the sentence then?
> 
> "Servers MUST NOT use REDIRECT after a DESCRIBE but must use
> one of the other redicrection mean, for example return a 3xx code"

We need to resolve how to handle outstanding reqests with REDIRECT first 
before determing this issue.

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]

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

---

From: [email-masked]
Date: Thu, 26 Jun 2003 10:16:43 +0200

regards,

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

                                                                                                                                           
                                                       To:   Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1                                     
                                                       cc:   [email-masked]                                                               
                                                       Subject:    Re: [MMUSIC] material for RTSP spec clarification                       
                                                                                                                                           
               Magnus Westerlund                       Classification:                                                                     
               <magnus.westerlund@ericsson.                                                                                                
               com>                                                                                                                        
                                                                                                                                           
               Sent by:                                                                                                                    
               [email-masked]                                                                                                       
                                                                                                                                           
               25/06/2003 20:29                                                                                                            

[email-masked] wrote:
> 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>

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 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>
>
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.

>    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 ;-)>

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.

>
>    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
>
>
> <section 11.9 in the new draft  is long and detailed but
> 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.

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

Best Regards

Magnus Westerlund