[SR-Users] Dispatcher module and xavp_dst
Julien Chavanton
jchavanton at gmail.com
Tue Sep 6 16:52:14 CEST 2022
Hi again Pyry, it would be great if you could cherry-pick the commit/patch
and test it and add a comment in the MR.
https://github.com/kamailio/kamailio/pull/3232
On Tue, Sep 6, 2022 at 10:34 AM Julien Chavanton <jchavanton at gmail.com>
wrote:
> Hi Pyry, I just made some tests and found the misalignment, I am preparing
> a patch.
>
> I made some tests with 3 and 6 gateways, disabling one and then two, I
> found how the indexes could get mixed up between the call to
> ds_sorted_by_priority() and ds_manage_routes_fill_reordered_xavp().
>
> Hopefully you can help with testing once I have the MR ready, shortly.
>
>
> Some test data :
>
> INSERT INTO dispatcher VALUES(1,1,'sip:192.168.0.1:5060',0,12,'','');
> INSERT INTO dispatcher VALUES(2,1,'sip:192.168.0.2:5060',0,12,'','');
> INSERT INTO dispatcher VALUES(3,1,'sip:192.168.0.3:5060',0,12,'','');
> INSERT INTO dispatcher VALUES(4,1,'sip:192.168.0.4:5060',0,12,'','');
> INSERT INTO dispatcher VALUES(5,1,'sip:192.168.0.5:5060',0,12,'','');
> INSERT INTO dispatcher VALUES(6,1,'sip:192.168.0.6:5060',0,12,'','');
>
> Then disabling 2 gateways :
>
> dispatcher.set_state i 1 sip:192.168.0.1:5060
> dispatcher.set_state i 1 sip:192.168.0.3:5060
>
>
> // ----------------- Routing Logic -----------------
> //
> route {
> xinfo("[MAIN][$rm][$ci]from[$fU]to[$tU]ruri[$ru]Rp[$Rp]Ri[$Ri]\n");
> if (!ds_select_dst("1","13", "-1")) {
> xinfo("[MAIN] no gateway available !\n");
> }
>
>
> while (defined $xavp(_dsdst_)) {
> xinfo("[MAIN] URI : $xavp(_dsdst_=>uri) \n");
> pv_unset("$xavp(_dsdst_)");
> }
> return;
> }
>
> // Logs showing the gateways returned.
>
> 0(398491) DEBUG: dispatcher [dispatch.c:2263]: ds_manage_route_algo13():
> [active][0]idx[1]uri[sip:192.168.0.5:5060
> ]priority[12-0=12]latency[0ms]flag[0]
> 0(398491) DEBUG: dispatcher [dispatch.c:2263]: ds_manage_route_algo13():
> [active][1]idx[2]uri[sip:192.168.0.4:5060
> ]priority[12-0=12]latency[0ms]flag[0]
> 0(398491) DEBUG: dispatcher [dispatch.c:2270]: ds_manage_route_algo13():
> [inactive][2]idx[-1]uri[sip:192.168.0.3:5060
> ]priority[12]latency[0ms]flag[1]
> 0(398491) DEBUG: dispatcher [dispatch.c:2263]: ds_manage_route_algo13():
> [active][3]idx[4]uri[sip:192.168.0.2:5060
> ]priority[12-0=12]latency[0ms]flag[0]
> 0(398491) DEBUG: dispatcher [dispatch.c:2270]: ds_manage_route_algo13():
> [inactive][4]idx[-1]uri[sip:192.168.0.1:5060
> ]priority[12]latency[0ms]flag[1]
> 0(398491) DEBUG: dispatcher [dispatch.c:2263]: ds_manage_route_algo13():
> [active][5]idx[0]uri[sip:192.168.0.6:5060
> ]priority[12-0=12]latency[0ms]flag[0]
>
> 0(398491) DEBUG: dispatcher [dispatch.c:2128]:
> ds_manage_routes_fill_reordered_xavp(): [4|sip:192.168.0.3:5060|idx:-1]skipped
> 1 || 1
> 0(398491) DEBUG: dispatcher [dispatch.c:2128]:
> ds_manage_routes_fill_reordered_xavp(): [5|sip:192.168.0.1:5060|idx:-1]skipped
> 1 || 1
> 0(398491) DEBUG: dispatcher [dispatch.c:2300]: ds_manage_route_algo13():
> priority[12]gateway_selected[1]next_index[2]
> 0(398491) DEBUG: dispatcher [dispatch.c:2465]: ds_manage_routes(): using
> alg [13] hash [1]
> 0(398491) DEBUG: dispatcher [dispatch.c:2512]: ds_manage_routes():
> selected [13-1-0/1] <sip:192.168.0.5:5060>
> 0(398491) DEBUG: dispatcher [dispatch.c:2107]: ds_select_dst_limit():
> selected target destinations: 4
> 0(398491) INFO: <script>: [MAIN][sip:192.168.0.5:5060]
> 0(398491) INFO: <script>: [MAIN] URI : sip:192.168.0.5:5060
> 0(398491) INFO: <script>: [MAIN] URI : sip:192.168.0.4:5060
> 0(398491) INFO: <script>: [MAIN] URI : sip:192.168.0.2:5060
> 0(398491) INFO: <script>: [MAIN] URI : sip:192.168.0.6:5060
>
> On Mon, Sep 5, 2022 at 9:02 AM Julien Chavanton <jchavanton at gmail.com>
> wrote:
>
>> Seems like you are on the right track, FYI I will have a look by the end
>> of the day tomorrow.
>>
>> On Mon, Sep 5, 2022, 6:06 AM Pyry Aaltonen <pyry.aaltonen at cuuma.com>
>> wrote:
>>
>>> Hi,
>>>
>>>
>>>
>>> I´ve looked now closer the commit and overall the dispatch.c, and I
>>> think the problem is related to that problem which was fixed in that commit
>>> which I linked previously.
>>>
>>> (I looked the code from master in github)
>>>
>>> As a background I need to mention that its been over 10years since I´ve
>>> last read this much c-code so might be that I’m wrong 😊
>>>
>>>
>>>
>>> But..
>>>
>>>
>>>
>>> I cant quite tell you what the problem exactly is but to me it looks
>>> like there is something with the
>>>
>>> ds_sorted list and its reordering, combined with the function call of
>>> the ds_add_xavp_record with ds_sorted[i].idx, in the function
>>> ds_manage_routes_fill_reodered_xavp.
>>>
>>> (btw it probably should be reoRdered instead of reodered)
>>>
>>>
>>>
>>> I think the loop there messes up the referencing order of destinations
>>> in a situation where the highest priority destination is inactive.
>>>
>>>
>>>
>>> And it seems like It is happening only when the original order of the
>>> set is changing (which was fixed in the commit I linked previously)
>>>
>>> Because when for example set with 2 destination
>>>
>>>
>>>
>>> Dest1 prio 10
>>>
>>> Dest2 prio 0
>>>
>>>
>>>
>>> Both active -> xavp -> has values
>>>
>>> Dest2 inactive -> xavp -> has values
>>>
>>> Dest1 inactive -> xavp -> null
>>>
>>>
>>>
>>> So I guess somehow the same thing should need a fix in the
>>> ds_add_xavp_record or probably in the call for that in the
>>> ds_amange_routes_fille_reodered_xavp function.
>>>
>>>
>>>
>>>
>>>
>>> Does this make any sense to anyone else?
>>>
>>>
>>>
>>>
>>>
>>> -Pyry
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From: *sr-users <sr-users-bounces at lists.kamailio.org> on behalf of
>>> Pyry Aaltonen <pyry.aaltonen at cuuma.com>
>>> *Date: *Friday, 2. September 2022 at 7.56
>>> *To: *Kamailio (SER) - Users Mailing List <sr-users at lists.kamailio.org>
>>> *Subject: *Re: [SR-Users] Dispatcher module and xavp_dst
>>>
>>> Hi,
>>>
>>>
>>>
>>> Thank you for your responses!
>>>
>>>
>>>
>>> I don’t have latency stats enabled, but I do want to have load balance
>>> using round-robin by priorities, and that’s why I’m using algo13 instead
>>> algo 8, cause algo 8 doesn’t round-robin if the priorities are the same,
>>> and still, I do want to have priorities and not only round-robin and that’s
>>> why I’m not using algo4 either.
>>>
>>> So algo13 should be fine and the dispatching works just like it is
>>> described in the documentation, only the xavp_dst values aren’t updated
>>> like it should (I think 😊)
>>>
>>>
>>>
>>> Yesterday when I was searching around this issue of mine, I found out
>>> this quite recent commit
>>> https://github.com/kamailio/kamailio/commit/adba3caa2d12d1f8b89d720fbb9a6a9cdc8b2573
>>>
>>> The description of that commit looks quite same that what I’m now facing
>>> with only the xavp_dst values.
>>>
>>> If the highest priority destination is inactive the destination is
>>> updated but the corresponding xavp_dst values are not correct(or missing
>>> completely).
>>>
>>>
>>>
>>> With my previous destination examples
>>>
>>> If first trunk is inactive, the destination is set correctly to second
>>> one, but the xavp_dst values are null, and I think xavp_dst values should
>>> be “type=2” or something like that.
>>>
>>> 10 sip:1.2.3.4;transport=tcp 10 1 type=type1
>>>
>>> 10 sip:4.3.2.1;transport=tcp 10 1 type=type2
>>>
>>>
>>>
>>> -Pyry
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From: *sr-users <sr-users-bounces at lists.kamailio.org> on behalf of
>>> Julien Chavanton <jchavanton at gmail.com>
>>> *Date: *Thursday, 1. September 2022 at 16.33
>>> *To: *Kamailio (SER) - Users Mailing List <sr-users at lists.kamailio.org>
>>> *Subject: *Re: [SR-Users] Dispatcher module and xavp_dst
>>>
>>> The rest of the dispatcher "features", like failover should be supported
>>> based on what I remember from the way it was integrated and tested.
>>>
>>> If it is not the case I can have a look.
>>>
>>>
>>>
>>>
>>> On Thu, Sep 1, 2022 at 9:21 AM Julien Chavanton <jchavanton at gmail.com>
>>> wrote:
>>>
>>> On second thought, the documentation looks accurate to me.
>>>
>>> Do you have the latency stats enabled ?
>>> 3.26. ds_ping_latency_stats (int)
>>>
>>>
>>>
>>> If yes, the priority values you are using seem a bit low 1ms and 10ms.
>>>
>>> If not, the algorithm should behave simply like that :
>>>
>>> "The algorithm will load balance using round-robin prioritizing the
>>> gateways with the highest priority. "
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Sep 1, 2022 at 9:09 AM Julien Chavanton <jchavanton at gmail.com>
>>> wrote:
>>>
>>> Maybe the documentation should be improved, it seems the first bullet
>>> point should say.
>>>
>>> "The algorithm will load balance using round-robin prioritizing the
>>> gateways with the highest *adjusted* priority. "
>>>
>>>
>>>
>>>
>>> On Thu, Sep 1, 2022 at 9:06 AM Julien Chavanton <jchavanton at gmail.com>
>>> wrote:
>>>
>>> Hi, did you look at the documentation of algorithm 13 ?
>>>
>>>
>>>
>>> The priority is used in combination with the latency to determine the
>>> preferred gateway.
>>>
>>> Once you confirm that this is what you want "latency latency optimized
>>> dispatching", we can help to clarify why and how this may not work as
>>> expected.
>>>
>>>
>>>
>>> Regards
>>>
>>>
>>>
>>> https://kamailio.org/docs/modules/devel/modules/dispatcher.html
>>>
>>> - “13” - latency optimized dispatching
>>>
>>> - The algorithm will load balance using round-robin prioritizing the
>>> gateways with the highest priority.
>>>
>>> - If ds_ping_latency_stats is active the algorithm will adjust the
>>> priority of the gateway automatically, the priority will be lowered by 1
>>> point every time the latency ms is as high as the priority.
>>>
>>> - If the attribute 'cc=1' is set, the latency used is congestion ms :
>>> estimate (current latency ms) - average (normal condition latency ms).
>>>
>>> *Example 1.46. **latency_optimized_dispatching** usage*
>>>
>>> Using this simple formula :
>>>
>>> ADJUSTED_PRIORITY = PRIORITY - (ESTIMATED_LATENCY_MS/PRIORITY)
>>>
>>>
>>>
>>> GATEWAY | PRIORITY | ESTIMATED | ADJUSTED | LOAD
>>>
>>> # | | LATENCY | PRIORITY | DISTRIBUTION
>>>
>>> 1 | 30 | 21 | 30 | 33%
>>>
>>> 2 | 30 | 91 | 27 | 0%
>>>
>>> 3 | 30 | 61 | 28 | 0%
>>>
>>> 4 | 30 | 19 | 30 | 33%
>>>
>>> 5 | 30 | 32 | 29 | 0%
>>>
>>> 6 | 30 | 0 | 30 | 33%
>>>
>>> 7 | 30 | 201 | 24 | 0%
>>>
>>>
>>>
>>>
>>>
>>> With congestion control the formula becomes :
>>>
>>> CONGESTION_MS = CURRENT_LATENCY_MS - NORMAL_CONDITION_LATENCY_MS
>>>
>>> ADJUSTED_PRIORITY = PRIORITY - (CONGESTION_MS/PRIORITY)
>>>
>>>
>>>
>>> -
>>>
>>>
>>>
>>> On Thu, Sep 1, 2022 at 2:38 AM Pyry Aaltonen <pyry.aaltonen at cuuma.com>
>>> wrote:
>>>
>>> Hello,
>>>
>>>
>>>
>>> I’m quite new user with kamailio (heard first time about it a year ago
>>> and joined the list yesterday) and now wondering how the xavp_dst should
>>> work.
>>>
>>>
>>>
>>> I had read from the documentation that
>>>
>>> ”The first XAVP is the current selected destination.”
>>>
>>>
>>>
>>> I use ds_select_dst with alg 13. And my kamailio version is kamailio
>>> 5.5.3 (x86_64/linux)
>>>
>>>
>>>
>>> So when my dispatcher list is like (I have also tried to differ the
>>> priority value like 10 and 1, but doesn’t make difference)
>>>
>>> 10 sip:1.2.3.4;transport=tcp 10 1 type=type1
>>>
>>> 10 sip:4.3.2.1;transport=tcp 10 1 type=type2
>>>
>>>
>>>
>>> If one of the destinations fails (dx/ip), and it happens to be the one
>>> with higher priority or the one that just gets higher position in the
>>> dispatcher list if the prio Is equal.
>>>
>>> My xavp_$xavp(dsdst=>attrs) get null value. And, if I try to seek
>>> $(xavp(dsdst[0]=>attrs) or $(xavp(dsdst[1]=>attrs) I also got nothing.
>>>
>>>
>>>
>>> If both destinations are up with equal priority, it selects them with
>>> round-robin, and the xavp_$xavp(dsdst=>attrs) has the type value of the
>>> selected destination as expected, also the $(xavp(dsdst[0]=>attrs) or
>>> $(xavp(dsdst[1]=>attrs) contains the destinations so that the selected
>>> is 0 and the other is at position 1.
>>>
>>> The $du is updated as I expect so if one fails the other one is selected
>>> always, why the xavp_dst isn’t working same way, or am I missing something?
>>>
>>>
>>>
>>> If needed I’ll try to provide more information,
>>>
>>> Thanks already in advance
>>>
>>>
>>>
>>> -Pyry
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> __________________________________________________________
>>> Kamailio - Users Mailing List - Non Commercial Discussions
>>> * sr-users at lists.kamailio.org
>>> Important: keep the mailing list in the recipients, do not reply only to
>>> the sender!
>>> Edit mailing list options or unsubscribe:
>>> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>> __________________________________________________________
>>> Kamailio - Users Mailing List - Non Commercial Discussions
>>> * sr-users at lists.kamailio.org
>>> Important: keep the mailing list in the recipients, do not reply only to
>>> the sender!
>>> Edit mailing list options or unsubscribe:
>>> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20220906/04a65106/attachment.htm>
More information about the sr-users
mailing list