Hi Robert,
If my nat firewall reports to be SIP ALG capable NAT Traversal on
sipxecs is it unnecessary?
[<<BOB JOLY>>] In theory, it is unnecessary if all the NATs in
your deployment have SIP ALGs however if you have remote workers
behind non-SIP-aware NATs (somebody connecting from a hotel for
example), the SIP ALG in your local router cannot help in this
scenario. In general, unless your router is one that has been
tested against sipXecs (InGate, Intertex) I would think you will
achieve better results in the long run with relying on sipXecs's
native NAT traversal feature as opposed to the router's generic
SIP ALG implementation.
How can I test the router SIP ALG implementation to make sure it could
cooperate with sipxecs (without the upcoming NAT Traversal)?
In case I want to rely on sipxecs NAT Traversal, SIP ALG on the router
must be disabled? I mean is possible the two NAT Traversal (on the
router, and on sipxecs) might interfere each other?
Well I don't completely agree here. I'm dealing mostly with small
installations that rely on dynamic IPs. Dynamic IPs that are
changing very rarely (once I force the router to reboot). These
small installations have needs comparable to big ones but with
less users accessing the corporate network really occasionally. I
hosted private server services behind NAT with a dynamic IP and
dynamic DNS and in all cases this has been fine enough to satisfy
the customer needs. I'm thinking mostly to VPNs. Of course there
are limits to this solution, but as I said this if definitely fine
enough.
Forcing the remote worker feature to be available only to network
with a static IP it's a strict limit. Right now sipxbridge can
determine reliably the public IP using STUN and self heal in case
of an IP change. Why not share the same existing feature?
[<<BOB JOLY>>] I appreciate your insights here. STUN is not a
very reliable way to determine the public IP address of a device
that is why it is taking a backseat in sipxvbridge (see
http://list.sipfoundry.org/archive/sipx-dev/msg11667.html).
Perhaps the best of both words would be to allow a STUN option for
the NAT traversal feature to address cases like yours.
Well, every working SIP phone able to connect to an ITSP directly
dealing with NAT Traversal I tried use STUN. Most of them don't even
have an option setting to set a static IP. I really cannot judge if STUN
is reliable or not, but I would definitely vote for an option to allow
dynamic IP deployments to be able to use the remote worker feature.
Alberto
_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
