On Thu, 2009-03-26 at 19:14 -0400, M. Ranganathan wrote: > Hello, > > If stun discovery is not possible, sipxbridge is inoperable. In that > case, what does it mean to START it.
It means that a transient error in stun resolution does not make a perfectly good (if temporarily not useful) configuration behave like a broken configuration. > One can hope that the stun server will later recover but its far more > likely that the user entered a bad address for it. > Would it not be better to fail to start it so the user is explicitly > aware that ITSP calls cannot be made. No. It would be better if the bridge started and then sent an alarm, then continued to poll hoping that the stun eventually works (at which time it sends another alarm indicating success). > What I had previously coded up was : > > 1. Fail if discovery not possible AND no public address entered. > 2. If STUN fails in operation, ignore error but send an alarm to the user. > > In my mind it is better in that you don't have the case of a service > that starts but that simply does not work. ( This would be > acceptable if the SIPXCONFIG GUI could indicate a state of STARTING > but we dont have that today. ) What the user sees now would be, the > service starts and sends an alarm but can do nothing until the stun > server recovers. Any calls to it will result in a 503 error. Is that a > good thing ? ( maybe -- but I am not sure ). Process failure is scarier and more severe looking, and will cause the customer to look for local problems. The customer should be looking first at the external network path and the stun server. Using the supervisor to do retries at the level of restarting entire processes when the process can do it's own is misleading. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
