This is a snip from the user's mailing list, I'm just adding it to the issue tracker, as it is yet to be confirmed as a bug, only here for tracking pruporses:
```
I have a situation where I have 2 devices registering with the same AOR, I have the registrar module's max_contacts parameter set to 1 and I use the 0x04 flag on the save function.
When I use dmq_usrloc for replication, I can see 2 contacts registered for the AOR on the "client" nodes whereas the node where the actual registration took place only has 1 contact for the AOR.
```
```
It seems to me like another bug, although again I'm not familiar with the module so can't be sure without looking that it is not intended behaviour.
I plan to look later this week when I have some time but in the meantime, you can send me the examples directly if you like.
```
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/265
Kamailio takes care of sending in-dialog keep-alives using OPTIONS when dlg_set_attribute ka-src and ka-dst is used. It also sends OPTIONS to correct address if a client sends Re-Invite indicating a network change, which is a common case with mobile clients (switching between mobile-data and Wifi) fixed in #273
The problem is that it ends the dialog on missing even one keep-alive response. Missing a response is possible when the client is handling the network change and keep-alive is sent around that time.
Thus, having a configurable counter after which you expect to end the dialog might be helpful. For eg. you decide to end the dialog after we miss 3 responses for keep-alives in a row.
Something like dlg_set_attribute(ka-src, 3) where 3 indicates the number of responses that can be missed before ending the dialog.
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/438
ENV: Debian 8
So on most Linux systems the /var/run folder is a tmpfs and after which clears after each reboot
As I try to start up kamailio after a reboot through kamctl I get the following error.
"ERROR: PID file /var/run/kamailio.pid does not exist -- Kamailio start failed"
Because kamailio does not have the permission to write to the /var/run folder as the kamailio user.
Would it be possible to add in the "kamctl" code a section where the SPECIFIED PID LOCATION (/var/run/kamailio) is checked and if it does not exist create it as the root user and chown it to the SPECIFIED USER (kamailio)? The way I have patched it for now is to create a init script that creates a /var/run/kamailio folder and chmods it to kamailio:kamailio
Thanks everyone!
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/231
Hello,
As you will see I have merged my branch back into master.
These changes add a new event route [tm:branch-failure] to the tm module
which is run when any failure response is received on a transaction.
The event_route uses a new route type BRANCH_ROUTE which limits the
functions that can be run in the route.
The functions t_check_status(), t_next_contact_flow(), t_relay() and
unregister() can be used in this route.
A new pv $T_reply_ruid is accessible in this route which can be used to
unregister a single contact entry.
The following example route can be used on a registrar to handle failed
or invalid flows:
event_route[tm:branch-failure] {
xlog("L_INFO", "event_route[tm:branch-failure]\n");
if (t_check_status("430|403")) {
if (!unregister("location", "$tu", "$T_reply_ruid"))
{
xlog("L_WARN", "failed to unregister $tu with
ruid $T_reply_ruid\n");
}
if (!t_next_contact_flow())
{
xlog("L_INFO", "No more flows\n");
}
else
{
xlog("L_INFO", "Next flow\n");
t_relay();
}
}
}
Any bugs, memory leaks etc. let me know!
Hugh
--
Hugh Waite
Principal Design Engineer
Crocodile RCS Ltd.
If a PUBLISH request is sent before a 200 OK for the previous PUBLISH request is received, the E-Tag is reset which leads to inconsistent presentity data in the presence server.
This is happening because the second PUBLISH is sent with the same E-Tag as the previous one, but the presence server has an updated the E-Tag (generated while handling the first PUBLISH).
The pua module should implement a queuing mechanism for subsequent PUBLISH request while a previous PUBLISH transaction is in progress. No new PUBLISH requests should be sent before a response to the previous PUBLISH request was received and the E-Tag updated.
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/21