Add support for multiple request matching strategies when processing NOTIFY requests #24
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit introduces a concept of a request processing strategy, which is evaluated against the incoming request. This (collection of) strateg(y/ies) provides a determination mechanism of a request being processed by a SipSession or its children. Thus a user may provide extensions to the SipSession on which inbound requests may be accepted without the need to mutate any parameters, or request event processing mechanisms in SipPhone This is a derivation of the request matcher, allowing for a more flexible implementation.
In order to support extensible request handling, we introduce the RequestProcessor class, which is tasked with executing a sequence of strategies over an inbound request for a SipListener instance. These strategies execute sequentially until one of the strategies accepts the request. If no strategies were executed or the validation fails, the governing SipPhone will return an appropriate error (which indicates that either the event was not recognized or the subscription was orphaned).
teles-mami
changed the title
|
@jaimecasero this one is also up for review ;) |
teles-mami
commented
Jan 25, 2018
| * | ||
| * @see RequestProcessor | ||
| */ | ||
| public class RequestProcessingResult { |
There was a problem hiding this comment.
Thinking about converting this to an enum, because the double boolean tautology may confuse the implementing user of the strategies
There was a problem hiding this comment.
After further analysis, we will need this form for the event processing logic.
Specifically in "presence" event processing, we will have successful (orphaned) events which will be processed later on, but not in the current handler.
Leaving the logic as-is.
|
Also like the other PR, |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The SipPhone class has a specific flow for processing NOTIFY requests:
validate request -> process if event is (conference | refer | presence | send bad request) -> else orphaned event error (call or transaction does not exist).
This flow is hard to intercept and extend via inheritance without actually copy-pasting code from the SipPhone itself. In order to avoid cumbersome inheritance of SipPhone for NOTIFY request processing, we introduce the conctept of executable NOTIFY processing strategies, which will determine if a request belongs to one of the registered EventSubscriber classes (which are not so difficultly inherited).
Thus we take inspiration from the request handling strategy solution and introduce strategies which will allow to further the spectrum of event packages which the SipPhone supports.
This pull request does NOT provide extended set of event packages, and does not address the issue of coupling of EventSubscriber with the SipPhone parent. It is a prelude and a gateway to the end user/tester to provide their own solutions and customized event handling without actually inheriting the SipPhone itself.
Related issue