On Thu, 2008-09-18 at 16:17 -0400, Joly, Robert (CAR:9D30) wrote: > > 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.
I'd still like to see a use case for XECS-1305. > > 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". My attitude is that if one would have to add code to one redirector to consider what another redirector has done, one has made a mistake in the design. E.g., all redirectors implicitly act only on certain user-parts, and if one redirector requires that another redirector not act on a particular user-part, those redirectors should have syntactically distinct sets of user-parts that they act on. One curious aspect of these issues is that the current design allows a redirector to declare an error for a particular request, which perforce takes precedence over any contacts that other redirectors have provided. Currently, the only redirectors which can produce errors are ones which we have designed to not overlap in user-parts with any other redirectors. In regard to the current proposal, I think some details are omitted. I see this text: > When a redirector plugin returns SUCCESS_LOOKUP_DONE, the RedirectServer > will tag the entire Contact list with the Authority Level of the > plug-in. But to make this work as intended, it seems that the redirector framework needs to delete any other contacts added by a lower-authority-level 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
