> I don't want to sound like a grouch, but 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.
This principle is a noble one but time has shown that it is difficult to adhere it. The hard reality is that some redirectors have direct interdependencies (mapping->fallback->huntgroup) and that all have indirect interdependencies (for example, creating a dialplan that uses call pickup code as a prefix will yield different results depending on the order of redirectors). Given that this principle does not exist in actual fact, I would be hesitant to judge a proposal on the grounds that it does not abide by it. Having said that, I agree that a proposal should not unnecessarily make redirector interdependencies worse. > > 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? Scott has a much more comprehensive view of the trajectory of redirector plugins than I do so I will let him field that question but it is a very legitimate one. > > 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 think that the main goal of the original plug-in interface was to limit the interactions between plug-ins in such a way that it would theoretically be possible for someone to implement a new plug-in independently without having to concern itself with the existing plug-ins. I think that approach #2 you describe above also abandons that idea. If I understand correctly, when adding a plug-in, one may have to code logic that will ensure that it will not produce a Contact for a given URI if another existing plug-in is known to produce one. Building the code that will make that determination requires knowledge of all other plug-ins and/or their configuration hence introducing interdependencies, does it not? Besides causing interdependencies, I think that this principle would also be difficult to adhere to and to enforce in each plug-in. I guess that the first violator of that principle would be authrouter plugin which needs to go in and modify every "authoritative responses". > > >From a theoretical point of view, choice 2 means that we still don't > have to worry about the order of execution of redirectors, > even with "authoritative responses". From a practical point > of view, we can omit the "authority level" machinery > entirely, because the code knows that when a redirector > declares its response authoritative, no contacts will have > come from any other redirector. > > 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
