Transaction only topology_hiding enhancements#3908
Open
davidtrihy-genesys wants to merge 8 commits into
Open
Conversation
No functionality changes just refactor for ease of diff viewing
b1ae973 to
0d8947c
Compare
This file contains hidden or 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
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.
Summary
Additional features to the topology_hiding module in transaction only mode.
Details
A strong effort was made to not alter dialog topology_hiding functionality and only target transaction functionality but there was a refactor done to separate the logic as the transaction aware logic grew in size due to the changes so a lot of the common code was refactored into separate source files to make development easier and additional functionality that could be common was added to those same files
75ff8a6bdd87466f44a5c8dbeac417cf82493ae4the idea is to show that there is no functionality change that would affect the dialog aware module44b86215d8bc06137e4e7a44ad549f645576d21bac6d588b96741d6aaf6597528b56d2abc6462889bbba1f626f1478a040e947ef246da9bd66656ba3The major logic rework is part of this commit here
11783c1c4faa561541e7b0e26ee4bffa9adb88a0this is where the bulk of the work was done to support the new model of topology_hiding there are other smaller commits too but these ones give the bulk of changes.Once the modparam name and scheme has been agreed upon the documentation can be added in another commit before merged the PR
Socket tag matching
Purpose of these tags is to define the sockets that will be used for topology hiding, internal is when the request comes in and the socket is switched, it will allow the topology_hiding to be engaged but also not strip topology information for requests and only for responses, the inverse applies for requests initiated from internal.
External is purely for failover scenarios, in this case if you don't have a DNS advertised for your internal socket and that instance fails, you can do some script initiated failover to another instance that may have the same IP address but has the same tag and it should be able to decode the socket information using the tags to match the information as opposed to IP addresses
If this tag is not set then failover will not work in this scenario, this only affects the auto_route
auto route modparam
This modparam is purely to generate an auto route on the trusted internal socket when one way hiding is engaged due to no Contact header update, the script writer can turn it off and choose to do sequential requests in the script
param encoding and password
Allows for setting the param name, password and encoding type and choosing which one to use when doing topology_hiding will allow two definitions and supports password rotation
Solution
The solution has some limitations that could be addressed in future with modparams but I don't think it's entirely necessary for now
These listed limitations only really apply to the new encoding type and the target usage of this algorithm is in the one way hiding mode of operation which the script writer should be aware of the internal SIP message Routes and Contact headers so they should be aware of the limitations, in any case I plan to address them in a follow up PR
Compatibility
Retains full backwards compatibility with the current mode of operation, will link the suite of sipssert tests written when PR is open.