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 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. 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 3. sipXsupervisor should not use lack of username for one (or several) accounts with registration as a precondition for starting sipXbridge. 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. 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. 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? _______________________________________________ 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/
