[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MMUSIC] RTSP draft changes from telecon

Hi Tom,

Tom Marshall wrote:
If the media content changes it should be published as a new resources
with an new URI.

I agree that it is desirable to have a new URI for a changed resource,
but I
don't think it should not be a MUST. I don't think the spec should
dictate
content policy to this degree.

No, I agree but we should be clear with what a certain answer means so. That way we can avoid ambiguities if different content policies are used.


2. Same issue with SETUP, but in reverse. Does 304 necessarily imply
that the resource description is identical?

What is your suggestion for the semantics of receiving a 304 to a

SETUP
request? I have earlier asked what happens when one do SETUP to change


parameters and it does not work correctly, see bug 513737:


https://sourceforge.net/tracker/?group_id=23194&atid=377744&func=detail&;
aid=513737

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.

Assuming that the media stream has not changed, how could a resource description in that case be different while the media is not different. 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.


I admit that I have not thought about the issue in 513737 before. It
seems
to come from overloading the semantics of SETUP.

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.


3. The RTSP state machine mandates that a 3xx response to a request
changes
the state to Init. This is fairly logical for the other 3xx codes,

as

they
are used for redirection. Should 304 also follow this rule? Suppose
that a
client has a Session and is PLAYing a resource. The client then

issues

a
DESCRIBE on that same resource, specifying the existing Session and

an

If-Modified-Since header. The server returns a 304 response. What
happens
to the Session? Should it be considered torn down? Should the

server

stop
sending data packets?



I think 304 needs to be excluded from this behavior. Is it not in fact


that a 304 response is the result of that the session state has not

been
changed?

Yes, it would be logical to exclude 304 from the state change in this
case. But wouldn't this break compatibility with 2326? Are there existing
RTSP
implementations that would reset the state to Init in this case?

Looking at the RFC2326 state machine nothing of this is explicitly declared. Therefore I don't think there is a problem of fixing this in the new state machine.


Further, suppose that the same scenario as (3) above plays out but

the

server returns 302 instead. What happens to the session, and should

the

server stop sending data packets?



The scenario you think of is a DESCRIBE request with session header relating to a active session. That DESCRIBE request results in a 302 response. However as DESCRIBE does not effect the session state (see table 6).

I think there is a conflict in the state change rules. Perhaps the
rules
for state changes need to be re-examined, or at least clarified?

Yes, this needs consideration and clarification. I haven't thought before of the case that one actually desires to do a new describe of the session description of the session currently set up. This case might imply that a server needs to know that this request is in the context of the given session so it does not move a requesting party around due to load balancing, etc. In all other cases it looks like the DESCRIBE can be stateless and simply be a tool for requesting session descriptions related to a certain media resource. Have you any clarifying thoughts on when a session context is needed for a DESCRIBE?

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?


Also currently session header is not applicable for DESCRIBE requests (See table 4).

This is true for draft-02, but 2326 section 12 says:

Header type support methods
...
Session Rr req. all but SETUP, OPTIONS

This is not strictly correct, as the Session header is indeed meaningful
in
SETUP, but it does allow Session to be used in DESCRIBE.


Yes, as RFC 2326 is obvious in error and can easily be showed to contradict itself, this is not an argument. The valid argument for session header in request is simply: Are there reasons when the content of a DESCRIBE request is dependent on a already established session? If yes, session header shall be allowed in DESCRIBE, else not.

Best Regards

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