Hi Daniel,
good tip about the crypto module.
It will indeed hide the IP address in the call-id, just tried it:
Call-ID: d810d369-aa60-4d79-aee5-9c03d2e66781
I think if we would feed the sruid unique ID (in libs/srutils) into the SHA256 hash (also available there) this it should be secure enough without the crypto dependencies.
The sruid is based on a LSFR implementation which is quite fast, and the SHA256 should provide the necessary unpredictability.
But as the crypto module approach works, it has probably not a really high priority. I can also look a bit into it when I got time.
Cheers,
Henning
Am 14.08.19 um 19:21 schrieb Daniel-Constantin Mierla:
Hello,
using the ip in call-id is not a good practice imo, I had it in mind to replace it properly everywhere for quite some time -- actually at this moment there is an option that can be activated in the crypto module making the call-id to be generated with libssl unique id generation functions, but I don't recall if the local ip is still appended. This would require libssl, so my goal was to add an alternative to generate a "good-enough" unique id, without external dependencies, to be used as local call-id.
Cheers,
Daniel
On 14.08.19 19:01, Joel Serrano wrote:
Hello Henning,
No concerns at all!! As you say, the Call-ID can really say whatever... The only concern could/would be in the security topic that you are disclosing potential sensible information about your infrastructure blablabla... but that can be solved just by changing the listen= order so even that wouldn't be a problem.. In reality I was just curious so I thought I'd ask :)
Thanks!!
Joel.
On Wed, Aug 14, 2019 at 9:32 AM Henning Westerholt <hw(a)skalatan.de<mailto:hw@skalatan.de>> wrote:
Hello Joel,
funny - I just had this discussion about the same topic some days ago.
In the end this is "only" the call-id, the IP should not be used to to routing descisions etc.. Do you have some more concerns about this?
I think as well it just uses the first IP. I think at the moment the call-id is generated internally from tm, but this could be of course changed for the module with some coding/extension.
Cheers,
Henning
Am 14.08.19 um 17:12 schrieb Joel Serrano:
Hello,
Simple doubt regarding dispatcher module when you have the ds_default_socket() modparam set:
Say you have 2 kamailio boxes, active + passive, one shared IP via keepalived.... On the actrive node, you have dispatcher.send_ping to 1, and the passive has it set to 0.
So far OK, only the active box is sending out probing OPTIONS requests, and it's using as outbound socket the virtual IP out of all the available ones (as defined with ds_default_socket() modparam)
I have seen in a capture that the outbound OPTIONS look like:
OPTIONS sip:190.14.203.219:5060<http://190.14.203.219:5060> SIP/2.0
Via: SIP/2.0/UDP A.B.C.180;branch=z9hG4bK7abb.6fbaccc1000000000000000000000000.0
To: <sip:190.14.203.219:5060<http://190.14.203.219:5060>>
From: <sip:dspinger@my.domain><mailto:sip:dspinger@my.domain>;tag=e2bdd495733c59fd91487a137fccad4e-8a73
CSeq: 10 OPTIONS
Call-ID: 2019f8491329c382-31419(a)A.B.C.181
Max-Forwards: 70
Content-Length: 0
A.B.C.180 -> VRRP
A.B.C.181 -> Physical IP of the box
My doubt is, shouldn't ds_default_socket also update the IP used to generate the Call-ID used in the OPTIONS request? Currently, I believe it's using the first defined listen= IP from config script as I switched the order the listen= are defined and I get the desired result:
OPTIONS sip:186.188.220.174:5060<http://186.188.220.174:5060> SIP/2.0
Via: SIP/2.0/UDP A.B.C.180;branch=z9hG4bKc97e.a8d9e1c2000000000000000000000000.0
To: <sip:186.188.220.174:5060<http://186.188.220.174:5060>>
From: <sip:dspinger@my.domain><mailto:sip:dspinger@my.domain>;tag=5e2e1773f812f6a7e4085c5d036e29d8-d323
CSeq: 10 OPTIONS
Call-ID: 7d9a92c218fc1ba0-32111(a)A.B.C.180
Max-Forwards: 70
Content-Length: 0
Is this expected?
Cheers,
Joel.
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://skalatan.de/services
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.com<http://www.asipto.com>
www.twitter.com/miconda<http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda<http://www.linkedin.com/in/miconda>
--
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://skalatan.de/services
The ims_usrloc_scscf module lacks module documentation in git master:
~/repositories/kamailio/src/modules/ims_usrloc_scscf> ls -la README doc*
ls: cannot access 'README': No such file or directory
ls: cannot access 'doc*': No such file or directory
The purpose of this module and also its parameters that are exported should be documented in a doc/*.xml files like the other modules. This are the exported parameters from the source code:
{"timer_interval", INT_PARAM, &timer_interval },
{"desc_time_order", INT_PARAM, &desc_time_order },
{"matching_mode", INT_PARAM, &matching_mode },
{"cseq_delay", INT_PARAM, &cseq_delay },
{"fetch_rows", INT_PARAM, &ul_fetch_rows },
{"hash_size", INT_PARAM, &ul_hash_size },
{"subs_hash_size", INT_PARAM, &subs_hash_size },
{"contacts_hash_size", INT_PARAM, &contacts_hash_size },
{"nat_bflag", INT_PARAM, &nat_bflag },
{"contact_delete_delay", INT_PARAM, &contact_delete_delay },
{"usrloc_debug_file", PARAM_STR, &usrloc_debug_file},
{"enable_debug_file", INT_PARAM, &usrloc_debug},
{"user_data_dtd", PARAM_STRING, &scscf_user_data_dtd},
{"user_data_xsd", PARAM_STRING, &scscf_user_data_xsd},
{"support_wildcardPSI", INT_PARAM, &scscf_support_wildcardPSI},
{"unreg_validity", INT_PARAM, &unreg_validity},
{"maxcontact_behaviour",INT_PARAM, &maxcontact_behaviour},
{"maxcontact", INT_PARAM, &maxcontact},
{"maxcontact_3gpp", INT_PARAM, &maxcontact_3gpp},
{"max_subscribes", INT_PARAM, &max_subscribes},
{"sub_dialog_hash_size",INT_PARAM, &sub_dialog_hash_size},
{"db_mode", INT_PARAM, &db_mode},
{"db_url", PARAM_STR, &db_url},
{"timer_procs", INT_PARAM, &ul_timer_procs},
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1644
<!-- 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, ...)
- [x] Each component has a single commit (if not, squash them into one commit)
- [x] 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
- [x] 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 -->
- [x] PR should be backported to stable branches
- [x] Tested changes locally
- [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description
<!-- Describe your changes in detail -->
ims_usrloc_scscf module documentation is added.
removed unnecessary files.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/1835
-- Commit Summary --
* ims_registrar_scscf : fixed wrong comment for emergency register
* ims_registrar_scscf: removed screensharing log file.
* ims_usrloc_scscf: removed NewFile.xml file
* ims_usrloc_scscf: doc is added
-- File Changes --
M src/modules/ims_registrar_scscf/config.c (4)
D src/modules/ims_registrar_scscf/screensharing.log (66)
D src/modules/ims_usrloc_scscf/NewFile.xml (9)
A src/modules/ims_usrloc_scscf/doc/Makefile (4)
A src/modules/ims_usrloc_scscf/doc/ims_usrloc_scscf.xml (62)
A src/modules/ims_usrloc_scscf/doc/ims_usrloc_scscf_admin.xml (340)
A src/modules/ims_usrloc_scscf/doc/ims_usrloc_scscf_faq.xml (58)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/1835.patchhttps://github.com/kamailio/kamailio/pull/1835.diff
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/1835
Hello,
Kamailio SIP Server v5.2.4 stable release is out.
This is a maintenance release of the latest stable branch, 5.2, that
includes fixes since the release of v5.2.3. There is no change to
database schema or configuration language structure that you have to do
on previous installations of v5.2.x. Deployments running previous v5.2.x
versions are strongly recommended to be upgraded to v5.2.4.
For more details about version 5.2.4 (including links and guidelines to
download the tarball or from GIT repository), visit:
* https://www.kamailio.org/w/2019/08/kamailio-v5-2-4-released/
RPM, Debian/Ubuntu packages will be available soon as well.
Many thanks to all contributing and using Kamailio!
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda