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
