On Thu, 2009-03-26 at 16:34 -0400, M. Ranganathan wrote: > 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.
I don't believe that in practice those two are distinguishable, so you have to treat them identically. The alarm gives the user a heads-up to check and figure it out. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
