The topos module fails to update the dialog data in the topos_d table after the processing of re-INVITEs.
I have setup a call at 11:55, and triggered a re-INVITE at 12:08. The respective topos_d table entry is not updated.
This causes the entry to expire after topos dialog_timeout value.
I would expect that the timestamp of the call in the topos_d table is updated. Is this assumption correct? If the current behavior is expected, it should documented in the module README.
No error messages from topos module in kamailio.log. Output from tables:
```
MariaDB [kamailio]> select id, rectime, s_method, a_callid from topos_t; select id, rectime, s_method, a_callid from topos_d;
+-----+---------------------+----------+----------------------------------+
| id | rectime | s_method | a_callid |
+-----+---------------------+----------+----------------------------------+
| 305 | 2019-08-04 12:08:12 | INVITE | q0Jeh9g49GeYdJXqcjCo-G0CW4dQ0iav |
| 306 | 2019-08-04 12:08:12 | ACK | q0Jeh9g49GeYdJXqcjCo-G0CW4dQ0iav |
| 307 | 2019-08-04 12:08:14 | INVITE | q0Jeh9g49GeYdJXqcjCo-G0CW4dQ0iav |
| 308 | 2019-08-04 12:08:14 | ACK | q0Jeh9g49GeYdJXqcjCo-G0CW4dQ0iav |
+-----+---------------------+----------+----------------------------------+
+-----+---------------------+----------+----------------------------------+
| id | rectime | s_method | a_callid |
+-----+---------------------+----------+----------------------------------+
| 156 | 2019-08-04 11:55:22 | INVITE | q0Jeh9g49GeYdJXqcjCo-G0CW4dQ0iav |
+-----+---------------------+----------+----------------------------------+
```
--
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/2024
Hi Alex,
there have been many changes to the modules between 5.1 and 5.2. I just
looked a bit to the code of dispatch.c and also the commits.
I noticed something in commit 3933a64c464acfb285e - there was a block
related to round-robin before which got removed in this refactoring (if
I analyzed it correctly):
- /* if alg is round-robin then update the shortcut to next to be
used */
- if(alg == DS_ALG_ROUNDROBIN)
- idx->last = (hash + 1) % idx->nr;
It could be simple added back, because of the changed logic, though.
Cheers,
Henning
Am 12.08.19 um 17:28 schrieb Alex Balashov:
> Hi Daniel,
>
> Haven’t checked that, no. But all the external system does is issue RPC commands (`dispatcher.set_state`) maybe a few times a day. It’s nothing volatile or overly Byzantine.
>
> —
> Sent from mobile, with due apologies for brevity and errors.
>
>> On Aug 12, 2019, at 11:24 AM, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote:
>>
>> Hello,
>>
>> could you observe similar behavior on other dispatchers that don't use
>> an external system tomanage activation and deactivation of the gateways?
>> Or you haven't checked such one so far?
>>
>> Cheers,
>> Daniel
>>
>>> On 12.08.19 15:23, Alex Balashov wrote:
>>> Hi,
>>>
>>> I've got a proxy that does very basic round-robin distribution of calls
>>> to an elastic pool of servers, defined in a simple SQLite database with
>>> equal priorities. Nothing too complicated, just a vanilla
>>> `ds_select_domain("1", "4")`.
>>>
>>> The only complication is that seldom are most of the gateways enabled.
>>> Probing stuff was turned on, but didn't do quite what was desired, so it
>>> was replaced with a system that manages activation and deactivation of
>>> the gateways externally. Nevertheless, these are the left-over probing
>>> settings:
>>>
>>> modparam("dispatcher", "ds_ping_method", "OPTIONS")
>>> modparam("dispatcher", "ds_ping_from", "sip:pinger@domain")
>>> modparam("dispatcher", "ds_ping_interval", 15)
>>> modparam("dispatcher", "ds_probing_threshold", 256)
>>> modparam("dispatcher", "ds_inactive_threshold", 1)
>>> modparam("dispatcher", "ds_probing_mode", 0)
>>>
>>> After an upgrade from 5.1 to 5.2.3 (009f62), the round-robin has become
>>> extremely "sticky" and tendentious. That is to say, it directs _almost_
>>> all calls to a single gateway -- the first gateway in the table --
>>> though not 100%. There is also a marked tendency to send lots of
>>> consecutive calls to the same gateway, even if it's not the first one,
>>> though most of the time it is.
>>>
>>> Has anyone experienced similar upon upgrading to 5.2?
>>>
>>> Thanks much!
>>>
>>> -- Alex
>>>
>> --
>> Daniel-Constantin Mierla -- www.asipto.com
>> www.twitter.com/miconda -- www.linkedin.com/in/miconda
>>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users(a)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
#### 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 -->
- [ ] PR should be backported to stable branches
- [x] Tested changes locally
- [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description
What the affected line of code really wants to achieve is: if an
accepted inputs type mask is not specified then default to accepting
only the actual variable type. So we must mask the var type first,
then shift it by `CFG_INPUT_SHIFT`, before or-ing it with the rest.
What happened before was that the entire type was shifted, and that
included var type, input type and flags. What we end up with is some
additional higher bits set (for flags). I actually discovered this while
adding an additional flag that was meant to mark variables as private,
only accessible through an internal API (not available to modules such
as cfg_rpc).
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/2022
-- Commit Summary --
* core: Fix the cfg framework variable input type default
-- File Changes --
M src/core/cfg/cfg.c (2)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/2022.patchhttps://github.com/kamailio/kamailio/pull/2022.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/2022
Module: kamailio
Branch: master
Commit: c3b2eacbba1097ed3d40cff18ea2d51ebcad1c67
URL: https://github.com/kamailio/kamailio/commit/c3b2eacbba1097ed3d40cff18ea2d51…
Author: MancaÈ George <mancas.f.george(a)gmail.com>
Committer: MancaÈ George <mancas.f.george(a)gmail.com>
Date: 2019-08-01T09:39:28Z
core: Fix the cfg framework variable input type default
What the affected line of code really wants to achieve is: if an
accepted inputs type mask is not specified then default to accepting
only the actual variable type. So we must mask the var type first,
then shift it by `CFG_INPUT_SHIFT`, before or-ing it with the rest.
What happened before was that the entire type was shifted, and that
included var type, input type and flags. What we end up with is some
additional higher bits set (for flags). I actually discovered this while
adding an additional flag that was meant to mark variables as private,
only accessible through an internal API (not available to modules such
as cfg_rpc).
---
Modified: src/core/cfg/cfg.c
---
Diff: https://github.com/kamailio/kamailio/commit/c3b2eacbba1097ed3d40cff18ea2d51…
Patch: https://github.com/kamailio/kamailio/commit/c3b2eacbba1097ed3d40cff18ea2d51…
---
diff --git a/src/core/cfg/cfg.c b/src/core/cfg/cfg.c
index 3822a9c94d..488d72f35a 100644
--- a/src/core/cfg/cfg.c
+++ b/src/core/cfg/cfg.c
@@ -94,7 +94,7 @@ int cfg_declare(char *group_name, cfg_def_t *def, void *values, int def_size,
/* verify the type of the input */
if (CFG_INPUT_MASK(def[i].type)==0) {
- def[i].type |= def[i].type << CFG_INPUT_SHIFT;
+ def[i].type |= CFG_VAR_MASK(def[i].type) << CFG_INPUT_SHIFT;
} else {
if ((CFG_INPUT_MASK(def[i].type) != CFG_VAR_MASK(def[i].type) << CFG_INPUT_SHIFT)
&& (def[i].on_change_cb == 0)) {