> Woof! > > Robert wrote: > > The ideal solution would be of have a systematic way of imposing a > > start-up order in sipXsupervisor. If there was a concept of 'weak > > startup dependency' in sipXsupervisor whereby one could > declare that > > process B should only be started after launch of process A has been > > attempted (either passed or failed) then that would provide > a really > > clean solution to the problem as this would allow sipXproxy to > > immediately raise an alarm when it fails to contact > sipXrelay at init > > and start routing the calls it can. > > 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.
Thar solution is simple and definitely a better one. Ranga, do you see any pitfall with that approach? _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
