Comparing client_nat_test with nat_uac_test

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Comparing client_nat_test with nat_uac_test

Thomas Gelf
Another thing I stumbled over is one missing test in client_nat_test():
test 1 is the same in both modules, nat_traversal's test 2 corresponds
to 18 (2 & 16) in nathelper's nat_uac_test, test 8 (search RFC1918
addresses in the SDP payload) has no equivalent in client_nat_test().

Is test 8 useless? Is anyone aware of scenarios where RFC1918 could
appear in SDP, even with a correct SIP header? I know that EVERYTHING
is possible with a braindead ALG - but are there other situations where
this could happen? I wasn't able to figure out such an example, so
client_nat_test("7") should probably suffice for all cases.

Is this assumption correct?

Best regards,
Thomas Gelf


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Comparing client_nat_test with nat_uac_test

Bogdan-Andrei Iancu
Hi Thomas,

Thomas Gelf wrote:
> Another thing I stumbled over is one missing test in client_nat_test():
> test 1 is the same in both modules, nat_traversal's test 2 corresponds
> to 18 (2 & 16) in nathelper's nat_uac_test,
I found useful such a separation because in some cases (asymmetric GWs),
a GW may be detected as nated just because it advertise a different port
in VIA. So, I would like to have the control over these tests.
>  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.

example is : UAC1 (nat) ---- proxy1 (forces RTPP as caller is natted)
----proxy2 (forces RTPP as callee is natted) ---- UAC2(nat)

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).

Regards,
Bogdan

> Is test 8 useless? Is anyone aware of scenarios where RFC1918 could
> appear in SDP, even with a correct SIP header? I know that EVERYTHING
> is possible with a braindead ALG - but are there other situations where
> this could happen? I wasn't able to figure out such an example, so
> client_nat_test("7") should probably suffice for all cases.
>
> Is this assumption correct?
>
> Best regards,
> Thomas Gelf
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Comparing client_nat_test with nat_uac_test

Thomas Gelf
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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: 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




_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Comparing client_nat_test with nat_uac_test

Bogdan-Andrei Iancu
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 ?

Regards,
Bogdan

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: 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




_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users