M. Ranganathan wrote: > > On Fri, Jun 26, 2009 at 12:38 PM, Mark > Gertsvolf<[email protected]> wrote: > > sipXecs 4.0.1-015823 > > > > Create a new gateway of type SIP trunk using "None" as a template. > > Fill in all available fields on the page and choose "route via > > internal bridge" option. Press OK. > > As a result of the above a new gateway of type "SIP trunk " > is created > > with "registration" option turned on and no > username/password specified. > > > > At this point if an unrelated configuration change is made, which > > causes sipXbridge profile to be regenerated, sipXbridge can > not start: > > sipXsupervisor decides that a precondition to start > sipXbridge is not > > met: User Name is mandatory for ITSP accounts requiring > Registration. > > Check ITSP account xx.yy.zz.ww > > Actually sipxbridge is making that determination. If desired, > I can generate an alarm for this.
Hi Ranga, sipXsupervisor is attempting to restart sipXbridge and is executing "/usr/bin/sipxbridge.sh --configtest" to determine if sipXbridge is configured to run properly. If it finds out the component is not ready it should raise the alarm. In my opinion the component itself can not raise an alarm from inside its configtest invocation as it does not know why configtest is being executed. > > > > At the same time sipXsupervisor does not generate an alarm or any > > other visual indication to indicate that an important > system component > > has > > failed: No jobs show as failing, including sipXbridge restart job. > > There is no way of knowing that the system has a problem. > > If configtest fails, there should be a visual indication > hence I thought it unnecessary to generate an alarm. No other > component seems to generate such an alarm. My view is that this is the role of sipXsupervisor to raise an alarm whenever "start" operation fails due to component configtest failure. Component itself has no context as to why configtest is executed. > > > > In my opinion several things are suboptimal in this case: > > > > 1. Sole creation of a SIP trunk, which has not even been > included in > > any dial plan rules causes sipXbridge to stop working. > Combined this > > with behaviors such as http://track.sipfoundry.org/browse/XX-5878, > > where sipXbridge profile gets generated and sipXbridge is restarted > > without the control of the admin is making it difficult for > admin to > > make changes on a live system. I'll throw > > http://track.sipfoundry.org/browse/XX-5882 into the mix to > highlight > > how seemingly benign changes in SIP trunk are impacting system > > behavior in an unpredictable way. > > > > 2. Default profile should not have "registration" turned on > by default > > (possibly a minor thing), but it triggers the problem at hand > > Agreed. Please open a sipxconfig jira issue to remove it. > > > > > > 3. sipXsupervisor should not use lack of username for one > (or several) > > accounts with registration as a precondition for starting > sipXbridge. > > Not sure I agree here. > It is a configuration failure. SipXbridge is failing configest. > It would be relatively easy for a user to remove the > offending account or supply the necessary information. Apologies, this should have been worded as: sipXbridge should not use lack of username for one (or several) accounts with registration as a precondition for starting. > > sipXbridge may have N other workable accounts, which are > good to go. > > Why not let sipXbridge start and complain about the one invalid > > account and disable registration for it. This will allow > the rest of > > the ITSP accounts in the system to work properly. > > Well, if calls are routed to that account then how should > sipxbridge respond? Especially in light of 4.1 requirements > where sipxbridge will just route the call to the domain of > the ITSP even if a valid account does not exist. If during initialization sipXbridge finds an ITSP account with registration turned on and no user provisioned, it can raise an alarm and disable registration. The alarm should be a signal that incoming calls will not work. At the same time, inability to register against an ITSP should not be the reason not to allow outgoing calls. ITSP may not even challenge the call, just like bandwidth.com or any other ITSP with ACL based authentication. As a result username is only required for an outgoing call if the call is challenged. At that point sipXbridge may fail the call with an appropriate error code and possibly raise an alarm. > > > > 4. sipXsupervisor does not create an alarm and NO visual indication > > exists in the system to alert the admin that one of the key system > > components can not start. > > > Visual indication should exist on the services page. I do not routinely visit services page. At the same time I do see visual indication on multiple pages when one or more services needs to be restarted or when one of the jobs fail or when updates are available. There should be a similar visual indication telling the admin that one or more services can not run due to configuration or another issue. > > > > I am planning to report this behavior in a JIRA ticket. Do > we have a > > consensus that this problem is worth reporting, or does > anybody think > > I am being totally unreasonable complaining about this? > > No but I think sipxbridge is not totally unreasonable either :-) sipXbridge rocks! I meant no offense with the "unreasonable" comment. _______________________________________________ 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/
