Hello Mark, Answers in line.
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. > > 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. > > 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. > 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. > > 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 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 :-) Any votes on this from anybody else? I can work the solution which ever way is desired. > > > _______________________________________________ > 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/ > -- 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/
