Having (optional) support for socket activation in Kamailio would bring several benefits:
* Security: systemd can listen on privileged ports or socket paths and start Kamailio with privileges already dropped.
* Major upgrades or reconfigurations of Kamailio requiring a full restart are possible without having the listening socket(s) ever go away.
* Any service dependent on Kamailio doesn't have to wait for it to finish starting (or start at all).
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/293
It seems a good idea to support JWT as a new SIP authorization method. Wonder if anyone is interested? Think auth_db would be the best spot to add support for JWT.
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/29
We have avp_copy on avpops module but we don’t have anything to copy xavps.
```
// copy all the content of an avp to a xavp
$xavp(a[0]=>b) = $(avp(x)[*]);
// deleting left content
$xavp(a[0]=>b[*]) = $(avp(x)[*]);
// copy xavp to a xavp with index
$xavp(a[0]) = $xavp(b[1]);
// all
$xavp(a[*]) = $xavp(b[*]);
// copy all content of a xavp to a avp
$avp(x) = $xavp(a[0]=>b[*]);
```
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/7
If I enable dialog module Kamailio will fail to start with following error:
ERROR: dialog [dialog.c:498]: mod_init(): no dlg flag set!!
In the documentation this parameter is set to 4 as an example:
modparam("dialog", "dlg_flag", 4)
But no comments made as to why number 4 is used, which numbers are possible to use and most importantly - why such default value is chosen?
In any case - module should use default which does not break server's configuration.
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/372
(Feature request)
be able to recover data from htable variable when kamailio starts, from another kamailio instances through dmq module.
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/260
repro servers peer with each other in a federated manner just like SMTP servers for email, but using TLS mutual authentication to prevent impersonation.
Kamailio has TLS support and should be able to talk to such servers and other Kamailio servers in the same way.
It would be good to create a recommended sample configuration for this type of service and also add it to the RTC Quick Start Guide:
http://rtcquickstart.org/guide/multi/sip-proxy.html
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/531
OpenSSL is well known for huge amount of deadly security vulnerabilities, even before heartbleed.
It would be nice if I could avoid bringing in such a library just because of Kamailio - having support for GnuTLS will let the user to make such a choice.
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/371
If I run set_contact_alias nothing happens - the contact remains the same on the outbound message There's no error returned and debug logs indicate a proper header
However, if I add "msg_apply_changes()" on the line after set_contact_alias the Contact sent to next hop has the alias content No other changes
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/445