Dale Worley wrote: > Sorry for all the trouble about this issue -- yesterday was a tense day, > and I've not been in the loop about this issue. But I get nervous when > a proposed change might disable some of my debugging tools -- it's not > fun to have a high-priority customer problem on your desk and discover > that your debugging tools don't work any more. And though there was a > meeting about this when I was gone, nobody had told me of the tradeoffs > being made or asked me to sign off on them. > > Thinking about Scott's suggestion, it does seem sufficient to arrange > the *-config files as one wants and then to disable sipXconfig from > running. > > BTW, are we eliminating sipXproxy-config.in, and directly generating > sipXproxy-config? >
Yes, sipXproxy is the first -config.in file to be replaced. sipXconfig will handle the config preprocessing using configpp and then all user-configured settings will be stored in the database and the file generated when necessary (after config changes and on sipXconfig startup, at the present time). You can think of etc/sipxproxy/sipXproxy-config.vm as the replacement for sipXproxy-config.in Kevin _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
