M. Ranganathan wrote: > 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.
I did not forget about it (that's what my comment below applies to): I left an issue opened for that. http://track.sipfoundry.org/browse/XCF-2776 But I really want us to get the basics done first and then improve upon it. I'd rather sipXconfig worried about computing the range: in this way it's very clear what the port range really is. It's my understanding that admin needs to see that anyway to configure firewall. > >> 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 ? > Port ranges for now. > >> 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. > Yes. That's why I said that there are some sipxbridge.xml adjustment required. > > >> - 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 ? No. I hope I never suggested it anywhere. > >> 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? I hope not: in my opinion they changed too much already ;-) 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
