What I think we’re missing is the “SIP INVITE dialogs”. Reading https://kamailio.org/docs/modules/stable/modules/dialog.html this seems to be exactly what we need: Kamailio can behave as a stateful proxy through the TM module. However, "stateful" in this context refers to transaction state, not dialog state. Certain applications may benefit from an awareness of "calls" in the proxy, not just SIP transactions. For example, a common need is to limit the number of calls that can be made concurrently by an endpoint, account, user group, etc. In order to count the number of calls in progress, it is necessary for the proxy to be aware of whole dialogs, not just transactions, and to provide some means of programmatically classifying these dialogs. This is just one common application discussed for illustrative purposes; there are many others.
We’ll explore the dialog module. This is very helpful, thank you so much! With best wishes, Unai Rodriguez On 22 Jan 2024 at 19:51 +0100, Calvin E. <[email protected]>, wrote: > Are you using 'ds_load_update()' and 'ds_load_unset()'? These should be > keeping track of how many sessions are active at each destination in the set, > so the one with the fewest sessions is selected. This assumes you are using > SIP INVITE dialogs. Am I missing something specific to MRCP? > > > On Mon, Jan 22, 2024 at 10:06 AM Unai Rodriguez <[email protected]> wrote: > > > We're already using call load distribution. As I said, it sends the same > > > number of requests to each backend but the max concurrency of each > > > varies... how can module dispatcher be aware of the number of ongoing > > > concurrent sessions on each backend unless it connects to them? Thank you > > > > > > > On Jan 22, 2024, at 18:37, Calvin E. <[email protected]> wrote: > > > > > > > > It sounds like you're looking for "Call Load Distribution", provided by > > > > the dispatcher module, algorithm 10 in 'ds_select_dst'. > > > > > > > > https://www.kamailio.org/docs/modules/devel/modules/dispatcher.html > > > > > > > > Search the page for references to "call load" to see how > > > > 'ds_load_update()' and 'ds_load_unset()' are used. > > > > > > > > You will need to set ds_hash_size to a power of two large enough to > > > > track your peak concurrent sessions. Each destination in a set will > > > > need a unique 'duid' string, and optionally 'maxload'. > > > > > > > > > > > > > > > > > On Mon, Jan 22, 2024 at 9:06 AM Unai Rodriguez via sr-users > > > > > <[email protected]> wrote: > > > > > > Dear List, > > > > > > > > > > > > We're load balancing MRCP requests using Kamailio dispatcher > > > > > > module's call load distribution algorithm. > > > > > > > > > > > > We want to achieve the same maximum number of concurrent sessions > > > > > > on each MRCP backend but because the duration of each request > > > > > > varies, we’re unable to achieve this (at the moment we send the > > > > > > same number of requests to each backend but they all have different > > > > > > maximum concurrent requests). > > > > > > > > > > > > Is there a way/module that will send requests to the backend with > > > > > > the least number of ongoing sessions? My guess is, this module > > > > > > needs to connect to the backends to know their status. Any pointers > > > > > > appreciated. > > > > > > > > > > > > Thank you > > > > > > > > > > > > With best wishes, > > > > > > Unai Rodriguez > > > > > > > > > > > > > > > > > > __________________________________________________________ > > > > > > Kamailio - Users Mailing List - Non Commercial Discussions > > > > > > To unsubscribe send an email to [email protected] > > > > > > Important: keep the mailing list in the recipients, do not reply > > > > > > only to the sender! > > > > > > Edit mailing list options or unsubscribe:
__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to [email protected] Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
