On Thu, 2008-05-22 at 11:55 -0400, Scott Lawrence wrote:
> On Thu, 2008-05-22 at 11:04 -0400, Huijun Yang wrote:
> > Scott,
> >
> > XECS-1305 : "There are some circumstances under which a redirector may
> > 'know' that its decision regarding a given request is authoritative and
> > should override any others. "
> >
> > Currently, I only see some error cases that a redirector provides a
> > forced response. Do you see or foresee any scenarios that lookup is
> > successfull, but still decide to override others' decision?
>
> Certainly.
>
> You won't find examples now, because there's no way to do it anyway...
>
> There are lots of internal targets (like MoH, call pickup, etc) for
> which a specific redirector could claim to be authoritative.
Given how dial plans are constructed, a single dial string (user-part)
will almost always cause only one redirector to generate a contact.
There have been problems with this in the past, that is, redirectors
unexpectedly producing contacts for dial strings, but the fundamental
cause is that the redirector has an excessively broad idea of the dial
strings that it is responsible for. So in almost all cases, the
redirectors can be allowed to execute in any order and without regard to
the results of the other redirectors.
The above assertion is true because dial plans are almost always
constructed to have unambiguous prefixes and simple patterns. It breaks
down if you construct a dial plan where one pattern overlaps with
another pattern and there is an expressed priority between them. E.g.:
if your dial plan contained:
617-xxx-xxxx local call
xxx-xxx-xxxx long-distance call
and you treat the first category differently from the second category.
Now we already have processing like that, in the "mappingrules" vs.
"fallbackrules" mechanism, and it indeed violates the assertions in my
first paragraph. (Although in most installations, I think the
fallbackrules could be made disjoint from the mappingrules.)
However, if we are going to have a redirector declare itself to be
authoritative, and exclude the output of all other redirectors, the main
benefit is to avoid executing the remainder of the redirectors. But the
current thinking for XECS-1305 is that all of the redirectors have to be
executed anyway.
Dale
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
