M. Ranganathan wrote:
> The following applies if you are working with a recent version of
> 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
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
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.
On Sat, Sep 12, 2009 at 6:34 AM, Emil Ivov <firstname.lastname@example.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.
> 4. For such ITSPs you should place the public Address in your SDP as
> Its a tricky and fairly messy business. Burn your NAT. Go with IPV6 and
> be happy (OK I am kidding).
> To unsubscribe, e-mail:
> For additional commands, e-mail:
> M. Ranganathan
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
email@example.com PHONE: +18.104.22.168.43.30
http://sip-communicator.org FAX: +22.214.171.124.47.31
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com