Add support for multiple request matching strategies in SipSession #22
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
The current loopback implementation was limited in the sense that it wasn't open to mutation of request matching, causing a SipPhone client to potentially miss an incoming request which did not fit either the current Request URI check or the To check by equality. This commit introduces a concept of a request matching strategy processing, which is evaluated against the incoming request. This (collection of) strateg(y/ies) provides a determination mechanism of acceptance of request into the SipSession. Thus a user may provide extensions to the SipSession on which inbound requests may be accepted without the need to mutate any parameters. To enable this behavior, some parameters accessors have been moved from SipPhone to its parent, the SipSession. The request matching mechanism deprecates the loopback accessors. However, the loopback behavior has been retrofitted with the new matching strategy mechanism (tests included for proof).
In order to follow extensibility guidelines defined in the Gang Of Four book on Design Patterns, we refactor the request matching mechanism to increase the cohesion of the SipSession object (which just queries the matching and handles that the matching is up to its business logic). The business logic of the strategy handling themselves is handled now by the request matcher, which will determine if a strategy will be added, removed or contained. To reduce coupling of the matching strategy to the SipSession, we move the sip session to be an argument of the strategy determination. This way we can represent and initialize each handler as a functional interface (for Java 8), reducing code footprint while still delegating the responsibility of request attribution to a session to the strategy itself.
The To and Request URI matching strategies are now treated as singleton strategies, permitting only one instance in the matcher. This is to improve performance and remove bugs when adding multiple same-typed strategies. If a strategy wants to be instantiated multiple times (which is default), it has to return the corresponding boolean parameter. This may be applicable in cases where a SipUnit client wants to, for example, accept multiple numbers in the To header using a same strategy class.
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. (cherry picked from commit 30dbcee)
gsaslis
requested review from
a team
and removed request for
gvagenas and
jaimecasero
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.
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.
Default processing strategy is Request URI validation, with To validation able to be added. The user may access the underlying matcher to add additional strategies in order to determine if a request is viable to be accepted.
Related issue