[OpenSIPS-Users] Comparing client_nat_test with nat_uac_test

[Dan Pascu]

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20090602/7df5fce5/attachment.htm