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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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
