I think what Ranga is doing right now is keeping the system from signalling a false failure because of an inconclusive or erroneous startup error message. At least working towards keeping that from happening.
A helium balloon would be nice too. At the same time if the ITSP does not require registration, it's hard to tell what failsafe offerings they have. Every ITSP is different. Obviously pointing the calls to a POTS line and having an analog gateway is not a bad idea either. I had that feature with an ITSP, and paid for it every month, and when it failed it did not work because their system failed, the registration worked but no calls came through the trunk or the POTS backup. Sheesh. Our current carrier offers a web portal where we can login and redirect DID's to any number we need them to go to, or we can call them, and it doesn't cost extra, but it's not automated. >>> "Todd Hodgen" <[email protected]> 07/13/09 7:36 PM >>> >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/ </[email protected]> _______________________________________________ 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/
