On Fri, 2010-05-07 at 14:13 -0400, Mossman, Paul (Paul) wrote: > Scott wrote: > > > Why isn't the same true of the mappingrules > > (transformation-only) redirector? > > > > Because it's not designed that way :-) > > > > > i.e. You have a conference bridge 6480, and a 6XXX->XXX > > > transformation-only rule. An INVITE to 6480 will result in > > a Contact > > > for the conference bridge, but also 480? Surely a User 480 > > would not > > > also receive an INVITE? > > > > Yes, both would get that call - since the conference bridge > > answers right away, it would probably win the resulting race. > > I doubt admins expect transformation-only dial plan rules to cause > simring with internal extensions. Certainly not based on the UI we > are currently presenting. > > Are there any plausible use cases where this is required?
I'm not sure that I understand the question... do you mean "do we need the current behavior of mappingrules to add contacts when there already are some?". Even aside from the backward-compatibility problem the change would create, I think the answer is yes. > If not, then should we consider changing mappingrules redirectors so > that they too only return a Contact when no previous redirector has > added one. Why? It has always worked this way... what's the problem you want to solve? If there's a change we should think about, it's allowing more than one rule to match, but doing _that_ in a backwards-compatible way is a significant challenge because you have to have a flag or some other mechanism that says "if this rule matches then stop trying", and then set that flag on all rules when converting from previous versions. 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. Once we've got that, then it will be safe to start thinking about changing them. _______________________________________________ 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/
