On Thu, Mar 26, 2009 at 12:14 PM, Robert Joly <[email protected]> wrote: >> 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?
No problem. No problem at all... except that I cannot presently send an alarm because of *&$#@ SSL handshake flaking out on me. I'll accept if you can help me debug this steenking handshake. Works at first and dies later... bah! > > _______________________________________________ > 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 _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
