[SR-Users] Dispatcher module and xavp_dst
Julien Chavanton
jchavanton at gmail.com
Tue Sep 6 16:34:34 CEST 2022
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/813c3d82/attachment.htm>
More information about the sr-users
mailing list