Hi, XECS-1306 is a umbrella tracker that links to XECS-476 and XECS-1305 which both call for improvements to the redirect plug-in interface. The purpose of this e-mail is to describe at a high-level the changes that I propose to handle both improvements.
Background information about requested improvements ===================================================== XECS-476 - "Redirectors that reject requests should be clearer about why" is requesting that redirector plug-ins be capable of providing a reason phrase to be added to the response to assist in the troubleshooting of problems. XECS-1305 - "Redirectors need to be able to indicate that no other redirectors should be called" is requesting that redirector plugins be capable of indicating that their response is authoritative and that no more redirectors be consulted. High-level overview of the current redirect plugin processing ============================================================= In its current implementation, the sunny day case goes like this: the redirector plugin's are called one-by-one ((lookUp()) and are responsible for editing the Contact list of the supplied response. After all the redirectors have all been called, the Redirect server is left with a Response containing a set of Contacts which are included in the 302 Moved Temporarily it sends out. The current processing also has error handling, cancellation handling and suspension handling which will not be detailed in this high-level overview. For more details, please consult http://sipxecs.sipfoundry.org/ViewVC/sipXecs/main/sipXregistry/doc/Redir ection.txt?view=markup 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). #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. #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. 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. Cheers, bob _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
