Re: [MMUSIC] RTSP draft changes from telecon

[Magnus Westerlund <magnus.westerlund@era.ericsson.se>]

Tom Marshall wrote:

> > > The answer to my question is implied: a 304 response to a SETUP does
> > >      
> not
>  
> > > guarantee that the resource description is unchanged.  Correct?
> > >
> > >      
> > I don't know actually. Lets start deciding what resource that a 
> > If-Modified-Since header actually relates to in a SETUP request. 
> > Comparing this with Last-Modified header which for a SETUP relates to 
> > the media stream. In that case it seems valid that the
> >    
> If-Modified-Since 
>  
> > header in a request relates to the media stream also. In that case a
> >    
> 304 
>  
> > would mean that the media stream which the URL in the request points
> >    
> at 
>  
> > has not be changed.
> >    
> My assumptions are that:
>
> 1. The resource description is independent from the resource content.
> This
>   follows from having a resource description be available via alternate
>   means (eg. an HTTP download).
>
> 2. The resource description may change while the content does not.  One
>   example would be fixing a typo in an i=, e=, or p= line of SDP.
>
> 3. The resource content may change while the description does not.  One
>   example would be re-encoding a media file with the same codec
> settings. 
>   Another example would be live content.
>  
Ok.

>  
> > Assuming that the media stream has not changed, how could a resource 
> > description in that case be different while the media is not
> >    
> different. 
> See above.
>
>  
> > If that is possible we should point out this fact and explicitly
> >    
> declare 
>  
> > that a 304 answer does not in fact guarantee the resource description
> >    
> is 
>  
> > still the same.
> >    
> Agreed.  I will state that the 304 response to a DESCRIBE or SETUP does
> not
> imply anything about the response to the other method.
>  
How do we solve the scenario when a SDP description is distributed with 
HTTP and the client would like to setup this session under the 
assumption that the resource description has not changed in relation to 
the media. Does etags work for this?

In that case I think the proposed clarification works fine.

> > I don't think this problem of overloading is that problematic. I
> >    
> simply 
>  
> > think that we need to clarify the behavior of reSETUP request that
> >    
> fails.
>
> It will be interesting to see how well this works.  There seems to be a
> non-trivial number of combinations of headers and response codes that
> can be
> used with a SETUP request/response.
>  
Yes, there are a couple of questions here. But my direct approach would 
be that a 200 response means that the requested changes has happened. A 
100 answer would mean not yet. A 3xx answer I assume is the same as a 
REDIRECT request for that session, with the possible exception for 304. 
A 4xx would mean that nothing has been changed due to some error in the 
request. A 5xx is usual a little dependent on what has actually 
happened. If the session is still useable at least the parameters shall 
not have been changed.

Which means that a server must basically verify that it can address all 
changes requested in the change before actually performing them.

However I guess that the above idea might not totally fly when one 
starts to look into all details.

> It is in section A.1: "If a request yields a status code of 3xx, the
> state
> becomes Init, and a status code of 4xx yields no change in state."
>
> This sentence makes it very, very tempting to code the state machine
> based
> solely on the first digit of the status code.  In fact, I think rfc2068
> (upon which a large part of rfc2326 is based) encourages this behavior. 
> Also note that the error in assuming that all 3xx codes are redirections
> is
> carried over from rfc2068.
>
> I don't know if any existing RTSP state machines behave based solely on
> the
> class of status code, but the concern should be noted.
>  
I think the notion of coding the state machine after the first digit is 
actually good one. However in this case it might be needed to either 
clarify the exception or actually move 304 to a new number space like 
6xx. What the general category would actually do is another question.

> I know that in our (RealNetworks) system, the session context is used
> for a DESCRIBE.  If you look at past and current versions of our software, you
> will see it passed as both an ETag (which is a Session in disguise) and
> an actual Session.  This is not to say that the context is needed in the
> strict sense, but it is used.  I expect (and hope to motivate) a move away from
> using session context in such a manner, but there is one example that
> has been in use for several years.
>  
Okay, that I guess that we might need to allow session header in 
DESCRIBE request to allow for compatibility. However depending on what 
motivations we can see write some text how it actually shall be used.

> > However the use of 302 for load balancing on DESCRIBE and SETUP
> >    
> request 
>  
> > looks very dangerous. Lets assume that there are two server that are 
> > both fairly well loaded, what prevents them from sending a requesting 
> > party back and forth between the server without allowing it to get its
> >    
>  
> > description or session?
> >    
> Nothing prevents this in either HTTP or RTSP.  Most clients will track
> the
> number of redirects received and complain if it is "too many".
>  
Okay, I guess that work and does not need fixing. However a note about 
this might be useful. 


--

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: magnus.westerlund@era.ericsson.se



_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic