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. --Woof! _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
