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. > > 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. > > 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 ).
Consider - if the bridge is running, it can send back: 503 ITSP "example.net" unreachable - unable to resolve public address using stun to "stun.example.com" so not only is the alarm available to the admin, but every failed call will contain diagnostic information on the source of the problem. If the bridge does not start, the error will be 408 Timeout or possibly a local transport error indication. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
