[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MMUSIC] RTSP multicast question.
Yedidia Amit skrev:
Thank you all for your comments.
Now lets consider again the following scenario:
One media server which manage multiple live streams only - all the streams are sent by multicast to the local network.
Several clients (e.g. VLC) who send DESCRIBE receive SDP with the multicast details.
What is stopping them to receive the stream properly.( Even if they send SETUP and PLAY they will be answered with 200 ok)
All other controls are not relevant for this case (like PAUSE will not be supported -since this is live multicast)
What is wrong with that?
Clearly using RTSP to retrieve the SDP with all the details it needs are
workable. However, here we get to the issues:
A client that retrives a SDP with filled in c= lines to a multicast
address. What should they do? I don't think we have a clear standardized
behavior here. At least two alternatives exist:
1. Stop with RTSP and simple use the SDP, like RTSP describe was SAP or
one downloaded the SDP in HTTP or received it over email.
2. Use RTSP to perform SETUP on the media streams.
If one do 2 then one comes to the next question:
3. How does I separate this case A) when I simply want to indicate that
I am listing to a multicast group that I can't affect from B) where I
want to ask the server to please deliver the media to a multicast group
of my choice. To me both A) and B) are valid use cases.
4. What does it mean to perform PLAY on a multicast group where you will
receive media as soon as you perform the IGMP join?
5. Are there well defined signaling to have the client understand that
sending PAUSE will not do anything. Sure trying and failing will carry
that message, but unless the client is aware of these cases he might
think everything is broken and take error recovery actions.
The main point I like to make is that we clearly can support some use
cases around multicast with RTSP. However, it needs to be written up in
such a way that clients and servers are interoperable. I also think it
will need to be motivated correctly because otherwise client implementor
will not understand why they should care for a case where the client use
SETUP as way of registering its listing to the multicast group.
If you can contribute this in draft specification text to RTSP 2.0 we
clearly can have the WG consider to add it. I personally would like to
see it written up. But I have enough to work on the RTSP 2.0 core that I
don't going to branch out to cover this.
Cheers
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