>> 2. As "NAT Traversal" and "Internet Calling" really are meant for >> different things, and there is no logical correlation, I propose to >> keep them as completely separate items/pages under "System", "Nat >> Traversal" and "SBC Routes" namely.
> These two features can be viewed as providing similar services. Both will > help you reach URIs that are outside of sipXecs's local private > >domain and > will manage the NAT traversal issues. I'd like to propose a different > approach... If we can position the internet calling and NAT > traversal > features as two competing technologies for achieving connectivity in a > network plagued with NATs then I think we can simplify things > quite a bit. > The GUI could simply be a pull-down menu with a simple label: 'NAT Traversal > provider' and the pull down menu has two choices: 1= >Built-in NAT Traversal; > 2= External SBC. You pick one or the other but you cannot have both. In > either case, you will be required to datafill >>the Intranet subnets and > Intranet domains on that page and will be used by whatever NAT traversal > provider you have selected. I like that. In fact, it is exactly what Paul and I concluded from a off-line discussion. We will make a dropdown list to ask user to choose one way or the other, but not both. > Both features need an exhaustive list of subnets and domain that make up the > private network that sipXecs bathes in and that list is the same > for both > features. Does it make sense to have two places in the GUI where that > information can be entered? I think there's inherent complixity in this as > well. With the dropdown list to make the selection, this problem no longer apply. You only need to enter the configuration for private network once. Thanks Huijun _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
