[sip-comm] Does SIP communicator really tries to traverse NAT?


#1

I am trying to set up opensips on the server, which should detect
clients that are behind NAT.

The main way to determine NAT in opensips book is to check Contact
header of a request: if it contains 192.168.* address, then client is
behind NAT. But sniffering requests of SIP communicator, I found that
Contact header does not contain inner (192.168.*) IP addres, but
contains outer address from the router.

Does it really try to resolve NAT itself?
Is it possible to turn off this?
How to determine NAT in case if 192.168 address does not present?
Is it required to determine NAT?

Thanks.

···

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#2

You should not try as client to discover what type of NAT you are behind and use this for building your Contact header because the result depends on how the NAT router software has been implemented and unfortunately this is non-deterministic behavior. What you learn from a STUN server may or may not work afterwards so you better not use something that does not work always.

Best way is to let the client use the native IP address in its contact header and OpenSIPS will properly detect if the headers must be rewritten and if NAT must be kept alive or not.

Adrian

···

On Oct 18, 2010, at 7:08 AM, Dmitry Kravchenko wrote:

I am trying to set up opensips on the server, which should detect
clients that are behind NAT.

The main way to determine NAT in opensips book is to check Contact
header of a request: if it contains 192.168.* address, then client is
behind NAT. But sniffering requests of SIP communicator, I found that
Contact header does not contain inner (192.168.*) IP addres, but
contains outer address from the router.

Does it really try to resolve NAT itself?
Is it possible to turn off this?
How to determine NAT in case if 192.168 address does not present?
Is it required to determine NAT?

Thanks.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#3

So, this is my question: how to make SIP communicator to use native
address in it's contact header?

By default it doesn't.

···

2010/10/18 Adrian Georgescu <ag@ag-projects.com>:

Best way is to let the client use the native IP address in its contact header and OpenSIPS will properly detect if the headers must be rewritten and if NAT must be kept alive or not.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#4

I was wrong in my previous message, but I found a thing, absolutely
mysterious for me!

I was shiffering REGISTER requests both on client (Windows/SIP
communicator/Microsoft Network Monitor) and server
(Linux/Opensips/tcpdump) machines.

And I found, that the content of Contact header differs in network
communication dump!

Contact header contains private IP address if captured on client and
contains public IP address if captured on server!

How is it possible? Should I suppose some extra agent acting between
my client and server, which is doing that? Or this can be an effect of
opensips work?

Other words, can tcpdump "see" the results of opensips work, for
example it's header substituting?

···

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#5

You must have a NAT router that does this translation. You should disable this function in the router if possible. Google for 'SIP ALG problem' for more information.

Adrian

···

On Oct 18, 2010, at 8:21 AM, Dmitry Kravchenko wrote:

I was wrong in my previous message, but I found a thing, absolutely
mysterious for me!

I was shiffering REGISTER requests both on client (Windows/SIP
communicator/Microsoft Network Monitor) and server
(Linux/Opensips/tcpdump) machines.

And I found, that the content of Contact header differs in network
communication dump!

Contact header contains private IP address if captured on client and
contains public IP address if captured on server!

How is it possible? Should I suppose some extra agent acting between
my client and server, which is doing that? Or this can be an effect of
opensips work?

Other words, can tcpdump "see" the results of opensips work, for
example it's header substituting?

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#6

Hey folks,

На 18.10.10 14:37, Dmitry Kravchenko написа:

So, this is my question: how to make SIP communicator to use native
address in it's contact header?

SIP Communicator does not, and never has used STUN inside SIP messages.
We used to support it inside the SDP at one point but it was not enabled
by default and have since removed it in favour of our pending ICE support.

If you are seeing something other than your host address in a Contact
header then there's someone else putting it in there, possibly a SIP
aware ALG.

You should try and disable that behaviour on the router. Alternately you
could also make your SIP server listen on a non-standard port and make
it use TLS.

Hope this helps,
Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net