On Thu, Mar 26, 2009 at 1:34 PM, M. Ranganathan <[email protected]> wrote: > 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!
I will simply refuse ITSP calls at sipxbridge if a public address cannot be found in time for such outbound calls to be made. > > > > >> >> _______________________________________________ >> 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
