[sip-comm-dev] Question about NAT and STUN (sorry, again)


#1

I am new to sip-communicator. I am trying to get it to work with our own
SIP application server built on top of SIP Servlet container.

I searched through the previous discussion on the mailing list. In
particular from the "SIP Communicator & NAT & RTCP" thread (
https://sip-communicator.dev.java.net/servlets/ReadMsg?list=dev&msgNo=6092),
I understand the rationale for disabling STUN by default.

However, in my case the SIP server does not perform the NAT detection
procedure as described in that email thread. Instead, the SIP server relies
on the user agent sending the correct public address in both the SIP headers
and in the SDP. So I would like to enable STUN in sip-communicator, but
cannot find the documentation on how to do that. (Sorry, I know this has
been asked from time to time but I cannot find an answer in the mailing
lists.)

Can someone tell me how to:
- enable STUN and configure the address of the STUN server?
- alternatively, configure the local IP address that sip-communicator should
use?

Thanks in advance
Eric Cheung


#2

Hey Eric,

Eric Cheung wrote:

Can someone tell me how to:
- enable STUN and configure the address of the STUN server?

you have to configure a STUN server address and port in
sip-communicator.properties (or sip-communicator.xml depending on which
version of the ConfigService you are using).

the keys for both of these are:

net.java.sip.communicator.impl.netaddr.STUN_SERVER_ADDRESS
net.java.sip.communicator.impl.netaddr.STUN_SERVER_PORT

let me know if you need help setting them. Beware though as this has not
been used that much with SC and there might be glitches.

- alternatively, configure the local IP address that sip-communicator
should use?

I am afraid you can't do that at this point ... although a quick hack
wouldn't be that hard to come up with.

Cheers
Emil

···

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


#3

Hi Emil

Thanks for the quick response.

After I add the STUN_SERVER_ADDRESS and STUN_SERVER_PORT properties, I can
see from the STUN server side that it got the request.
sip-communicator0.log.0 also reports:

10:24:24.969 FINER: impl.netaddr.NetworkAddressManagerServiceImpl.run().634
Stun
Server check succeeded for server: .....

However, when sip-communicator sends REGISTER to the registrar, it still
populates the Contact header with the private IP address inside NAT.

Would it be useful if I send the log file for you to take a look?

Thanks
Eric


#4

Hey Eric,

I am afraid that's actually how it's supposed to work. Using STUN in
order to get a public address for your Contact header is quite delicate
since we need to share a socket with jain-sip. Contrary to media streams
jain-sip is never letting go of its socket so making it available to the
stun lib would be tricky.

Besides, using STUN for the SIP traffic makes little sense since it is
not really optimizing a lot and most servers would forward requests to
the address:port pair that a client is registered on anyway.

If you have control on your server then I'd suggest doing the hack
there. Should be quite easier.

Hope this helps,
Emil

Eric Cheung wrote:

···

Hi Emil

Thanks for the quick response.

After I add the STUN_SERVER_ADDRESS and STUN_SERVER_PORT properties, I
can see from the STUN server side that it got the request.
sip-communicator0.log.0 also reports:

10:24:24.969 FINER:
impl.netaddr.NetworkAddressManagerServiceImpl.run().634 Stun
Server check succeeded for server: .....

However, when sip-communicator sends REGISTER to the registrar, it still
populates the Contact header with the private IP address inside NAT.

Would it be useful if I send the log file for you to take a look?

Thanks
Eric

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


#5

Hi Emil

Thanks for the clarification. So STUN is only used (if enabled) to set the
IP address in the SDP then.

I think it is a problem with all SIP servers implemented on SIP servlet
containers because the SIP servlet API does not really support this
non-standard behavior.

When you say 'most servers would forward requests to the address:port pair
that a client is registered on anyway' are you referring to specific SIP
server software (e.g. asterisk, SERS), or public SIP services? Can you
provide an example that works with SIP communicator? I am thinking I can
front my server with one of these and work around the problem.

Thanks
Eric


#6

Hey Eric,

Hi Emil

Thanks for the clarification. So STUN is only used (if enabled) to set the
IP address in the SDP then.

In SIP Communicator it is yes.

I think it is a problem with all SIP servers implemented on SIP servlet
containers because the SIP servlet API does not really support this
non-standard behavior.

I don't have a lot of first hand experience with SIP servlet
containers but that sounds a bit odd to me since it would prevent them
to work with clients that connect from behind NATs with endpoint
dependent mapping (symmetric) ... it would also feel shaky in other
situations since standard VoIP was never a use case that people tend
to keep in mind when making NATs.

When you say 'most servers would forward requests to the address:port pair
that a client is registered on anyway' are you referring to specific SIP
server software (e.g. asterisk, SERS), or public SIP services? Can you
provide an example that works with SIP communicator? I am thinking I can
front my server with one of these and work around the problem.

I guess I meant large scale deployments since servers themselves could
be cofigured either way. You can try this with iptel.org (SER + SEMS)
or ippi.fr (OpenSIPS + Asterisk). Last time I checked sipphone.com
also did this. Not sure what's in there but I'd bet on a SER+Asterisk
combination. Free.fr, one of the bigger French ISPs, have this in
their SIP service too (freephonie.net) but you need to be subscribed
to their Internet service in order to use the SIP one.

I believe that a default asterisk installation (on Debian/Ubuntu at
least) would also behave this way.

Hope this helps,
Emil

···

On Fri, Sep 11, 2009 at 7:57 PM, Eric Cheung <eric.sh.cheung@gmail.com> wrote:


#7

Hey Eric,

> Hi Emil
>
> Thanks for the clarification. So STUN is only used (if enabled) to set
the
> IP address in the SDP then.

In SIP Communicator it is yes.

> I think it is a problem with all SIP servers implemented on SIP servlet
> containers because the SIP servlet API does not really support this
> non-standard behavior.

I don't have a lot of first hand experience with SIP servlet
containers but that sounds a bit odd to me since it would prevent them
to work with clients that connect from behind NATs with endpoint
dependent mapping (symmetric) ... it would also feel shaky in other
situations since standard VoIP was never a use case that people tend
to keep in mind when making NATs.

> When you say 'most servers would forward requests to the address:port
pair
> that a client is registered on anyway' are you referring to specific SIP
> server software (e.g. asterisk, SERS), or public SIP services? Can you
> provide an example that works with SIP communicator? I am thinking I can
> front my server with one of these and work around the problem.

I guess I meant large scale deployments since servers themselves could
be cofigured either way. You can try this with iptel.org (SER + SEMS)
or ippi.fr (OpenSIPS + Asterisk). Last time I checked sipphone.com
also did this. Not sure what's in there but I'd bet on a SER+Asterisk
combination. Free.fr, one of the bigger French ISPs, have this in
their SIP service too (freephonie.net) but you need to be subscribed
to their Internet service in order to use the SIP one.

I believe that a default asterisk installation (on Debian/Ubuntu at
least) would also behave this way.

Hope this helps,
Emil

The following applies if you are working with a recent version of JAIN-SIP:

Having spent the last year or so wallowing around in NATs (stinky business
that) and building a JAIN-SIP based ITSP gateway in a sinking boat, let me
add a couple of words if I may:

1. Some ITSPs will work with private addressing and some will not. In fact
many ITSPs do not work with private addressing in the signaling and SDP (
sorry to contradict you Emil ).

2. Not all ITSPs want private addresses in the Contact and Via headers. Many
want you to place a public address there. If you are behind a firewall, and
are dealing with such ITSPs ( for example AT&T , Bandwidth.com etc. ) you
should use your public IP address in Via, Contact and SDP.

3. You can place the public IP address in the Contact header. JAIN-SIP does
not really care. You can obtain the public address from STUN,
place this address in the Contact header and send off the INVITE.

4. For such ITSPs you should place the public Address in your SDP as well.

Its a tricky and fairly messy business. Burn your NAT. Go with IPV6 and be
happy (OK I am kidding).

Ranga

···

On Fri, Sep 11, 2009 at 2:07 PM, Emil Ivov <emcho@sip-communicator.org>wrote:

On Fri, Sep 11, 2009 at 7:57 PM, Eric Cheung <eric.sh.cheung@gmail.com> > wrote:

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

--
M. Ranganathan


#8

Hey Ranga,

M. Ranganathan wrote:

The following applies if you are working with a recent version of JAIN-SIP:

Having spent the last year or so wallowing around in NATs (stinky
business that) and building a JAIN-SIP based ITSP gateway in a sinking
boat, let me add a couple of words if I may:

1. Some ITSPs will work with private addressing and some will not. In
fact many ITSPs do not work with private addressing in the signaling and
SDP ( sorry to contradict you Emil ).

2. Not all ITSPs want private addresses in the Contact and Via headers.
Many want you to place a public address there. If you are behind a
firewall, and are dealing with such ITSPs ( for example AT&T ,
Bandwidth.com etc. ) you should use your public IP address in Via,
Contact and SDP.

I see. I guess that could make sense in the case of an ITSP that is
targeting services to a known environment with either public addresses
only or known STUN-tolerant types of NATs. Still, it contradicts the
direction that the IETF is preaching or in other words: using SIP
outbound to handle NAT traversal for SIP and ICE (including STUN) for
media only.

3. You can place the public IP address in the Contact header. JAIN-SIP
does not really care. You can obtain the public address from STUN,
place this address in the Contact header and send off the INVITE.

I am not really worried whether JAIN-SIP would let me place a public
address in the Contact header. What bothers me is that once JAIN-SIP
starts it is no longer possible (at least not without hacking the
network layers) for a third party lib to access the same port and obtain
a STUN binding. This basically means that we need to obtain a mapping
when starting the application and then trust that it will never change
until we shutdown. This is in my opinion overly optimistic as even if
one sends frequent binding update messages (e.g. empty datagrams or
REGISTERs or OPTION requests) NATs could (and do) sometimes change their
bindings in the middle of a session with for no apparent reason.

All of the above, as well as details I've pointed out in previous
threads, are our reasons for not using STUN at the moment. We will
enable it as part of ICE (some time at the end of the year) for media
but I don't think anyone is planning on making it work with SIP. If
someone is interested in contributing a patch that allows such behaviour
as a (non-default) option then please do.

Cheers,
Emil

···

4. For such ITSPs you should place the public Address in your SDP as well.

Its a tricky and fairly messy business. Burn your NAT. Go with IPV6 and
be happy (OK I am kidding).

Ranga

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

--
M. Ranganathan

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

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


#9

Hey Ranga,

M. Ranganathan wrote:

> The following applies if you are working with a recent version of
JAIN-SIP:
>
>
> Having spent the last year or so wallowing around in NATs (stinky
> business that) and building a JAIN-SIP based ITSP gateway in a sinking
> boat, let me add a couple of words if I may:
>
> 1. Some ITSPs will work with private addressing and some will not. In
> fact many ITSPs do not work with private addressing in the signaling and
> SDP ( sorry to contradict you Emil ).
>
>
> 2. Not all ITSPs want private addresses in the Contact and Via headers.
> Many want you to place a public address there. If you are behind a
> firewall, and are dealing with such ITSPs ( for example AT&T ,
> Bandwidth.com etc. ) you should use your public IP address in Via,
> Contact and SDP.

I see. I guess that could make sense in the case of an ITSP that is
targeting services to a known environment with either public addresses
only or known STUN-tolerant types of NATs. Still, it contradicts the
direction that the IETF is preaching or in other words: using SIP
outbound to handle NAT traversal for SIP and ICE (including STUN) for
media only.

To use public addresses in Signaling is in line with the sipconnect
specification for interconnection of PBXes. Many ITSPs geared towards this
market segment follow that recommendation. SipConnect wants you to use
public addresses in your signaling for call setup.

Private address based ITSPs are geared towards the home market where they
expect that a SIP phone will directly connect to the ITSP without going
through a Session Border Controller. Most big ITSPs geared towards business
users (indeed all the major ones today ) want you to use public addresses
for call setup. The assumption is that your PBX will go through an SBC
(back to back User Agent ) that does signaling rewriting. They tend to be
quite picky about symmetric relaying and will reject packets where the
source port of the packet does not match the SDP media port.

Some ITSPs will do hosted NAT compensation (i.e. look at remote port as you
describe ) if they notice that your signaling is using private addresses and
will not do hosted NAT compensation otherwise. For example LES.net is one
such ITSP.

Other ITSPs will allow you to log in and configure the account to either do
HNC or not. HNC has some bad characteristics for call forwarding. Hence many
business oriented ITSPs do not support this.

If you are a softphone ( which indeed you are ) and you expect to be either
going through a pbx or connected to one of those "homely" ITSPs ( generally
built on top of asterisk) it is a pretty good assumption that private
addressing everywhere will work just fine.

> 3. You can place the public IP address in the Contact header. JAIN-SIP
> does not really care. You can obtain the public address from STUN,
> place this address in the Contact header and send off the INVITE.

I am not really worried whether JAIN-SIP would let me place a public
address in the Contact header. What bothers me is that once JAIN-SIP
starts it is no longer possible (at least not without hacking the
network layers) for a third party lib to access the same port and obtain
a STUN binding. This basically means that we need to obtain a mapping
when starting the application and then trust that it will never change
until we shutdown. This is in my opinion overly optimistic as even if
one sends frequent binding update messages (e.g. empty datagrams or
REGISTERs or OPTION requests) NATs could (and do) sometimes change their
bindings in the middle of a session with for no apparent reason.

You can run STUN on the side. It uses another socket to ping the stun server
and hence is independent of the socket used by JAIN-SIP. I dont think its a
requirement that you use the SAME socket as is used by the signaling layer -
only that you contact the same host where you would want to send the
signaling. When the public address changes, use that public address to put
into your Contact and Via header.

( Please forgive the shameless self advertising but if you want a concrete
example please checkout sipXbridge. I use your trusty Sun4J stack there. )

Now this is all moot because as a softphone, I think your approach of using
private addressing is correct. You would either be in a pbx or talking to a
ITSP that does NAT compensation.

Ranga

···

On Sat, Sep 12, 2009 at 6:34 AM, Emil Ivov <emcho@sip-communicator.org>wrote:

All of the above, as well as details I've pointed out in previous
threads, are our reasons for not using STUN at the moment. We will
enable it as part of ICE (some time at the end of the year) for media
but I don't think anyone is planning on making it work with SIP. If
someone is interested in contributing a patch that allows such behaviour
as a (non-default) option then please do.

Cheers,
Emil

> 4. For such ITSPs you should place the public Address in your SDP as
well.
>
>
> Its a tricky and fairly messy business. Burn your NAT. Go with IPV6 and
> be happy (OK I am kidding).
>
> Ranga
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@sip-communicator.dev.java.net
> <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
> For additional commands, e-mail:
> dev-help@sip-communicator.dev.java.net
> <mailto:dev-help@sip-communicator.dev.java.net>
>
>
>
>
> --
> M. Ranganathan
>

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

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

--
M. Ranganathan


#10

Hey Ranga,

Thank you for your detailed observations. A few notes inline.

M. Ranganathan wrote:

To use public addresses in Signaling is in line with the sipconnect
specification for interconnection of PBXes. Many ITSPs geared towards
this market segment follow that recommendation. SipConnect wants you to
use public addresses in your signaling for call setup.

Yes, and this makes sense for PBXes. We don't have the same constraints
though.

If you are a softphone ( which indeed you are ) and you expect to be
either going through a pbx or connected to one of those "homely" ITSPs (
generally built on top of asterisk) it is a pretty good assumption that
private addressing everywhere will work just fine.

Glad we agree :slight_smile:

    I am not really worried whether JAIN-SIP would let me place a public
    address in the Contact header. What bothers me is that once JAIN-SIP
    starts it is no longer possible (at least not without hacking the
    network layers) for a third party lib to access the same port and obtain
    a STUN binding. This basically means that we need to obtain a mapping
    when starting the application and then trust that it will never change
    until we shutdown. This is in my opinion overly optimistic as even if
    one sends frequent binding update messages (e.g. empty datagrams or
    REGISTERs or OPTION requests) NATs could (and do) sometimes change their
    bindings in the middle of a session with for no apparent reason.

You can run STUN on the side. It uses another socket to ping the stun
server and hence is independent of the socket used by JAIN-SIP. I dont
think its a requirement that you use the SAME socket as is used by the
signaling layer - only that you contact the same host where you would
want to send the signaling. When the public address changes, use that
public address to put into your Contact and Via header.

I am not sure I follow. Indeed the STUN protocol does not require you to
use the same socket per se. However you do need the same local port or
else the binding that you are going to obtain from the STUN server is
only going to be valid for your STUN port and that's not of much use.

I don't believe you could have two separate DatagramSockets bound on the
same local port simultaneously. Trying to do this would result in
something like:

java.net.BindException: Address already in use

(Just tried it on Lin, Mac and Win ... although maybe I am missing
something?)

WDYT?
Emil

···

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


#11

Hey Ranga,

Thank you for your detailed observations. A few notes inline.
ing to be valid for your STUN port and that's not of much use.

I don't believe you could have two separate DatagramSockets bound on the
same local port simultaneously. Trying to do this would result in
something like:

java.net.BindException: Address already in use

(Just tried it on Lin, Mac and Win ... although maybe I am missing
something?)

Ah! Yes don't rely upon STUN for determining the port. Only for determining
the host address. Use rport for determining the port. No I was not
suggesting use of two sockets bound to the same port.

Regards

Ranga

···

On Sun, Sep 13, 2009 at 4:42 AM, Emil Ivov <emcho@sip-communicator.org>wrote:

WDYT?
Emil

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

--
M. Ranganathan


#12

M. Ranganathan wrote:

Ah! Yes don't rely upon STUN for determining the port. Only for
determining the host address. Use rport for determining the port.

Hmm ... if you do that then you should get your IP address together with
the port in a "received" param. In this case again, why would one need STUN?

Cheers
Emil

···

No I
was not suggesting use of two sockets bound to the same port.

Regards

Ranga

    WDYT?
    Emil

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

--
M. Ranganathan

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

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


#13

M. Ranganathan wrote:
> Ah! Yes don't rely upon STUN for determining the port. Only for
> determining the host address. Use rport for determining the port.

Hmm ... if you do that then you should get your IP address together with
the port in a "received" param. In this case again, why would one need
STUN?

The following is true if you were writing an SBC:

If you are using public address for call setup, then you would use STUN to
determine your public address.

You would need to have some prior knowledge about how ports are mapped ( for
example symmetric mapping 1-1 mapping ).

Then you could use the public address determined by STUN and that port
mapping information to set up your signaling with the sip server on the
ITSP.

You would not rely upon STUN for determining port mappings - just for IP
address determination and determining whether your NAT is mapping internal
ports to identical external ports ( i.e. validating your mapping assumptions
). You can also use STUN for NAT reboot detection.

In your case you would not have to do any of this because you are using
private addressing for everything ( correctly so ). You can rely upon an SBC
in the network to do the rest.

I would do nether STUN nor ICE and just continue with private addressing if
I were working on a soft phone.

Ranga

···

On Sun, Sep 13, 2009 at 9:25 AM, Emil Ivov <emcho@sip-communicator.org>wrote:

Cheers
Emil

> No I
> was not suggesting use of two sockets bound to the same port.
>
>
> Regards
>
> Ranga
>
>
> WDYT?
> Emil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@sip-communicator.dev.java.net
> <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
> For additional commands, e-mail:
> dev-help@sip-communicator.dev.java.net
> <mailto:dev-help@sip-communicator.dev.java.net>
>
>
>
>
> --
> M. Ranganathan
>

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

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

--
M. Ranganathan