Hello, maybe a dedicated module is going to be too complex or better said, duplicate a lot of code for management of the destinations, load/reload/keepalive, ... (although I won't have anything against such approach, if considered better by developer).
However, if done in dispatcher, I think that a new algorithm id should be used, leaving 8 as it is. Also, there should be a new field added in the internal structure to keep this "dynamic" priority -- it can be initialized to the "priority" value. In some cases I use different algorithms for the same group of destinations, so it would be good to be able to use algorithm 8 with priority from database and the new algorithm at the same time. Cheers, Daniel On 27.05.20 21:46, Henning Westerholt wrote: > > Hi Julien, > > > > sounds interesting, a “location optimized routing mode”. What about > making it as a dedicated mode, to not overloading the mode “8”? > > > > Cheers, > > > > Henning > > > > -- > > Henning Westerholt – https://skalatan.de/blog/ > > Kamailio services – https://gilawa.com <https://gilawa.com/> > > > > *From:* sr-dev <[email protected]> *On Behalf Of > *Julien Chavanton > *Sent:* Thursday, May 14, 2020 7:26 PM > *To:* Kamailio (SER) - Development Mailing List > <[email protected]>; Kamailio (SER) - Users Mailing List > <[email protected]> > *Subject:* [sr-dev] congestion control priority for priority based > dispatching > > > > Hi Folks, > > > Just found another simple use case of the dispatcher latency stats. > > Just shraing this idea of a feature I want to contribute. > > > When using dispatcher algorithm 8: > > “8” - select destination sorted by priority attribute value (serial > forking ordered by priority). > > If the gateway as the attribute, the priority becomes the estimated > latency. > > cc-priority > > > > - The dispatcher would automatically prioritize the closest one. > > - If a gateway is becoming unresponsive it will automatically become > de prioritize. > > > Consider this real life scenario where you have gateways in East and > West Coast > > Example > > > URI: sip:28.71.19.140 > > > FLAGS: AP > PRIORITY: 10 > ATTRS: { > BODY: cc_priority=1 > } > LATENCY: { > AVG: 84.001000 > STD: 0.062000 > EST: 84.001000 (high == low priority) > MAX: 93 > TIMEOUT: 0 > URI: sip:28.71.16.140 > FLAGS: AP > PRIORITY: 10 > > ATTRS: { > BODY: cc_priority=1 > } > > LATENCY: { > AVG: 29.110000 > STD: 2.383000 > EST: 31.999000 (low == high priority) > MAX: 1499 > TIMEOUT: 1 > > > > > > Another major improvement to all of this would be to gather stats on > INVITE <> 100 to have a very accurate latency estimation even if the > gateway does not support SIP OPTIONS pings > > > > > > > _______________________________________________ > Kamailio (SER) - Development Mailing List > [email protected] > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Funding: https://www.paypal.me/dcmierla
_______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
