Subject: RE: [MMUSIC] RTSP telecon Monday 16th of June 18.00 CET

From: [email-masked]
Date: Tue, 17 Jun 2003 17:19:35 +0300

Hi Philippe, all,
I have some comments on the redirection at DESCRIBE phase. My concern is on the explicit redirection, not the implicit redirection, on which I agree with you.

>    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). The
>    "Location" header MUST be used to point out the new server.
>    (magnus westerlung wrote: "This MUST level may not be totally
>    clear in draft-03 and should be reviewed").
> 

So, does this mean that a REDIRECT request sent by the server to a DESCRIBE request (before any DESCRIBE response, which may not even be sent by the server) would be invalid? The following scenario:

Client->Server1:
	DESCRIBE ....

Server1->Client
	REDIRECT .... (with Location header pointing to the Server2's location)

Server1 sends a REDIRECT request containing the Location header to the client, instead of sending the SDP description in a DESCRIBE response. Client simply disconnects from Server1, and connects to Server2, if it wishes to. I guess this is not an invalid scenario, right?

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

I think it would be better to add: "if the RTSP client is willing to have an RTSP session with the redirected server" to the beginning of this statement. The above statement sounds as if a DESCRIBE request is mandatory to be sent after a redirection, regardless of the client's will to start a new session. 

Best Regards,
Emre

Emre Baris Aksu
Nokia Mobile Phones

> -----Original Message-----
> From: ext [email-masked]
> [mailto:[email-masked]]
> Sent: 16 June, 2003 18:50
> To: Magnus Westerlund
> Cc: IETF MMUSIC WG
> Subject: Re: [MMUSIC] RTSP telecon Monday 16th of June 18.00 CET
> 
> 
> Magnus, all,
> 
> 
> here is the sumary/result after the reflector exchanges:
> 
> 
> *****************************
>    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). The
>    "Location" header MUST be used to point out the new server.
>    (magnus westerlung wrote: "This MUST level may not be totally
>    clear in draft-03 and should be reviewed").
> 
>    1.D) following which a minimal RTSP client implementation MUST
>    issue a DESCRIBE on the alternate server (i.e. start from
>    scratch) designated in the "Location" header.
> 
> *****************************
>    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)
> 
> OPEN ISSUE: the name of the feature tag, should it be 
> "implicit-redir" ?
> 
>    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.
> 
> OPEN ISSUE: 200 or 2XX is open, minor benefit in using xx!= 00
> 
>    2.C) The mean to indicate the new server is "Content-Base".
> 
>    2.D) The client MAY then directly SETUP to the alternate server.
> 
>    NB:The purpose is to save one round trip.
> 
> 
> **************************
> 
> regards,
> 
> 
> Philippe Gentric
> Software Architect
> Philips MP4Net
> [email-masked]
> http://www.platform4.philips.com
> 
> 
>                                                               
>                                                               
>                
>                                                               
>                                                               
>                
>                                                        To:   
> IETF MMUSIC WG <[email-masked]>                              
>                 
>                                                        cc:   
> (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS)                    
>                 
>                                                        
> Subject:    [MMUSIC] RTSP telecon Monday 16th of June 18.00 
> CET                     
>                                                               
>                                                               
>                
>                Magnus Westerlund                       
> Classification:                                               
>                       
>                <magnus.westerlund@ericsson.                   
>                                                               
>                
>                com>                                           
>                                                               
>                
>                                                               
>                                                               
>                
>                Sent by:                                       
>                                                               
>                
>                [email-masked]                          
>                                                               
>                
>                                                               
>                                                               
>                
>                13/06/2003 16:17                               
>                                                               
>                
>                                                               
>                                                               
>                
>                                                               
>                                                               
>                
> 
> 
> 
> 
> Hi,
> 
> Sorry that I am late. There is a teleconference scheduled for monday
> (16th of June) at 18.00 CET. Included is the contact 
> information and agenda.
> 
> Cheers
> 
> Magnus
> 
> 
> Conference Details:
> 
> Telephone nr: +46 8 71 99500
> Participant PIN: 21158
> Date   06/16/2003 (MM/DD/YYYY)
> Start Time   18:00 (HH:MM)  CET
> 
> Agenda:
> -------
> 1. Opening of meeting.
> 2. Administrative
> a. IETF Vienna
> b. Authoring and Specification
>     - Aravind co-author
>     - Working on the specification.
> 3. Since last meeting (28th of May).
> a. Bug 533691 &  513880
>      - Updated text received, include in specification?
> b. http://rtsp.org/bug556295 - Text received, include in 
> specification?
> c. Multiple SSRC in RTSP.
>      - Text received, include in specification?
> d. http://rtsp.org/bug507882 - RTP timestamp and pause
>      - Aravind to write up text
> e. http://rtsp.org/bug739845 - "a=range" is missing IANA registration
> and clear rules
>      - Magnus to write text and question to list.
> f. http://rtsp.org/bug742328 - How to handle PLAY request when at the
> end of a media clip
>      - Magnus to write text.
> g. http://rtsp.org/742348 - Usage of implicit REDIRECT.
>      - Philippe and Yves has written to the list. Resolve discussion.
> 
> 3. New Things
> 
> a. REDIRECT to automatically close session.
> 
> Problem description:
> With the clarification the result of the REDIRECT request without
> session header closes the RTSP message connection, does this mean that
> the session has automatically been closed? If Yes, should the same
> behaviour be used also when session header is present?
> 
> 5. Any other Issues
> 6. Next meeting - Proposal: IETF meeting?
> 7. End meeting
> 
> 
> --
> 
> 
> 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]
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic
> 
> 
> 
> 
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic
> 
_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: [email-masked]
Date: Wed, 18 Jun 2003 15:01:42 +0200

