Added enable_register_publish parameter to enable REGISTER and PUBLISH method for topos If set to 1 REGISTER and PUBLISH will be enabled for topos Currently only via header will be applied for topos and if mask_callid is set to 1 call-ID will be masked. Other headers should be manged by the user as required.
<!-- Kamailio Pull Request Template -->
<!-- IMPORTANT: - for detailed contributing guidelines, read: https://github.com/kamailio/kamailio/blob/master/.github/CONTRIBUTING.md - pull requests must be done to master branch, unless they are backports of fixes from master branch to a stable branch - backports to stable branches must be done with 'git cherry-pick -x ...' - code is contributed under BSD for core and main components (tm, sl, auth, tls) - code is contributed GPLv2 or a compatible license for the other components - GPL code is contributed with OpenSSL licensing exception -->
#### Pre-Submission Checklist <!-- Go over all points below, and after creating the PR, tick all the checkboxes that apply --> <!-- All points should be verified, otherwise, read the CONTRIBUTING guidelines from above--> <!-- If you're unsure about any of these, don't hesitate to ask on sr-dev mailing list --> - [x] Commit message has the format required by CONTRIBUTING guide - [x] Commits are split per component (core, individual modules, libs, utils, ...) - [ ] Each component has a single commit (if not, squash them into one commit) - [ ] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated)
#### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality)
#### Checklist: <!-- Go over all points below, and after creating the PR, tick the checkboxes that apply --> - [ ] PR should be backported to stable branches - [ ] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description <!-- Describe your changes in detail -->
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/3766
-- Commit Summary --
* add enable_register_publish
-- File Changes --
M src/modules/topos/topos_mod.c (2) M src/modules/topos/tps_msg.c (132) M src/modules/topos/tps_msg.h (2) M src/modules/topos/tps_storage.c (6)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/3766.patch https://github.com/kamailio/kamailio/pull/3766.diff
@toharish pushed 1 commit.
56bfbdfa659f7bc33ecafa35217cd3861f6451a3 Update tps_msg.c
@toharish pushed 1 commit.
1ba8444c45698d2e5d7944d8597abc5af17b80d9 Update tps_storage.c
@toharish pushed 1 commit.
9769806b96148a2ede4612605c6d4af047c137f7 topos:Update tps_msg.c
From description I understand that only Via is removed for REGISTER (and PUBLISH). The Contact stays the same, in that case Path still has to be used in order to get the traffic back to topos-instance. Also, the incoming Path headers are kept. Is it right?
Interested in that one, as I by chance have an immediate need for it. Will test it today.
From description I understand that only Via is removed for REGISTER (and PUBLISH). The Contact stays the same, in that case Path still has to be used in order to get the traffic back to topos-instance. Also, the incoming Path headers are kept. Is it right?
Yes, Via and Call-ID mask is done in this pull request, other headers can be managed in kamailio native script/ksr as per the end user requirement. Registration will have the location information and authentication information, hence it needs to be handled as per requirement.
I tested it for REGISTER, and it seems to break if the registrar sends e.g. a 4xx with no contact back, causing the log line
``` ERROR: topos [tps_storage.c:1407]: tps_db_load_dialog(): invalid dlg uuid provided ```
Is this something you've experienced, @toharish ?
I tested it for REGISTER, and it seems to break if the registrar sends e.g. a 4xx with no contact back, causing the log line
ERROR: topos [tps_storage.c:1407]: tps_db_load_dialog(): invalid dlg uuid providedIs this something you've experienced, @toharish ?
Thinking of it: if the Contact is not handled by topos, where is the lookup key `cparam_name` stored? Could it be that this only works with `contact_mode=2`? If so, could you please provide a full example to reprooduce it?
I tested it for REGISTER, and it seems to break if the registrar sends e.g. a 4xx with no contact back, causing the log line
ERROR: topos [tps_storage.c:1407]: tps_db_load_dialog(): invalid dlg uuid providedIs this something you've experienced, @toharish ?
Thinking of it: if the Contact is not handled by topos, where is the lookup key `cparam_name` stored? Could it be that this only works with `contact_mode=2`? If so, could you please provide a full example to reprooduce it?
ERROR: topos [tps_storage.c:1407]: tps_db_load_dialog(): invalid dlg uuid provided ,This error was noticed before the last commit [9769806]. After this update it was fine. I have tested with more than 135000 active registrations and many failures.
I have used contact_mode=1. In this case contact is stored but not replaced. This can be further worked out to replace the contact, however I felt it may vary based on the user requirement, hence it was left to the users to modify it in the kamailio script as required.
ERROR: topos [tps_storage.c:1407]: tps_db_load_dialog(): invalid dlg uuid provided ,This error was noticed before the last commit [[9769806](https://github.com/kamailio/kamailio/commit/9769806b96148a2ede4612605c6d4af0...)]. After this update it was fine. I have tested with more than 135000 active registrations and many failures.
I'm also getting this with your latest commit. Do you have a bare minimum config that works for you, so I can verify?
Also, I've tested with contact_mode=1 too, but for an INVITE, topos adds a `tps=btpsh-xxxx`, do you do this manually?
ERROR: topos [tps_storage.c:1407]: tps_db_load_dialog(): invalid dlg uuid provided ,This error was noticed before the last commit [[9769806](https://github.com/kamailio/kamailio/commit/9769806b96148a2ede4612605c6d4af0...)]. After this update it was fine. I have tested with more than 135000 active registrations and many failures.
I'm also getting this with your latest commit. Do you have a bare minimum config that works for you, so I can verify?
Also, I've tested with contact_mode=1 too, but for an INVITE, topos adds a `tps=btpsh-xxxx`, do you do this manually?
It is not required to add btph/atph to contact as Registration will not create a Dialog for another Indialog Method will not be orginated with this contact. For registration no change is done in the contact field by Topos.
modparam("topoh", "mask_key", "THIS_IS_TEST_KEY") modparam("topoh", "mask_callid", 1) modparam("topoh", "callid_prefix", "TXX") modparam("topoh", "use_mode", 1)
modparam("topos", "storage", "redis") modparam("topos_redis", "serverid", "tps")
modparam("topos", "contact_mode", 1) modparam("topos", "rr_update", 1) modparam("topos", "contact_host", EXTIP )
modparam("topos", "mask_callid", 1) modparam("topos", "enable_register_publish",1) This works perfectly for me, where TOPOS hide Via and mask Call-ID. Form. To and Requst URI chages as done manually/ through Dispatcher ds_select_domaincall in dispatcher.
ERROR: topos [tps_storage.c:1407]: tps_db_load_dialog(): invalid dlg uuid provided ,This error was noticed before the last commit [[9769806](https://github.com/kamailio/kamailio/commit/9769806b96148a2ede4612605c6d4af0...)]. After this update it was fine. I have tested with more than 135000 active registrations and many failures.
I'm also getting this with your latest commit. Do you have a bare minimum config that works for you, so I can verify? Also, I've tested with contact_mode=1 too, but for an INVITE, topos adds a `tps=btpsh-xxxx`, do you do this manually?
It is not required to add btph/atph to contact as Registration will not create a Dialog for another Indialog Method will not be orginated with this contact. For registration no change is done in the contact field by Topos.
modparam("topoh", "mask_key", "THIS_IS_TEST_KEY") modparam("topoh", "mask_callid", 1) modparam("topoh", "callid_prefix", "TXX") modparam("topoh", "use_mode", 1)
modparam("topos", "storage", "redis") modparam("topos_redis", "serverid", "tps")
modparam("topos", "contact_mode", 1) modparam("topos", "rr_update", 1) modparam("topos", "contact_host", EXTIP )
modparam("topos", "mask_callid", 1) modparam("topos", "enable_register_publish",1) This works perfectly for me, where TOPOS hide Via and mask Call-ID. Form. To and Requst URI chages as done manually/ through Dispatcher ds_select_domaincall in dispatcher.
@agranig any updates form you testing
@toharish pushed 1 commit.
86402aee2f1730922000902e15a095b54c5a6b4d Update tps_msg.c
This PR is stale because it has been open 6 weeks with no activity. Remove stale label or comment or this will be closed in 2 weeks.
Closed #3766.
Reopened #3766.
@toharish do you still like to get this merged? Not sure what the last result from your testing discussion was.
Would love to get this merged, but didn't succeed testing it successfully on my machine. Maybe I did something wrong? A second pair of eyes would be highly appreciated.
Would love to get this merged, but didn't succeed testing it successfully on my machine. Maybe I did something wrong? A second pair of eyes would be highly appreciated.
Yes for sure one more round of check will be good so that anything missed out can be checked. But for my Application I am using for REGISTER with call-ID mask and it works perfectly and its more than 8 months working with more than 160000 registrations
This PR is stale because it has been open 6 weeks with no activity. Remove stale label or comment or this will be closed in 2 weeks.
Any update regarding the tests from @agranig or somebody else?
This PR is stale because it has been open 6 weeks with no activity. Remove stale label or comment or this will be closed in 2 weeks.
Closed #3766.
Reopened #3766.
This PR is stale because it has been open 6 weeks with no activity. Remove stale label or comment or this will be closed in 2 weeks.
@agranig pushed 1 commit.
fa53a6da06a8210e7233fccc1f3524472e429248 Merge branch 'master' into enable_register_publish-parameter
Trying to get this tested based on latest master.
@agranig pushed 1 commit.
bc1da947930feba1ca3a3fc95a3bfd10e0f37ab0 topos: fix code formatting
@agranig pushed 1 commit.
31f207f152f42071374c6e795f7854f0ad6f7fa7 add enable_register_publish
@agranig pushed 1 commit.
891517365dcb31f9e360bc88deb6cb5a839b3f1a topos: add enable_register_publish modparam
@agranig pushed 1 commit.
fa08d737e6568f83eb880d9c14dbff4640b6613d topos: add enable_register_publish modparam
Tried to clean it up and rebase on top of current master and fix some code indentation etc.
However, it doesn't seem to work as expected to me.
What works: [x] Hiding Via header
What doesn't: [ ] Contact hiding [ ] No typos key param added to Contact, so the 401 is not rewritten back (regarding Via) and Kamailio doesn't know where to send the response to
@toharish could you please post an example of a REGISTER leaving Kamailio, so we can check what's supposed to be hidden?
@agranig pushed 1 commit.
6f4a19f110f6f7761663689168164ba234b8f265 Merge branch 'master' into enable_register_publish-parameter
Tried to clean it up and rebase on top of current master and fix some code indentation etc.
However, it doesn't seem to work as expected to me.
What works: [x] Hiding Via header
What doesn't: [ ] Contact hiding [ ] No typos key param added to Contact, so the 401 is not rewritten back (regarding Via) and Kamailio doesn't know where to send the response to
@toharish could you please post an example of a REGISTER leaving Kamailio, so we can check what's supposed to be hidden?
[reg1.txt](https://github.com/user-attachments/files/17831070/reg1.txt)
@agranig I have attached the working SIP trace when this module is used. I am able to send 401 properly to the orginator without any addtional configuration in this PR I had planned only change of CALLID and hide via, If required we can plan for contact with topos key. Since there is no indialog messages in registration I feel that topos key may not be required.
The key will be required because when you register and rewrite the Contact, you have to handle the R-URI for inbound new requests (INVITES for instance) too. So a REGISTER needs to be handled pretty much the same way as a dialog-forming request such as an INVITE.
I'm currently looking into some ways to handle this generically.
The key will be required because when you register and rewrite the Contact, you have to handle the R-URI for inbound new requests (INVITES for instance) too. So a REGISTER needs to be handled pretty much the same way as a dialog-forming request such as an INVITE.
I'm currently looking into some ways to handle this generically.
@agranig You are right this will be topos key is required when we rewrite the contact. But in this PR I have not changed the contact. Contact changes can also be done locally from the script by saving AoR and location information in redis. The Idea behind this PR was to change via and Call-ID which cannot be directly changed from the script. Contact rewrite, request uri rewrite etc.. from this module can be done in differenet PR.
There are currently some conflicts that prevents a merge of this PR. I am also not sure whats the status of this extension is, if there are still necessary changes. As the 6.0 release is scheduled for middle of next week, maybe you can give an update if this is ready or need more time.
github-actions[bot] left a comment (kamailio/kamailio#3766)
This PR is stale because it has been open 6 weeks with no activity. Remove stale label or comment or this will be closed in 2 weeks.
Closed #3766.
-
Andreas Granig -
Daniel-Constantin Mierla
-
github-actions[bot]
-
Harish S
-
Henning Westerholt