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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> >> 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 <[email protected]> on behalf of >>> Pyry Aaltonen <[email protected]> >>> *Date: *Friday, 2. September 2022 at 7.56 >>> *To: *Kamailio (SER) - Users Mailing List <[email protected]> >>> *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 <[email protected]> on behalf of >>> Julien Chavanton <[email protected]> >>> *Date: *Thursday, 1. September 2022 at 16.33 >>> *To: *Kamailio (SER) - Users Mailing List <[email protected]> >>> *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 <[email protected]> >>> 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 <[email protected]> >>> 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 <[email protected]> >>> 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 <[email protected]> >>> 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 >>> * [email protected] >>> 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 >>> * [email protected] >>> 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 * [email protected] 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
