On Tue, Mar 3, 2009 at 10:24 AM, Robert Joly <[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
>
> 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.
Why a possibly different STUN server for EACH element of the cluster?
Will it not suffice to have a single STUN server address for the
entire cluster? I understand that it might be simpler to do the one
stun server per element from a UI and data management perspective....
Ranga
> 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.
> - Show quoted text -
> _______________________________________________
> 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
