On Tue, 2009-03-24 at 15:01 -0400, Robert Joly wrote:
> > Hi,
> > 
> > Regarding XCF-3139 (Cannot add or delete Intranet Subnets on 
> > the Internet Calling GUI Page) After a discussion took on IRC 
> > we agreed upon the following changes:
> > 
> > 1.Create a new page with topology/subnets - will allow 
> > creation of multiple sets of topology/subnets 2.All sets will 
> > be generated in nattraversalrules.xml we will have something like:
> >   <localtopology>
> >     <ipV4subnet>10.0.0.0/8</ipV4subnet>
> >     <ipV4subnet>172.16.0.0/12</ipV4subnet>
> >     <ipV4subnet>192.168.0.0/16</ipV4subnet>
> >     <dnsWildcard>*.d1.itcnetworks.ro</dnsWildcard>
> >   </localtopology>
> >   <localtopology>
> >     <ipV4subnet>11.0.0.0/8</ipV4subnet>
> >     <ipV4subnet>173.16.0.0/12</ipV4subnet>
> >     <ipV4subnet>194.168.0.0/16</ipV4subnet>
> >     <dnsWildcard>*.d2.itcnetworks.ro</dnsWildcard>
> >   </localtopology>
> > 3.Internet Calling page will be changed - such as: depending 
> > on what sbc is selected will pick a topology/subnet set (from 
> > a drop-down probably) 4.For now we will keep NatTraversal Tab 
> > - we may find a better solution by the end of this sprint if 
> > time permits
> > 
> > Please share your opinions.
> 
> A few comments:
> 1- I like the idea of separating the topology information from internet
> calling & NAT traversal.
> 2- One could make the argument that the 'server behind NAT' information
> element relates to topology.  A UI-savvy person (that excludes me!)
> should consider whether or not that setting should be moved to your new
> topology page.
> 3- What is the motivation for providing multiple topology sets.  If we
> cannot think of a compelling use case then my vote is to stick a single
> set for simplicity sake.

There are lots of companies out there that have multiple subnets - ours
included, but even small ones often do.

> 4- Both NAT traversal and Internet calling should have quick links to
> that new topology page.
> 
> _______________________________________________
> sipx-dev mailing list
> [email protected]
> List Archive: http://list.sipfoundry.org/archive/sipx-dev
> Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev

_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev

Reply via email to