> -----Original Message----- > From: [email protected] [mailto:sipx-dev- > [email protected]] On Behalf Of Robert Joly > Sent: Wednesday, March 25, 2009 9:02 AM > To: Scott Lawrence > Cc: [email protected] > Subject: Re: [sipX-dev] XCF-3139 Proposal > > > 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. > > That I understand and that has my full support however that is not what > I was inquiring about. A topology can consist of n IP subnets and m > DNS > widlcards and that is fine but what is being proposed is the ability to > define multiple topologies. See xml file mock-up proposed (re-copied > below): > > <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> > > What I'm asking about is the presence of multiple <localtopology>. > Currently, we can only define one local topology (hence a single > <localtopology>). Is was inquiring about the justifications for > introducing multiple ones.
As long as multiple internal subnets can be defined within the localtopology I think that would be acceptable. > _______________________________________________ > 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
