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 ). Chris Parfitt please note note : I am talking about SIPXBRIDGE in this note (and not SIPXRELAY) just in case there is some confusion. The arguments above dont apply to sipxrelay which causes sipx proxy to not start. I am soon committing a reworked version that is based upon the "Always start but send alarm" philosophy applied to both sipxbridge and sipxrelay but I am having some reservations about it and I thought I should air them. Disclaimer : I am no UI expert. Please air your opinions. Ranga -- 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
