> 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
Am I correct in assuming that the public IP address field will only be
visible if 'specify IP address' is chosen from the dropdown list?
Similarly, "STUN server address" and "interval" will only be shown if
"Use STUN" is chosen?
>
> - RTP start port (advanced)
> - End RTP port (advanced)
Looking at the notes I had taken, it sounds like we are walking away
from the End RTP port value auto-calculations in this first pass. In
cases where the admin configured too narrow of a range given the
existing maximum calls (or too large of a maximum calls given the
existing RTP port range), how will he be warned that his configuration
is invalid? Wouldn't the 'invalid configuration warning' mechanism be
as difficult to implement as providing automatic end RTP port
calculation?
>
> 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)
If the behind NAT checkbox is checked then the admin must specify either
a public IP address or a STUN server for each element of the cluster.
This would need to be enforced by sipXconfig.
>
> 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.
Thank you for looking into this - this re-organization of the NAT
traversal configuration will go a long way toward making this feature
usable and more generally adopted.
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
