>From a user perspective, I'd recommend number 2, with an alert back to the ITSP. The BIG benefit her is that other services can come up and run, keeping a customer from a potential out of service.
One caveat for consideration. Generally, if an ITSP can't make their connection, they have a secondary route for the call - sometimes a simple voicemail, sometimes a pots line, etc. I don't know what conditions they require for that scenario, I'm assuming the %xx error would accommodate that for the ITSP, as the reroute might be a forward to another ITSP trunk to ensure continuity of service. Obviously, the more 9's you can put into the system, the better it will be. Any way to float a helium balloon out of the server so everyone sees the error? -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of M. Ranganathan Sent: Monday, July 13, 2009 2:34 PM To: sipX developers Subject: [sipX-dev] XX-6117 : Failing configtest -- a kinder and gentler sipxbridge. SipXbridge reads etc/sipxpbx/sipxbridge.xml on startup. The current strategy I follow fails configtest if there are any accounts found which have to REGISTER but have no username or password. Of course configtest failing means the service does not start. Should I start the service anyway but send alarm after startup? It appears that the visual indication we have that the service did not start is not sufficient. Possibile strategies are : 1. Fail configtest ( whcih is what happens at present ). If you don't look on the services page you deserve your fate. 2. Pass configtest but send an alarm on startup so you have some ITSP accounts functioning. When sipxbridge sees an INVITE for the ITSP account that failed configtest, I can return a 5xx server error with appropriate error text in the status code. Is 5xx the right error code here? I propose to leave the brutal approach in place for 4.0.2 but do the kinder gentler approach for 4.2. Any comments on this? 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 sipXecs IP PBX -- http://www.sipfoundry.org/ _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
