Re: [MMUSIC] RTSP multicast question.

[Magnus Westerlund <magnus.westerlund at ericsson.com>]

Yedidia Amit skrev:
> Magnus,
>
> I agree with the ambiguity that SETUP method should cause in multicast scenarios.
> This is exactly the case described in RFC2326 Appendix A (section A.1 and A.2) come to resolve:
>
> About client state (A.1 pg. 76):
> "If no explicit SETUP is required for the object (for example, it is available via a multicast group),
> state begins at Ready. In this case, there are only two states, Ready and Playing. The client also
> changes state from Playing/Recording to Ready when the end of the requested range is reached."  
>
> About server state (A.2 pg. 78):
> "If no explicit SETUP is required for the object, the state starts at
> Ready and there are only two states, Ready and Playing.
>
> Which means that session may be created by the server witout explicit SETUP command, (maybe by some internal configuration).
>
> Do you agree?

I would say that this is just an example of one more case of RFC 2326 
brokenness. Yes, re-reading the text that exist around session IDs 
indicate that the RTSP session could be generated in other ways than 
using SETUP. However, how this is accomplished or how one actually can 
use that state isn't specified. There is one hint that dynamic RTSP URIs 
could be used to indicate a specific session. But, nothing is specified 
that makes this implementable. Open issues that I directly see are:

- How to go from a URI to a session ID header?

- In which methods that one can use this and how the operations affect 
the state machine?

- What happens to the session identified when one does Teardown?

I would also like to point out that using the same session ID for 
multiple clients are not allowed according to this text in section 12.37:

   Note that a session identifier identifies a RTSP session across
   transport sessions or connections. Control messages for more than one
   RTSP URL may be sent within a single RTSP session. Hence, it is
   possible that clients use the same session for controlling many
   streams constituting a presentation, as long as all the streams come
   from the same server. (See example in Section 14). However, multiple
   "user" sessions for the same URL from the same client MUST use
   different session identifiers.

So I would still say that there only exist an embryo to potential 
solutions for what you want to do. And if you expect RTSP 1.0 clients to 
do something like this then I wouldn't expect interoperability. I would 
be surprised if any has the functionality.

As I see it the right way forward would be to discuss this in the 
context of changes and extensions to RTSP 2.0 that would allow what you 
want to be worked into a coherent behavior.

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund at ericsson.com
----------------------------------------------------------------------
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic