On Mon, Mar 2, 2009 at 6:38 PM, Damian Krzeminski <[email protected]> wrote:
> 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)
Why not :
RTP start port (must be at an even boundary if you can enforce that)
Max # of remote worker calls (default to 50)
Max # of ITSP calls (default to 50)
We can change the xml file format of nattraversalrules.xml ( assuming
Robert has no counter suggestions ). The parsing of that file can
compute the End RTP port.
>
> 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)
But confused here. Are we going with port ranges or lower bound + maximum ?
>
> 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
The public address should be generated and put into the sipxbridge.xml
file. I assume this will be done per item #1 ( the first one on your
list) above.
> - External address - removed
> - Maximum calls - (see above: moved to common port ranges panel)
>
> Internally nattraversalrules.xml should become sipXrelay configuration
Are you going to change the name of it ?
> 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.
Do you foresee any changes in sipxbridge.xml or nattraversalrules.xml format?
Thanks
>
> 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
>
--
M. Ranganathan
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
