On Thu, 2009-03-26 at 16:31 -0400, M. Ranganathan wrote: > On Thu, Mar 26, 2009 at 2:12 PM, Scott Lawrence > <[email protected]> wrote: > > On Thu, 2009-03-26 at 11:27 -0400, Andy Spitzer wrote: > >> > >> I disagree. The idea solution would be to allow sipXrelay to start > >> even if it cannot get STUN. It should continue to try to get STUN > >> periodically, and alarm if it cannot after some period (and alarm > >> again when it actually gets an answer, and alarm again if it loses it > >> again). That gets rid of the dependency problem yet still allows > >> sipXrelay to be started before sipXproxy. > >> > >> Using sipXsupervisor as a retry mechanism...I don't like it. > > > > +2 > > > > Is it appropriate to send an alarm if stun server does not work during > configtest ? I assume ( based upon this discussion ) that failing > configtest is not the right thing to do.
Once you change configtest to not do this check, the test will pass, supervisor will start the relay, the relay will do the stun check - if that fails, it should send an alarm. You don't need both. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
