> 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 we are in agreement that the authority level of a given plug-in will not be chosen by the plug-in in question. Instead, the authority level of a plug-in would be a configured attribute much like its instance number. The RedirectServer would learn it from the configDb somehow but I haven't yet put much thought into the actual mechanism. If and when we can agree that authority levels are a 'go', I'll spend some cycles to come up with a proposal. > > * 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. I agree the return codes should be improved upon. Let me take another crack at it. The descriptions I provide below explain what each return code means from the point-of-view of the redirector plugin (i.e. represents what would be found in the interface comments). As a result, it does not discuss the whole business of 'authority level' since this is a concern for the RedirtectServer and not the plug-ins themselves. SUCCESS_LOOKUP_DONE = the request was of interest to the redirector and it asserts that the content of the returned Contact list meets its requirements. LOOKUP_SUCCESS_SKIPPED = the request was of no interest to the redirector and as a result did not modify in any way the content of the returned Contact list. LOOKUP_ERROR = the redirector reported an error. The passed ErrorDescriptor may be used to customize how that error will be communicated back to the originator via a SIP response LOOKUP_SUSPEND = the redirector needs the request to be suspended for asynchronous processing. > > * 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? The way the suspension mechanism works today is as follows. If you have a chain of 10 plugins and plugin #5 suspends, when it resumes all the plug-ins are re-executed. This comes from the fact that the suspension mechanism does not have a means (today) of remembering the state of the Contact list when the suspension occurred. All the plug-ins are re-consulted to effectively reconstruct the response up to the suspension point. Now, in keeping with the example, I understand that if either plugins 1,2,3 or 4 returns SUCCESS_SKIP, they do not play a role in the response reconstruction and as a result, they could be optimized out. However, implementing such an optimization would require that we 'remember' which plugins skipped. IMO, coding such an optimization is not time well spent for two reasons: #1- many plug-ins that SKIP will likely realize rapidly that they are not interested in the request, i.e. they are not big CPU consumers; #2- If we do any work 'remembering' anything, I would say that it should be towards remembering the collected Contact list at the point of suspension so that we can avoid reconsulting all plugins that are upstream of the suspension point (plug-ins 1 to 4 in my example). This is where we get the biggest bang for the buck. Having said all that, I realize that I only indirectly responded to your question. The direct and short answer is: Yes. > > #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... ? Sure. <snip - the rest if for Dale to address> _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
