Starting this issue to collect suggestions about what should be adjusted in the default config or options (global or module parameters) in preparation for Kamailio 5.4.0. The goal is not to recreate a completely new config, the current one being a good starting point for new deployments, but to tune its parameters with what people consider useful to have based on experiences encountered lately.
Compared with 5.3, there are already:
* replaced XMLRPC with JSONRPC * option to use RTPEngine instead of RTPProxy
Other proposals I would do:
* enable path support by default in registrar/usrloc modules - it is disabled by default, a modparam needs to be set, but if set and no PATH header, then there is no effect. I met couple of cases when a Kamailio proxy was added in front of other Kamailio (usually coming as part of a PBX) and Path is not enabled there. * set timer_procs for usrloc - as deployments grow with the population of registered endpoints, core time can be affected by scanning expired registrations * load textopsx module and try to provide an example of using msg_apply_changes() probably within some `ifdef` - aiming to help new comers spot that changes as are immediately visible
Listing now, but to have in mind for other future releases, because the code is young in 5.4: * keepalive to be done with usrloc module to get round trip timer, etc *dlgs module loaded to see the basic stats about active calls - useful to help deciding when to do a restart or a maintenance shut down, even if it may not be 100% accurate if done after another restart (because there is no persistence, at least now), currently the stats being more or less in the fashion of active transaction stats
+1 for path support by default
Some other random preliminary thoughts: * Is there any reason for NATDETECT to precede retransmission processing? Also, AFAIK Contact header is not (normally?) present in CANCELs so it doesn't need to precede CANCEL processing either. If my hypotheses are correct, moving it after retransmission checks could save a few processing cycles? * If I'm not mistaken, the default kamailio configuration will always reject auths for methods where From can be set to anonymous. Perhaps it would make sense to enable bit 2 in the flags for auth_check, or provide a commented line with the option for the deployer to enable at will. * Provide a preprocessor-style option to instruct rtpengine and/or rtpproxy to engage for all calls, regardless of nat detection. This might overcomplicate things a little, however. * For stateless replies in REQINIT, document that force_rport() might have to be called, since these are sent out before the NATDETECT route * In the NATDETECT route, force_rport() is set unconditionally if nat is enabled in the configuration. Is there any reason for this? Wouldn't it make more sense for force_rport() to be run only if the nat tests indicate that a request has been NATted?
How about `systemdops` module loading by default via `/etc/kamailio/kamailio.cfg`?
Looks as most of the supported dists use `systemd`. Except Alpine. For Alpine I will disable this module loading.
Given that Prometheus is becoming quite common as a timeseries backend, what do you think about conditionally (#!ifdef) loading xhttp_prom module?
Do not forget that we have also the advanced (oob) and basic configs in `misc/examples/pkg/`, which were supposed to be installed in the shared docs (they were relocated from `etc/`, not sure we got to packaging them).
I am fine to add the systemd and prometeus to the advanced config, but for the default kamailio.cfg I think we should focus on tuning its parameters for core and loaded parameters. It still should aim to be a good but still simple starting point, without many dependencies of external projects/applications.
@gedia - SIP allows asymmetric singling (end point wanting the reply back to another address than where it sent the request from), force_rport() is normally needed when you know it is not the case, typically for natted devices. So it makes sense to have rport even in reqinit for natted cases. Anonymous calling is typically for PSTN calling, which can be more complex processing requiring P-Asserted-Identity and Privacy headers -- it can be also a candidate for advanced config version.
@miconda Regarding force_rport(), the point I was making was exactly that it does NOT engage in REQINIT, even if WITH_NAT is enabled. For example, replies to OPTIONS sent to kami will always be directed to address in first Via header even for NATted devices, even with NAT support enabled in the configuration. Perhaps it would make sense to point this out in comments or provide a fix when WITH_NAT is defined.
On an unrelated note, also consider the following: debug is by default either 4 or 2, depending on whether WITH_DEBUG is defined. AFAIK, log level 4 no longer exists, so consider changing this to 3 or 1 respectively (or 3/0, since level 0 is the default if not explicitly set).
@gedia - yes, I agreed with your remark about force_port(), if that was not clear. The debug=4 was inherited from openser times when it was a valid value, after merging core from SER project, the values shifted back with 1. Can be changed now to 3 and 2.
I pushed the updated config, here are the comments of the commit (referenced above):
- use force_rport() at the beginning of processing requests, note added in the top comments to inform that config performs symmetric signaling - load textopsx module and added define option to apply changes before presence handling, so changes to headers or body are visible to presence functions - modparams to enable use of Path for registrar module - modparam timer_procs for usrloc module - a bit of refactoring for debug mode, level being set by a defined token and log_stderror is set always to no, so even with higher debug level logs are sent to syslog (added comment how to enable it via setting value to 'yes' or using -E cli option) - updated notes for debug mode and listen param
As more and more installation requires dual-stack installation (IPv4 and IPv6). So I suggest enabling `auto_bind_ipv6=1`.
If this not acceptable, then add this option as comment near of `listen` directive.
Closed #2381.
@sergey-safarov - commented in the other issue you opened. This one is closed with 5.4 being branched.
-
Daniel-Constantin Mierla -
Federico Cabiddu
-
George Diamantopoulos
-
sergey-safarov