7 Jun
2018
7 Jun
'18
5:40 a.m.
Hi All,
Currently trying to work out the best way to keep track of how many calls are being sent
to any given dispatcher destination.
I remember being able to do this years ago with the load balancer module in OpenSIPS:
opensipsctl fifo lb_list.
Dispatching algorithm '10' seems to be the best fit for my requirements, as
I'm essentially wanting to send calls to a large quantity of FreeSwitch docker
containers acting as fax receiving nodes.
Equal weight, just filling them in some balanced fashion.
Any hints or ideas would be much appreciated!
Kind regards,
Tim Bowyer
7 Jun
7 Jun
5:41 a.m.
It sounds like the dialog module might be your best bet.
On June 6, 2018 10:40:38 PM EDT, Tim Bowyer <timbo(a)timbo.net.au> wrote:
Hi All,
Currently trying to work out the best way to keep track of how many
calls are being sent to any given dispatcher destination.
I remember being able to do this years ago with the load balancer
module in OpenSIPS: opensipsctl fifo lb_list.
Dispatching algorithm '10' seems to be the best fit for my
requirements, as I'm essentially wanting to send calls to a large
quantity of FreeSwitch docker containers acting as fax receiving nodes.
Equal weight, just filling them in some balanced fashion.
Any hints or ideas would be much appreciated!
Kind regards,
Tim Bowyer
-- Alex
--
Sent via mobile, please forgive typos and brevity.
10:04 a.m.
Thanks for the prompt reply Alex!
Trying to get my head around the best way to use the module.
By the looks I need to statically create profiles which will be used as counting groups.
Since each destination is dynamically created thus named with a fairly random ID, I
can't see how this could work.
Have tried using variables but I get a heap of errors. The process will only start if I
use static profile names.
Is there another sneaky way to get around this? When a new container is spun up, a new
entry is added to the dispatcher table and the dispatcher reloaded.
Likewise to trigger a container to start draining calls we remove from dispatcher then
reload before waiting for all calls to finish and stop the container.
Cheers,
Tim Bowyer
-----Original Message-----
From: sr-users <sr-users-bounces(a)lists.kamailio.org> On Behalf Of Alex Balashov
Sent: Thursday, 7 June 2018 10:42 AM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Subject: Re: [SR-Users] Monitoring Dispatcher
It sounds like the dialog module might be your best bet.
On June 6, 2018 10:40:38 PM EDT, Tim Bowyer <timbo(a)timbo.net.au> wrote:
Hi All,
Currently trying to work out the best way to keep track of how many
calls are being sent to any given dispatcher destination.
I remember being able to do this years ago with the load balancer
module in OpenSIPS: opensipsctl fifo lb_list.
Dispatching algorithm '10' seems to be the best fit for my
requirements, as I'm essentially wanting to send calls to a large
quantity of FreeSwitch docker containers acting as fax receiving nodes.
Equal weight, just filling them in some balanced fashion.
Any hints or ideas would be much appreciated!
Kind regards,
Tim Bowyer
-- Alex
--
Sent via mobile, please forgive typos and brevity.
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
11:04 a.m.
Hello,
do you need to have the counter per exact address in the dispatcher? Or
you want to have it per IP (address) of FreeSwitch?
If you just need the number of the calls, I would go with htable module,
having two options here:
a) store in table items (callid, srcipaddr, like $sht(acalls=>$ci) =
$si;) when getting 200OK for INVITE, delete the item by callid when BYE
is received ($sht(acalls=>$ci) = $null). This would require dumping the
entire hash table via rpc and count by value. You can set some auto
expires value to the max call lifetime you allow on your service
b) store the counter per ip addrress, so on 200OK you do
$shtinc(acalls=>$si). Based on direction (see rr module for how to
detect the direction), you have to decremented it on BYE based either on
source IP or next hop IP. On this option, you have to be careful with
cross BYEs (caller and callee hanging up at the same time, resulting in
two BYEs crossing kamailio for same call) -- you can use another hash
table to store that counter was decremented based on call-id, with the
item stored for short time, like auto expires 2 minutes.
The internal htable module can be replaced with a redis storage by using
ndb_redis.
For the future, I can add an rpc command to dump those numbers directly
from dispatcher module when using with algorithm 10.
Cheers,
Daniel
On 07.06.18 09:04, Tim Bowyer wrote:
Thanks for the prompt reply Alex!
Trying to get my head around the best way to use the module.
By the looks I need to statically create profiles which will be used as counting groups.
Since each destination is dynamically created thus named with a fairly random ID, I
can't see how this could work.
Have tried using variables but I get a heap of errors. The process will only start if I
use static profile names.
Is there another sneaky way to get around this? When a new container is spun up, a new
entry is added to the dispatcher table and the dispatcher reloaded.
Likewise to trigger a container to start draining calls we remove from dispatcher then
reload before waiting for all calls to finish and stop the container.
Cheers,
Tim Bowyer
-----Original Message-----
From: sr-users <sr-users-bounces(a)lists.kamailio.org> On Behalf Of Alex Balashov
Sent: Thursday, 7 June 2018 10:42 AM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Subject: Re: [SR-Users] Monitoring Dispatcher
It sounds like the dialog module might be your best bet.
On June 6, 2018 10:40:38 PM EDT, Tim Bowyer <timbo(a)timbo.net.au> wrote:
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference -- www.kamailioworld.com
Hi All,
Currently trying to work out the best way to keep track of how many
calls are being sent to any given dispatcher destination.
I remember being able to do this years ago with the load balancer
module in OpenSIPS: opensipsctl fifo lb_list.
Dispatching algorithm '10' seems to be the best fit for my
requirements, as I'm essentially wanting to send calls to a large
quantity of FreeSwitch docker containers acting as fax receiving nodes.
Equal weight, just filling them in some balanced fashion.
Any hints or ideas would be much appreciated!
Kind regards,
Tim Bowyer
-- Alex
--
Sent via mobile, please forgive typos and brevity.
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
2:10 p.m.
Hello,
On 07.06.18 10:04, Daniel-Constantin Mierla wrote:
Hello,
[...]
For the future, I can add an rpc command to dump those numbers directly
from dispatcher module when using with algorithm 10.
just implemented the feature in master branch -- the active dialogs load
should be printed in the rpc output for each destination (RUNTIME =>
DLGLOAD field).
Can you test and report back if it gives what you expect? If you want to
test with older versions and backport the patch locally, the commit
adding it is:
-
https://github.com/kamailio/kamailio/commit/513a176394247a3378ee218bf9df611…
Cheers,
Daniel
Cheers,
Daniel
On 07.06.18 09:04, Tim Bowyer wrote:
> Thanks for the prompt reply Alex!
>
> Trying to get my head around the best way to use the module.
> By the looks I need to statically create profiles which will be used as counting
groups.
> Since each destination is dynamically created thus named with a fairly random ID, I
can't see how this could work.
>
> Have tried using variables but I get a heap of errors. The process will only start
if I use static profile names.
>
> Is there another sneaky way to get around this? When a new container is spun up, a
new entry is added to the dispatcher table and the dispatcher reloaded.
> Likewise to trigger a container to start draining calls we remove from dispatcher
then reload before waiting for all calls to finish and stop the container.
>
> Cheers,
>
> Tim Bowyer
>
>
> -----Original Message-----
> From: sr-users <sr-users-bounces(a)lists.kamailio.org> On Behalf Of Alex
Balashov
> Sent: Thursday, 7 June 2018 10:42 AM
> To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
> Subject: Re: [SR-Users] Monitoring Dispatcher
>
> It sounds like the dialog module might be your best bet.
>
> On June 6, 2018 10:40:38 PM EDT, Tim Bowyer <timbo(a)timbo.net.au> wrote:
>> Hi All,
>>
>> Currently trying to work out the best way to keep track of how many
>> calls are being sent to any given dispatcher destination.
>> I remember being able to do this years ago with the load balancer
>> module in OpenSIPS: opensipsctl fifo lb_list.
>>
>> Dispatching algorithm '10' seems to be the best fit for my
>> requirements, as I'm essentially wanting to send calls to a large
>> quantity of FreeSwitch docker containers acting as fax receiving nodes.
>> Equal weight, just filling them in some balanced fashion.
>>
>> Any hints or ideas would be much appreciated!
>>
>> Kind regards,
>>
>> Tim Bowyer
> -- Alex
>
> --
> Sent via mobile, please forgive typos and brevity.
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users(a)lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users(a)lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference -- www.kamailioworld.com
8 Jun
8 Jun
12:15 p.m.
Hi Daniel,
Wow that was fast! Really appreciate your efforts.
I'm using a docker package at the moment so will need to jump through some hoops to
get the master build packaged for docker.
I'll keep you posted how I go.
Cheers once again and have a great weekend.
Tim Bowyer
-----Original Message-----
From: Daniel-Constantin Mierla <miconda(a)gmail.com>
Sent: Thursday, 7 June 2018 7:10 PM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>rg>; Tim Bowyer
<timbo(a)timbo.net.au>
Subject: Re: [SR-Users] Monitoring Dispatcher
Hello,
On 07.06.18 10:04, Daniel-Constantin Mierla wrote:
Hello,
[...]
For the future, I can add an rpc command to dump those numbers
directly from dispatcher module when using with algorithm 10.
just implemented the feature in master branch -- the active dialogs load should be printed
in the rpc output for each destination (RUNTIME => DLGLOAD field).
Can you test and report back if it gives what you expect? If you want to test with older
versions and backport the patch locally, the commit adding it is:
-
https://github.com/kamailio/kamailio/commit/513a176394247a3378ee218bf9df611…
Cheers,
Daniel
Cheers,
Daniel
On 07.06.18 09:04, Tim Bowyer wrote:
> Thanks for the prompt reply Alex!
>
> Trying to get my head around the best way to use the module.
> By the looks I need to statically create profiles which will be used as counting
groups.
> Since each destination is dynamically created thus named with a fairly random ID, I
can't see how this could work.
>
> Have tried using variables but I get a heap of errors. The process will only start
if I use static profile names.
>
> Is there another sneaky way to get around this? When a new container is spun up, a
new entry is added to the dispatcher table and the dispatcher reloaded.
> Likewise to trigger a container to start draining calls we remove from dispatcher
then reload before waiting for all calls to finish and stop the container.
>
> Cheers,
>
> Tim Bowyer
>
>
> -----Original Message-----
> From: sr-users <sr-users-bounces(a)lists.kamailio.org> On Behalf Of
> Alex Balashov
> Sent: Thursday, 7 June 2018 10:42 AM
> To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
> Subject: Re: [SR-Users] Monitoring Dispatcher
>
> It sounds like the dialog module might be your best bet.
>
> On June 6, 2018 10:40:38 PM EDT, Tim Bowyer <timbo(a)timbo.net.au> wrote:
>> Hi All,
>>
>> Currently trying to work out the best way to keep track of how many
>> calls are being sent to any given dispatcher destination.
>> I remember being able to do this years ago with the load balancer
>> module in OpenSIPS: opensipsctl fifo lb_list.
>>
>> Dispatching algorithm '10' seems to be the best fit for my
>> requirements, as I'm essentially wanting to send calls to a large
>> quantity of FreeSwitch docker containers acting as fax receiving nodes.
>> Equal weight, just filling them in some balanced fashion.
>>
>> Any hints or ideas would be much appreciated!
>>
>> Kind regards,
>>
>> Tim Bowyer
> -- Alex
>
> --
> Sent via mobile, please forgive typos and brevity.
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users(a)lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users(a)lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda --
www.linkedin.com/in/miconda Kamailio World Conference -- www.kamailioworld.com
12:30 p.m.
Hello,
I thought of looking briefly at the code to see what involves and
actually the counter with active calls per destination was there. It
needed only to print it in the rpc output.
One more remark came in my mind: just cherry picking the patch into an
older version may fail, because dispatcher got latency-based routing
support and that code affected the rpc code as well. If you want to just
try it, might be better to just test with master. The effective patch
itself should be a bit smaller, as I did some formatting to have more
suggestive attribute-name: attribute-value code formatting.
Cheers,
Daniel
On 08.06.18 11:15, Tim Bowyer wrote:
Hi Daniel,
Wow that was fast! Really appreciate your efforts.
I'm using a docker package at the moment so will need to jump through some hoops to
get the master build packaged for docker.
I'll keep you posted how I go.
Cheers once again and have a great weekend.
Tim Bowyer
-----Original Message-----
From: Daniel-Constantin Mierla <miconda(a)gmail.com>
Sent: Thursday, 7 June 2018 7:10 PM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>rg>; Tim Bowyer
<timbo(a)timbo.net.au>
Subject: Re: [SR-Users] Monitoring Dispatcher
Hello,
On 07.06.18 10:04, Daniel-Constantin Mierla wrote:
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference -- www.kamailioworld.com
Hello,
[...]
For the future, I can add an rpc command to dump those numbers
directly from dispatcher module when using with algorithm 10.
just implemented the
feature in master branch -- the active dialogs load should be printed in the rpc output
for each destination (RUNTIME => DLGLOAD field).
Can you test and report back if it gives what you expect? If you want to test with older
versions and backport the patch locally, the commit adding it is:
-
https://github.com/kamailio/kamailio/commit/513a176394247a3378ee218bf9df611…
Cheers,
Daniel
Cheers,
Daniel
On 07.06.18 09:04, Tim Bowyer wrote:
> Thanks for the prompt reply Alex!
>
> Trying to get my head around the best way to use the module.
> By the looks I need to statically create profiles which will be used as counting
groups.
> Since each destination is dynamically created thus named with a fairly random ID, I
can't see how this could work.
>
> Have tried using variables but I get a heap of errors. The process will only start
if I use static profile names.
>
> Is there another sneaky way to get around this? When a new container is spun up, a
new entry is added to the dispatcher table and the dispatcher reloaded.
> Likewise to trigger a container to start draining calls we remove from dispatcher
then reload before waiting for all calls to finish and stop the container.
>
> Cheers,
>
> Tim Bowyer
>
>
> -----Original Message-----
> From: sr-users <sr-users-bounces(a)lists.kamailio.org> On Behalf Of
> Alex Balashov
> Sent: Thursday, 7 June 2018 10:42 AM
> To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
> Subject: Re: [SR-Users] Monitoring Dispatcher
>
> It sounds like the dialog module might be your best bet.
>
> On June 6, 2018 10:40:38 PM EDT, Tim Bowyer <timbo(a)timbo.net.au> wrote:
>> Hi All,
>>
>> Currently trying to work out the best way to keep track of how many
>> calls are being sent to any given dispatcher destination.
>> I remember being able to do this years ago with the load balancer
>> module in OpenSIPS: opensipsctl fifo lb_list.
>>
>> Dispatching algorithm '10' seems to be the best fit for my
>> requirements, as I'm essentially wanting to send calls to a large
>> quantity of FreeSwitch docker containers acting as fax receiving nodes.
>> Equal weight, just filling them in some balanced fashion.
>>
>> Any hints or ideas would be much appreciated!
>>
>> Kind regards,
>>
>> Tim Bowyer
> -- Alex
>
> --
> Sent via mobile, please forgive typos and brevity.
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users(a)lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users(a)lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda --
www.linkedin.com/in/miconda Kamailio World Conference -- www.kamailioworld.com
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
2362
days inactive
2363
days old
6 comments
3 participants
participants (3)
-
Alex Balashov -
Daniel-Constantin Mierla -
Tim Bowyer