In any case, to use your example, it's bad design for the RTSP *clients* to be deciding which multicast address each server should be using, not merely because it relies upon the server having this ability enabled. It makes far more sense for each *server* to choose (or be assigned) its multicast address, in advance (when it starts up), in order to avoid conflicting with the multicast address(es) used by other server(s) on the same network. In general, it's the servers that will know this, not the clients (which might be on a completely separate network, and administered separately).
Re: Ok, so then what if I use SSM? Does that help any of these problems? Also, what if you want to have more than one client play the same stream (which I imagine that you do, given that you are using multicast)? How does the first client know that it should choose a destination multicast address itself, and how do the second (and subsequent) clients know that they should, instead, use the multicast address that the first client has already given to the server? Re: Lol! I don't know, I could not get out of this requirement. :( So, I implement like this: If the user really, really wants to use the multicast address he/she likes best, and the server isn't able to deliver the data to that address, then the session fails. A user that doesn't care about the address gets the default which I specified for the server, thanks to your recommendation. I thought that in RTSP if you specify the Transport Parameters in SETUP, the RTSP server is only supposed to *try* to give you the Transport you want if the server is able to. But the SETUP response is what really tells you what the server is going to give you. I know in the LIVE that the MediaSession is configured/initiated using the SDP, but I suppose I could try to read the Transport response and go back and change the MediaSession if any of the changes can be done after the subsessions are initiated. Thanks for your thoughts! Xochitl
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
