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

From: [email-masked]
Date: Mon, 16 Jun 2003 17:50:26 +0200

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 17 Jun 2003 16:50:21 +0200

Hi Philippe and Tom,

I agree with Tom here. It would be much simpler to just specify that any 
received SDP can point to another host using the a=control URLs. If you 
do DESCRIBE on the aggregated control URL you should receive the same 
SDP description.

The only implementation simplifying restriction I would like to 
introduce is that all media streams SHOULD be served by the same server.

Any counter reasons?

Best Regards

Magnus

Tom Marshall wrote:
> 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.
> 
> -- 

Magnus Westerlund

---

From: Tom Marshall <[email-masked]>
Date: Tue, 17 Jun 2003 07:20:12 -0700

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:

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

-- 
Biology is the only science in which multiplication means the same thing as
division.

---

From: "Ivan R. Judson" <[email-masked]>
Date: Tue, 17 Jun 2003 19:36:24 -0500

> introduce is that all media streams SHOULD be served by the 

The only thing that springs to mind is the scalability constraint. If I
understand this correctly, correctly synchronized playback of a session with
a large number of streams becomes difficult. It's a moderately academic
scaling point, but as we start recording and playing back 20-40 streams
simultaneously on a regular basis (we've done it irregularly for years) it
might become an issue. I haven't been following the details of this
particular conversation, but this point did pique my interest -- what's the
cost savings of requiring all streams from the same server?

--Ivan