On Thu, 2010-05-06 at 15:03 -0400, Mossman, Paul (Paul) wrote: > > > If you eliminate those dial plan entries, what is the > > implication for upgrade? > > Post upgrade you'd end up with potentially multiple Custom rules for > each old rule.
Well, really the whole notion of the class of rule should probably just go away... if all rules are Custom rules, why bother calling them that? Each rule has a name, and you can use the old rule type to set the rule names for the converted rules (if those rules are enabled - if not, I'd say just drop them). The real distinction is between 'transformation' rules (rules which manipulate the user/phone-number part of the address but to not send it to a gateway), and 'routing' rules (which may manipulate the user/phone-number part but also change the domain/address part to send it outside the sipXecs system). In the current UI this distinction is actually obscured: any rule that has one or more gateways is a 'routing' rule, and any that does not is a 'transformation' rule. Here's the real catch that's also actually confused by the current UI: transformation rules (mappingrules.xml) are searched first, and only the first match is applied; routing rules (fallbackrules.xml) are searched _only_ if no other mechanism has provided a way to route the call. The current UI lets you mix them up, so that it looks as though a rule with a gateway in it takes precedence (is higher in the list) over a transformation rule, but that's not how it really works. _______________________________________________ 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/
