On Mon, 2010-05-10 at 12:44 -0400, Mossman, Paul (Paul) wrote: > Scott wrote: > > I think that for 4.3 we should focus mostly on creating a UI > > that makes the current routing mechanisms easier to set up, > > understand, and debug. > > This particular behaviour is quite perplexing. A UI that makes it > easy to set up, understand, and debug will be challenging.
That's why you get paid the Big Bucks, Paul :-) > Regardless of whether or not we remove it in the next release... If > the behaviour is undesirable, then I will not reflect it in the new > UI. > > If the behaviour has a useful purpose, then I should consider how the > new UI could make it easier to set up, understand, and debug. Well, it's never been 'reflected' in the current UI in any meaningful sense; we don't have any UI at all for debugging dial plans, and the one we have for displaying what exists is actively misleading (in that it presents an order that often differs from the real one). Many of the real routing mechanisms are, at present, essentially invisible to the administrator - they are implicit based on the fact that some endpoint or service is configured. It would be great if there were a comprehensive mechanism to display all that, but that is a very big job. I think that the dial plan display in XX-7050 is a huge improvement over the current one. If in XX-7822 you just make the distinction between mapping/transformation and fallback/routing rules when creating them, you'll have taken another big step forward. > If the behaviour has a useful purpose, then I should consider how the > new UI could make it easier to set up, understand, and debug. If by 'the behavior' you mean 'mappingrules are applied even when some other mechanism has added one or more contacts', then yes, I think that it does. If anything, I think we should change the fallbackrules behavior so that it is also applied and can provide parallel external contacts, but there are good reasons not to do that now (having to do with whether or not gateways would 'seize' the call and mess up the forking... don't ask). A significantly easier (but not easy) change would be to allow multiple transformation rules to apply to the same call. Getting a creation and display mechanism that makes that clear is even harder than doing so for the current behavior though, and debugging those configurations would also be quite challenging. If/when we have a good facility for displaying and debugging why a particular call was routed the way it was (currently too complex for most phone system admins), then we should consider adding power and flexibility, but until then I think it would be just asking for (more) trouble. _______________________________________________ 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/
