Current NAT traversal support (we really could use a better name for this
feature) was written in parallel with a whole slew of non-trivial changes
in sipXconfig: adding support for multiple servers and re-write of
configuration generation.
As a result NAT traversal UI doesn't do justice to this feature. It make
many capabilities impossible to configure, and the ones that are supported
are far from obvious.
Some time ago Robert, Ranga and I came up with a list of changes. Only
recently, after completing server and services re-write we can actually
start implementing them:
1. New "NAT" tab for a Server will contain per-server NAT traversal parameters
Public addressing (per-server parameters):
- Drop-down "use STUN" vs. "specify IP address"
- public IP address (if 'specify IP address')
- stun address and stun interval (if 'use STUN')
- public port - always available (even if "use STUN is selected") - public
port is not discovered by STUN
- RTP start port (advanced)
- End RTP port (advanced)
2. Current NAT Traversal page
Parameters that will remain
- Enable NAT traversal
- Media-relay aggressiveness
- behind NAT checkbox - common - non-server specific parameter (either
entire cluster is behind NAT or not)
Improved port ranges configuration panel (per-cluster):
- maximum 'remote workers' calls
- maximum 'sipXbridge' calls
In future (probably not 4.0) sipXconfig should calculate and displays port
ranges that needs to be configured in firewall based on those values (4
ports per call)
All other parameters will be removed:
- XML-RPC port - hidden - set by sipXconfig, not configurable
- External address (retrieved from server/location)
- Local address (retrieved from server/location)
- Logging level will be moved to sipXrelay configuration (and ultimately to
new common logging screen)
Some changes in "Internal SBC" configuration ("SIP" tab):
- Public address - removed
- External address - removed
- Maximum calls - (see above: moved to common port ranges panel)
Internally nattraversalrules.xml should become sipXrelay configuration
files and will be generated in the same way as other configuration files
(and not with dial plans as today).
The might be also some adjustments required in sipxbridge.xml generation -
to make sure that we get port and addressing data from Server/Location.
D.
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
