> Damian wrote: > > Why don't we fix the problem where it really is: proxy and > > registrar should read dial plan when it changes and start > > using new dial plan when it makes sense for them: they know > > after all best when it's safe to do that.
Paul Mossman wrote: > Not sure how difficult it would be to coordinate that in current > architecture. But it would probably be considerably easier if the proxy > and registrar were unified into a single component...... Moderate difficulty. We'd have to rewrite some of the code that processes the various configuration files, but some of that code desperately needs rewriting anyway, and there are some features pending that would overlap nicely with that work. There would be significant opportunity for efficiency improvements while we were at it - the current processing of the mapping/fallback/auth rules is "suboptimal". As for signaling the change, most of the links in the chain are already there - because replication happens through sipXsupervisor, and it knows which processes need which files, it knows which processes to signal. We would certainly need to add a standard mechanism to pass that indication to the process (there are a few alternatives that have been discussed already). I suspect that we'd want to add an indication from sipXconfig that reconfiguration is complete so that when it needs to update multiple files (as it does for dialing rules) the process would not be signaled to reconfigure until all of them were done - this could either be a new signal, or we could just add this semantic to the updating of the configuration version stamp (that is, no process is told to reconfigure by sipXsupervisor until the configuration version stamp is written, even if its value has not changed). _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
