Hi Robert,
some more thoughts:
Robert Joly ha scritto:
The rule of thumb is that the NAT traversal feature should be turned on
whenever you have a deployment where there are non-SIP-aware NATs
between the sipXecs and some endpoints. A classic example of such a
deployment is the remote worker connecting from home or a hotel room.
If the sipXecs and its phones are all part of one happy network without
NATs separating them then you do not need to activate the NAT traversal
feature (even if you use sipxbridge as it comes with its own NAT
compensation scheme). For those familiar with the InGate siparator,
this feature is equivalent to its Remote SIP connectivity package.
In a non sip aware nat firewall what ports am I supposed to open to
archive the remote worker feature?
If my nat firewall reports to be SIP ALG capable NAT Traversal on
sipxecs is it unnecessary?
- What should I write in Public IP Address box if I have my
ip dynamically assigned from the ISP?
You only need to specify a Public IP address when sipXecs itself in
behind a NAT and there are phones north of that NAT. Generally, trying
to host a server from behind a NAT that can change WAN IP addresses can
cause complications and the NAT traversal feature of sipXecs is no
exception. For the time being, the feature requires a static public IP
address which most ISPs can provide at a cost.
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?
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
