<br><font size=2><tt><br>
In any case, to use your example, it's bad design for the RTSP <br>
*clients* to be deciding which multicast address each server should <br>
be using, not merely because it relies upon the server having this <br>
ability enabled. &nbsp;It makes far more sense for each *server* to choose
<br>
(or be assigned) its multicast address, in advance (when it starts <br>
up), in order to avoid conflicting with the multicast address(es) <br>
used by other server(s) on the same network. &nbsp;In general, it's the
<br>
servers that will know this, not the clients (which might be on a <br>
completely separate network, and administered separately). &nbsp;</tt></font>
<br>
<br><font size=2><tt>Re: Ok, so then what if I use SSM? &nbsp;Does that
help any of these problems?</tt></font>
<br>
<br><font size=2><tt>Also, <br>
what if you want to have more than one client play the same stream <br>
(which I imagine that you do, given that you are using multicast)? <br>
How does the first client know that it should choose a destination <br>
multicast address itself, and how do the second (and subsequent) <br>
clients know that they should, instead, use the multicast address <br>
that the first client has already given to the server?</tt></font>
<br>
<br><font size=2><tt>Re: Lol! I don't know, I could not get out of this
requirement. :( &nbsp;</tt></font>
<br>
<br><font size=2><tt>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. &nbsp;A
user that doesn't care about the address gets the default which I specified
for the server, thanks to your recommendation.</tt></font>
<br>
<br><font size=2><tt>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. &nbsp;But the SETUP
response is what really tells you what the server is going to give you.
&nbsp;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.</tt></font>
<br>
<br><font size=2><tt>Thanks for your thoughts!</tt></font>
<br><font size=2><tt>Xochitl<br>
</tt></font>
<br>
<br>
<br>