On Mon, 2008-09-29 at 14:31 -0400, Dale Worley wrote:
> On Thu, 2008-09-25 at 10:16 -0400, Scott Lawrence wrote:
> > 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.
>
> OK, so far, so good.
>
> Where I'm coming from is a fear that we're going to let the redirector
> system degenerate into an entirely unstructured system, where each
> redirector performs arbitrary editing of the list, and the overall
> effect can only be determined by simulating the execution of each
> redirector.
>
> It's true that giving each redirector the ability to arbitrarily edit
> the contact list makes it possible to solve any problem, this is like
> saying that you can implement any control-flow with GOTO. Control-flows
> that are implemented with GOTO are fragile. Worse, with GOTO you don't
> have to think through the overall design of what you're doing, you can
> just say "At this point, the next thing to do is X" and insert a GOTO X.
> With "structured programming", you have to get your conceptual model of
> the code straight before you can write the code.
>
> And we already have examples of redirectors that interact with other
> redirectors in a conceptually incorrect manner (because that was the
> expedient way to solve the problem at hand). I fear that if the
> redirector interface allows more arbitrary behavior, people will write
> redirectors that do arbitrary behavior.
I think that Roberts proposal actually narrows what a redirector can do
(except in that it allows more specific and useful error responses than
the existing behavior does).
> > 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.
>
> Now this makes my skin crawl. Not because of what you've said, but what
> you've not said, which is how this redirector relates to the others. I
> *think* what you mean is "We want a redirector that notices messages
> with method SUBSCRIBE, Event foobar, and our request-URI domain, and it
> will provide a contact. And other redirectors should not provide
> contacts for it."
>
> Now, are rules of this sort sufficient to implement everything you want?
> What sorts of patterns of "which redirector dominates which" are
> sufficient? Do all redirectors need to have a pecking order, or are
> there only certain groups that interact? Do we really need all the
> interactions we now have?
>
> Also, how is this alleged sipXecs service going to send SUBSCRIBEs to
> the real targets?
I sympathize with your discomfort, but let's be practical here... there
is a very very important point to be understood:
We already have all the unhygienic things you're afraid of. We
have mechanisms that route based on method and event and the
redirectors never see them; we have redirectors that modify
contacts added by other redirectors. We already must carefully
and manually ensure that redirectors are configured in the
correct order.
We do not have the alternative available of going back and getting rid
of those possibilities - our only choices are to make the mechanisms
incrementally better.
The goal here is, in part, to enable us to combine the functionality
currently in two different places in the system (forwardingrules and
redirectors) into one uniform mechanism (no, we won't make that change
this release, but we're laying the groundwork for it because we don't
want to redefine the interface again soon, and this is a major version
bump so it's a good time).
Roberts proposal actually goes further than I had originally asked for
by limiting what a redirector can do to the response message - it can
now either specify an error or manipulate the contacts, but it can't
change other parts of the response (and there are some seriously ugly
possibilities there now - fortunately, we have resisted using them, but
the possibilities exist).
> > > 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 don't have to enforce the restriction. But there are times where it
> is quite useful to simply document as part of an interface "any
> component must satisfy restrictions X, Y, and Z for the overall system
> to work correctly". As a trivial example, we require that all
> redirectors finish executing when they are called, and that is
> fundamentally unenforcable! But more realistically, even now we require
> that a redirector will return the same results when called multiple
> times on the same request.
I have no problem with documenting restrictions on what a redirector is
allowed to do.
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
