My apologies for taking so long to respond to this...
On Tue, 2008-09-16 at 11:06 -0400, Robert Joly wrote:
> High-level overview of the new redirect plugin processing proposal
> ==================================================================
> In order to address the requirements requested in XECS-476 and XECS-1305
> a series of modifications to the current plugin processing are proposed.
> This bullet list summarizes these changes and explains why they are
> introduced:
>
> #1- Modifications to error handling: Currently, the lookUp() method can
> report two kinds of errors; request errors and server errors. This
> proposal will only use a single error code and lookUp() will pass an
> 'ErrorDescriptor' object to be filled in by the redirector reporting the
> error. This object lets a redirector specify the response status code,
> optional reason phrase, optional Warning code and text to be used by the
> redirect server when constructing the error response. This object could
> also contain a flag that indicates whether or not a copy of the
> offending request message should be added as a body of the response.
> Also, unlike the current implementation, the plug-in chain is aborted on
> the first error reported (with proper suspended plug-ins clean-up).
This seems good.
> #2- Establish precedence of Contacts provided by redirectors: To address
> XECS-1305, plug-ins must be able to indicate that their response is
> authoritative however, some redirectors such as the AuthRouterPlugin,
> because of the security function it provides, always need to see and
> modify all Contacts whether or not they were added authoritatively by
> another plug-in. In order to meet this requirement a series of changes
> are proposed:
> A- a new 'authority level' attribute is added to each redirector
> plug-in.
> B- The SUCCESS return code is replaced by SUCCESS_LOOKUP_DONE and
> SUCCESS_SKIP
> C- a new method void RedirectPlugin::observe() is added to the
> RedirectPlugin interface definition
> When a redirector plugin returns SUCCESS_LOOKUP_DONE, the RedirectServer
> will tag the entire Contact list with the Authority Level of the
> plug-in. Any subsequent plug-in in the chain of lower 'Authority Level'
> will only get to observe the message via RedirectPlugin::observe().
> Subsequent plug-ins in the chain of equal or higher 'Authority Level'
> will get to edit the Contact list through the existing
> RedirectPlugin::lookUp(). When a redirector plugin returns
> SUCCESS_SKIP, it indicates that it isn't interested in the request and
> will prevent the Contact list from inheriting its 'Authority level'.
> Under this scheme, AuthRouterPlugin will get the highest 'Authority
> Level' to ensure it always gets to lookUp() requests. Note that
> plug-ins that are observing are not allowed to suspend.
That mechanism seems to cover the bases, but a couple of points of
clarification:
* It seems to me that the authority level of each plugin needs to
be a configuration parameter of the redirect server itself (as
opposed to a parameter of the plugin). There is no need for the
plugin to be aware of its own authority value (it will of course
know which interface is being called, so it will know how it
relates to any 'upstream' redirectors). It's not clear from
your text that this is what you meant (but nothing seems to me
to contradict it).
* I think the return code names need some tweaking to make clear
what they mean. I think I'd like to see a complete list of
return codes and a sentence for each as to what they mean.
* Is there an interaction between the suspend/resume mechanism and
the new 'no interest' (SUCCESS_SKIP) return? If a redirector
returned SUCCESS_SKIP, and some other redirector suspended, is
the SUCCESS_SKIP redirector called again when the message is
resumed?
> #3- Restrict redirector plug-ins capabilities to redirection only:
> Currently, the redirect plugins have full access to SIP Responses which
> would in theory allow them to do much more than just perform look-ups
> which opens the door for misuse and abuse. In order to limit redirector
> capabilities to look-ups only, the lookUp() will no longer supply a
> response SipMessage and will instead pass a editable Contact List that
> the redirect server will add to the 302 response upon success.
Much better.
> General notes: The suspension and cancellation mechanisms in place in
> the current implementation will be carried forward under this new
> proposal.
>
> Thank you for reviewing this high-level proposal and providing your
> feedback. Once we can agree on an approach, I will publish a detailed
> proposal describing the new APIs.
In the form of .h files that generate good doxygen docs... ?
In another response, Dale says:
> [...] XECS-1305 seems to me to be very problematic.
>
> The original redirector interface was designed with the idea that the
> various redirectors each, independently, looked at the request-URI to
> produce contacts, and the resulting set of contacts was made into a 302
> response. Even then, this design principle was violated (in how
> fallbackrules were handled, in the exstence of "post-processor"
> redirectors, and in the fact that a redirector could return an error
> that overrides all other redirectors). But this principle is the sort
> of thing that improves software architecture, as it allows redirectors
> and their effects to be discussed without having to always reference the
> order in which they are executed.
>
> But XECS-1305 seems to entirely abandon the idea that redirectors are
> independent of each other, and that their order of execution does not
> matter.
>
> There seems to be at least two ways out of this conflict:
>
> 1) Re-assess whether there is any requirement for XECS-1305. I notice
> that no use cases are provided for XECS-1305 -- perhaps this
> functionality is not really required to solve the ultimate problem?
Mea Culpa... I filed the issue and didn't put in nearly as much of the
'why' as I should have (slap self on the wrist).
The idea is that most redirectors should be able to be simple - they
should just look at the request uri and see if they have a routing for
it. However, we have some cases in which redirectors look at other
parts of the request and find things that override the routing.
The current examples of this are implemented as a separate feature in
sipXproxy through the forwardingrules mechanism. My goal is to
eliminate that as a proxy feature and do all routing decisions in
redirectors.
One example of such a usage would be a redirector that takes a (partial)
request:
SUBSCRIBE sip:[EMAIL PROTECTED]
Event: foobar
and redirects it to a sipXecs service that mediates access to and
aggregates subscriptions for all 'foobar' events from any user in our
domain (example.com). Now it is (in theory) true that all other
redirectors could be required to _not_ route such a request, but my
preference is that a redirector should be able to be very simple: look
at the address, write contacts.
> 2) Add constraints to the redirectors that enable the sort of operations
> that are envisioned, without making the outcome dependent on the order
> of operations. For instance, if a redirector gives an "authoritative
> response" for a URI, we might require as a validity constraint on the
> overall configuration that no other redirector will provide any contacts
> for that URI.
I have difficulty visualizing how we could (in a reasonable amount of
time) create any programatic enforcement of such a restriction. We
haven't even been able to justify the time to create a tool to display
how a given message would be routed in a particular dial plan, which is
a small subset of a real validation. Basing the design on a restriction
we can't test for doesn't seem practical.
When it comes time to implement whatever we agree on for this, we should
carefully think through what gets logged regarding the actions taken by
each redirector, and at what log levels, so that there is sufficient
data available to debug a poor configuration.
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
