It's too bad I'm not a coder, nor would you want ANY of my code that I have written included in your project. I'm a net admin and my code reflects that :-P my code knowledge really is limited to simple scripting.
I can, however, document. I have written new user guides for sipX in Atlassian Confluence (wiki software) that I'm sure I could move over to mediawiki (I like confluence best, but mediawiki will do :-P ) As far as the DNS views go, it's pretty simple to do, and I can document it in a few days whenever I get my redundant setup going again (secondary server died on my old one). Scott Lawrence wrote: > On Thu, 2009-11-05 at 13:54 -0600, Josh Patten wrote: > >> OK I just had a thought about location based DNS SRV that I wish to >> share with the members of this list in hopes of sparking discussion. A >> while back, when I actually implemented a redundant setup, I set the DNS >> server to have "views" ( >> http://www.oreillynet.com/pub/a/oreilly/networking/news/views_0501.html >> ) in that certain subnets would see the same DNS records but with >> different SRV priorities for different servers. >> >> The big advantage to this is that I could give the local sipX redundant >> sipX proxy a higher priority on that subnet than the core sipX server so >> in the event of a severed connection, extensions could still call each >> other and make emergency calls without needing to use a separate >> survivability proxy and without a drop in service. This is also useful >> for locations that have a large distance between them so call signaling >> stays local whenever possible. The disadvantage is that manual >> configuration is necessary and DNS changes to one location's zone view >> require changes in all other zone views as well. >> > > What you describe is a perfectly kosher thing to do. Congratulations on > working it out (documentation on the wiki would be good to help others > follow in your footsteps). This is exactly what the priority field of > the SRV record is meant to be used for. > > >> My question is has anyone (other than me) ever attempted this (it >> worked, BTW), and what the developers think of implementing a frontend >> into sipXconfig to make implementing this type of setup easy, or if it >> would be a waste of time/resources? >> > > There are a good many things that could be done better if we had a real > DNS manager built into sipXecs. Volunteers to build one would be more > than welcome (here's a chance to be a hero). > > The big deployment challenge with that is that many users already have > some other DNS server (and some of those are M$), so it can be difficult > to provide the configuration in a useful way (a chance to be a really > Big Hero). > > >> Also, is there a limit to the number of redundant proxies that can be >> configured? Last I heard it was 3 but I don't remember if that was a >> technical limitation or just an artificial one. >> > > At present it is 3, but it is an artificial limit. At some point, the > synchronization of registrations in an N-way configuration would begin > to be a problem. We've tested 5 in the lab, and it seemed to be ok, but > it wasn't for a long time or under very heavy load. > > > _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
