On 1 Jun 2009, at 15:12, Thomas Gelf wrote:
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?
No. Mediaproxy doesn't suffer from this problem. You can chain as many
mediaproxy relays as you want, they will simply work without any need
to do anything in the proxy configuration. The only requirement is
that all chained media relays have a public IP address.
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?!
It obviously has to listen in userspace for the first packets from
each side, before it can create a conntrack rule.
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?).
Of course it cares. A conntrack rule maps a certain source IP/port
with a destination IP/port via a parit of IP/port on the relay.
But even doing so could still lead to "deadlocks", correct?
Incorrect. Mediaproxy doesn't deadlock by design. All that is required
is to use public IP addresses on relays.
--
Dan
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
