23 Jan
2024
23 Jan
'24
10:37 a.m.
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. <calvine(a)gmail.com>om>, 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 <unai(a)rodr.org> 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. <calvine(a)gmail.com> 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
<sr-users(a)lists.kamailio.org> 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
sr-users-leave(a)lists.kamailio.org
> > > > > Important: keep the mailing list in the recipients, do not reply
only to the sender!
> > > > > Edit mailing list options or unsubscribe: