On Fri, 2009-06-26 at 17:03 -0400, Gertsvolf, Mark (CAR:9D30) wrote: > Scott Lawrence wrote: > > > > 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. > > > > Stop right there. > > > > That's a sipXconfig bug - it should not have been willing to > > generate a configuration with an internal inconsistency that bad. > > Agreed, unfortunately, this is the way all SIP trunks are provisioned > today. The "create" page does not let you set username/password. It also > does not let you to change "registration" setting. All SIP trunks after > going through "create" page are in a state, where further provisioning > is required. > Perhaps the way to solve this problem is to expose username/password and > registration checkbox on the "create" page and refuse to create the SIP > trunk if there is an inconsistency.
I'm sure there are several possible solutions, with some UI improvements and some configuration generation elements. In this case, the key is that the sipXconfig application must understand that the data it has is incomplete and/or internally inconsistent (one data value requires registration, but there are no credentials with which to do that registration); it should refuse to send such a profile. It's not true that sipXconfig should understand and validate all possible relationships between configuration settings - that would be asking way too much, but when we find one this bad and this easy to detect, it should be fixed. At bottom though, this was user error, and not that hard to diagnose. > > > 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? > > > > By all means report the fact that you were able to configure > > this broken configuration. > > > > The configtest for a component should not send an alarm; if > > anything, sipxsupervisor should send it, but I think that the > > current service status display is pretty good in this regard. > > It is not possible to find out that something is wrong with one of the > components unless you actually visit the "services" page. At the same > time there are visual indications 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. > In addition I would personally also like to see an alarm via email/IM, > since the condition may very well occur asynchronously, after the admin > leaves the admin portal. Yes, in general that's a good idea, but it's really a separate improvement - not a bug. _______________________________________________ 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/
