[OpenSIPS-Users] Comparing client_nat_test with nat_uac_test

[Dan Pascu]

On 2 Jun 2009, at 12:34, Bogdan-Andrei Iancu wrote:

> Hi Dan,
>
> Dan Pascu wrote:
>>
>> 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.
>>
> Out of curiosity....How does it work? typically you have to wait to  
> receive traffic in order to be discover the end RTP points and to  
> start sending. So, how MP proceed? does it automatically trust the  
> received IP in SDP till incoming traffic updates the end peer info?  
> or ?


If one endpoint has a public IP, it can already start forwarding to  
it, even before it receives a packet from it. This way it eliminates  
the deadlock, as the relays will always get packets from other relays  
even before they start sending to them. However the conntrack rule is  
only set in place after it had received a packet from both endpoints.

--
Dan