Tom,

I agree.

regards,

Philippe Gentric
Software Architect
Philips MP4Net

                                                                                                                                       
                                                   To:   Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1                                     
                                                   cc:   Magnus Westerlund <[email-masked]>                            
                                                    IETF MMUSIC WG <[email-masked]>                                                   
                                                   Subject:    Re: [MMUSIC] RTSP telecon Monday 16th of June 18.00 CET                 
               Tom Marshall                                                                                                            
               <[email-masked]>                Classification:                                                                     
                                                                                                                                       
               17/06/2003 16:20                                                                                                        

This all seems overly complex and inconsistent to me.  Why are people trying
so hard to insist that the SDP come from the same server as the media?  If
we simply require that the client honor the hostname in the complete stream
urls (whether from Content-Base or a=control) everything becomes very simple
and constistent.

If we require the client to make different assumptions based on whether the
SDP came from the current RTSP control connection or via another means, we
require a series of workarounds to make it work properly:

 - An inconsistent message with respect to urls.  We are requiring that
   clients explicitly ignore the hostname in certain situations.

 - Inconsistent behavior through proxies.  A proxy will always honor the
   hostname but clients are forbidden from doing so.

 - More complexity: another feature tag and 2xx response code to support.

If we simply require the client to honor the hostname in the stream urls,
all of the above issues go away.  The only changes are as follows:

 - The client MUST be prepared to examine the hostname and, if necessary,
   reconnect for the SETUP.  This seems a pretty simple thing to implement.

 - The typical non-redirecting server SHOULD take care to echo the hostname
   exactly as it appears in the client request in order to make the client's
   hostname comparison easy.  The server should already be doing this.

Remember, the notion that a DESCRIBE response not redirect the client was
only added in an attempt to reduce the complexity of RTSP.  If it is not
serving that purpose, it should be removed.

On Mon, Jun 16, 2003 at 05:50:26PM +0200, [email-masked] wrote:
> OPEN ISSUE: the name of the feature tag, should it be "implicit-redir" ?
>
>                                                        To:   IETF MMUSIC WG <[email-masked]>
>                                                        cc:   (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS)
>                                                        Subject:    [MMUSIC] RTSP telecon Monday 16th of June 18.00 CET
>
>                Magnus Westerlund                       Classification:
> (16th of June) at 18.00 CET. Included is the contact information and agenda.
>
> Cheers
>
> Magnus
>
>
> Conference Details:
>
> b. http://rtsp.org/bug556295 - Text received, include in specification?

--
Biology is the only science in which multiplication means the same thing as
division.
(See attached file: attl9e8w.dat)

---

From: [email-masked]
Date: Wed, 18 Jun 2003 14:59:58 +0200

emre,

sorry with the late reply.

I agree with what you wrote.

regards,

Philippe Gentric
Software Architect
Philips MP4Net

                                                                                                                                       
                                                   To:   Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1                                     
                                                   cc:   <[email-masked]>                                                             
                                                   Subject:    RE: [MMUSIC] RTSP telecon Monday 16th of June 18.00 CET                 
                                                                                                                                       
               [email-masked]                 Classification:                                                                     
                                                                                                                                       
               17/06/2003 16:19                                                                                                        

Hi Philippe, all,

Client->Server1:
             DESCRIBE ....

Server1->Client

Server1 sends a REDIRECT request containing the Location header to the client, instead of sending the SDP description in a DESCRIBE response. Client simply disconnects from Server1, and connects to Server2, if it wishes to. I guess this is not an invalid
scenario, right?

>    scratch) designated in the "Location" header.

I think it would be better to add: "if the RTSP client is willing to have an RTSP session with the redirected server" to the beginning of this statement. The above statement sounds as if a DESCRIBE request is mandatory to be sent after a redirection,
regardless of the client's will to start a new session.

Best Regards,
Emre

Emre Baris Aksu
Nokia Mobile Phones