On Thu, Mar 26, 2009 at 4:31 PM, M. Ranganathan <[email protected]> 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.
There are actually two conditions here. 1. The stun server address is plain wrong ( bad ip address or cannot even be resolved) 2. The address is OK but there is no stun server running. I assume that in case 1, the right thing to do is to FAIL configtest. I assume in case 2 the right thing to do is PASS configtest but send an alarm. Opinions? Ranga >> >> _______________________________________________ >> sipx-dev mailing list >> [email protected] >> List Archive: http://list.sipfoundry.org/archive/sipx-dev >> Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev >> > > > > -- > M. Ranganathan > -- M. Ranganathan _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
