Ross Finlayson wrote:
I will try your version later on (when I get back from my vacation)
but I believe that a simple test can be made to check your
correction.
If you connect a client from the internet to your LIVE555 server
that is behind a NAT/firewall, you would be reproducing the same
situation.
No, that's a completely different situation. A LIVE555 server behind
a NAT won't work until we implement ICE.
I haven't seen any feedback on whether your multiple-interface fix
worked for anyone.
I have tried it (I am having problems with a multiple-interface
machine). It seems to get halfway there: We now compute the Content-Base
URL appropriately (and source= element in the RTSP SETUP reply [though
the o= line of the SDP still has a different IP address. This may be
appropriate, I don't have a clear idea of how it is used, if at all.].
However, the RTP and RTCP packets come from the "wrong" IP address, i.e.
not necessarily the IP address of the interface that the connection was
made to.
It seems that some firewalls block all of the UDP traffic under these
circumstances. The UDP sockets need to be bound to the appropriate
interface, rather than INADDR_ANY, to ensure that they come from the
correct IP address.
WRT NATs: I think that what Noam Camiel was proposing was to use the
actual host name/port provided in the DESCRIBE verbatim, rather than
working backwards from the socket to the IP address to the IP address
string. This would seem to fix multiple interfaces /and/ NATs, at least
for the Content-Base header. Getting the source= element of the RTSP
SETUP wouldn't work this way.
Marc Neuberger
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
