Bogdan-Andrei Iancu wrote: >> test 8 (search RFC1918 >> addresses in the SDP payload) has no equivalent in client_nat_test().
> again, I do use this use this test, but not for detecting the private > IPs, but public once - this is useful when doing chains of RTPproxys + > mediaproxy + whatever other media relay. > ... > here, to avoid deadlock between the 2 media relays, you detect if a > public IP is in the SDP and start using that IP right away instead of > waiting to receive traffic (in order to discover the RTP peer). That's a good example, thank you. Could such a "deadlock" still happen with current Mediaproxy implementations? Hmmm... While reflecting about the whole thing... how does Mediaproxy find out what port this clients RTP will come from - if using nothing but netlink/netfilter?! And: does it care about source ports? Or does it just "forward" packets arriving on that specific reserved port (maybe checking just the source ip?). But even doing so could still lead to "deadlocks", correct? Regardless of this thoughts - once a client's Via (with public IPs) doesn't correspond to IP/port the packet came from, how "thrustworthy" is a public IP/port pair in SDP? And, indepentently from all of the above - shall I add a feature request asking for a test checking for RFC1918 addresses in SDP payload? Best regards, Thomas Gelf _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
