30 Mar
2021
30 Mar
'21
6:49 p.m.
Hello Community,
There is a module dispatcher and sharing algorithm 11 that features
the ability to redistribute load when the host is enabled or disabled
that is quite valuable for me.
In the test lab I faced unexpected behavior:
- when I add to group <=25 hosts algorithm behaves as per description.
- when a group includes 26 or more hosts, and 100 calls are done for
instance, then about 25 go to the first host and 75 are distributed
among the rest of hosts.
Expected behavior: all hosts of the group having the same rweight
value must receive the same amount of calls no mater what number of
hosts is in the group.
Could you please to help to figure out what is wrong and why when the
dispatcher group consists of 26+ hosts dispatching algorithm 11
behaves differently than when group consists of 25 or less of hosts?
Some configuration notes:
# module configs
modparam("dispatcher", "list_file",
"/etc/kamailio/dispatcher.list")
modparam("dispatcher", "flags", 2)
modparam("dispatcher", "ds_ping_method", "OPTIONS")
modparam("dispatcher", "ds_probing_threshold", 3)
modparam("dispatcher", "ds_inactive_threshold", 10)
modparam("dispatcher", "ds_probing_mode", 3)
modparam("dispatcher", "ds_ping_interval", 10)
modparam("dispatcher", "ds_ping_reply_codes",
"501,403,404,400,200")
modparam("dispatcher", "ds_ping_from",DS_PING_FROM_PARAM)
modparam("dispatcher", "use_default", 0)
# dispatching algorithm call
if ( ds_is_from_list("101")) {
sl_send_reply("100","My calls");
ds_select_dst("100", "11");
return;
}
# dispatcher list group config
100 sip:10.60.27.123:7000 0 10 rweight=50
100 sip:10.60.27.123:7001 0 10 rweight=50
100 sip:10.60.27.123:7002 0 10 rweight=50
100 sip:10.60.27.123:7003 0 10 rweight=50
100 sip:10.60.27.123:7004 0 10 rweight=50
100 sip:10.60.27.123:7005 0 10 rweight=50
100 sip:10.60.27.123:7006 0 10 rweight=50
100 sip:10.60.27.123:7007 0 10 rweight=50
100 sip:10.60.27.123:7008 0 10 rweight=50
100 sip:10.60.27.123:7009 0 10 rweight=50
100 sip:10.60.27.123:7010 0 10 rweight=50
100 sip:10.60.27.123:7011 0 10 rweight=50
100 sip:10.60.27.123:7012 0 10 rweight=50
100 sip:10.60.27.123:7013 0 10 rweight=50
100 sip:10.60.27.123:7014 0 10 rweight=50
100 sip:10.60.27.123:7015 0 10 rweight=50
100 sip:10.60.27.123:7016 0 10 rweight=50
100 sip:10.60.27.123:7017 0 10 rweight=50
100 sip:10.60.27.123:7018 0 10 rweight=50
100 sip:10.60.27.123:7019 0 10 rweight=50
100 sip:10.60.27.123:7020 0 10 rweight=50
100 sip:10.60.27.123:7021 0 10 rweight=50
100 sip:10.60.27.123:7022 0 10 rweight=50
100 sip:10.60.27.123:7023 0 10 rweight=50
100 sip:10.60.27.123:7024 0 10 rweight=50
Kamailio version:
kamailio -v
version: kamailio 5.4.4 (x86_64/linux) e16352
flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC,
F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX,
FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR,
USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE
1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: e16352
compiled on 15:56:46 Feb 15 2021 with gcc 4.8.5
System info
CentOS Linux release 7.7.1908 (Core)
Linux test-carrier-1.loc 3.10.0-1062.4.1.el7.x86_64 #1 SMP Fri Oct 18
17:15:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
30 Mar
30 Mar
7:57 p.m.
Hi Ivan, must be a limitation/problem in the computation, can you open an
issue.
Since I have built on top of algorithm 11, I could have a look, we may also
notify the original author to see what can be done.
On Tue, Mar 30, 2021 at 8:52 AM Ivan Matvieiev <i.matvieiev(a)kwebbl.com>
wrote:
Hello Community,
There is a module dispatcher and sharing algorithm 11 that features
the ability to redistribute load when the host is enabled or disabled
that is quite valuable for me.
In the test lab I faced unexpected behavior:
- when I add to group <=25 hosts algorithm behaves as per description.
- when a group includes 26 or more hosts, and 100 calls are done for
instance, then about 25 go to the first host and 75 are distributed
among the rest of hosts.
Expected behavior: all hosts of the group having the same rweight
value must receive the same amount of calls no mater what number of
hosts is in the group.
Could you please to help to figure out what is wrong and why when the
dispatcher group consists of 26+ hosts dispatching algorithm 11
behaves differently than when group consists of 25 or less of hosts?
Some configuration notes:
# module configs
modparam("dispatcher", "list_file",
"/etc/kamailio/dispatcher.list")
modparam("dispatcher", "flags", 2)
modparam("dispatcher", "ds_ping_method", "OPTIONS")
modparam("dispatcher", "ds_probing_threshold", 3)
modparam("dispatcher", "ds_inactive_threshold", 10)
modparam("dispatcher", "ds_probing_mode", 3)
modparam("dispatcher", "ds_ping_interval", 10)
modparam("dispatcher", "ds_ping_reply_codes",
"501,403,404,400,200")
modparam("dispatcher", "ds_ping_from",DS_PING_FROM_PARAM)
modparam("dispatcher", "use_default", 0)
# dispatching algorithm call
if ( ds_is_from_list("101")) {
sl_send_reply("100","My calls");
ds_select_dst("100", "11");
return;
}
# dispatcher list group config
100 sip:10.60.27.123:7000 0 10 rweight=50
100 sip:10.60.27.123:7001 0 10 rweight=50
100 sip:10.60.27.123:7002 0 10 rweight=50
100 sip:10.60.27.123:7003 0 10 rweight=50
100 sip:10.60.27.123:7004 0 10 rweight=50
100 sip:10.60.27.123:7005 0 10 rweight=50
100 sip:10.60.27.123:7006 0 10 rweight=50
100 sip:10.60.27.123:7007 0 10 rweight=50
100 sip:10.60.27.123:7008 0 10 rweight=50
100 sip:10.60.27.123:7009 0 10 rweight=50
100 sip:10.60.27.123:7010 0 10 rweight=50
100 sip:10.60.27.123:7011 0 10 rweight=50
100 sip:10.60.27.123:7012 0 10 rweight=50
100 sip:10.60.27.123:7013 0 10 rweight=50
100 sip:10.60.27.123:7014 0 10 rweight=50
100 sip:10.60.27.123:7015 0 10 rweight=50
100 sip:10.60.27.123:7016 0 10 rweight=50
100 sip:10.60.27.123:7017 0 10 rweight=50
100 sip:10.60.27.123:7018 0 10 rweight=50
100 sip:10.60.27.123:7019 0 10 rweight=50
100 sip:10.60.27.123:7020 0 10 rweight=50
100 sip:10.60.27.123:7021 0 10 rweight=50
100 sip:10.60.27.123:7022 0 10 rweight=50
100 sip:10.60.27.123:7023 0 10 rweight=50
100 sip:10.60.27.123:7024 0 10 rweight=50
Kamailio version:
kamailio -v
version: kamailio 5.4.4 (x86_64/linux) e16352
flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC,
F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX,
FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR,
USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE
1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: e16352
compiled on 15:56:46 Feb 15 2021 with gcc 4.8.5
System info
CentOS Linux release 7.7.1908 (Core)
Linux test-carrier-1.loc 3.10.0-1062.4.1.el7.x86_64 #1 SMP Fri Oct 18
17:15:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
9:34 p.m.
Hello,
there was an issue on the tracker, but this looks like the
redistribution due to percentage not being an integer number. I
referred to the docs (being noted there), closed the issue and pointed
to sr-users for further discussions.
So, for example, if there are 30 routes each with rweight of 50, that
means total rweight of 1500. With that, each route has the percentage of
50*100/1500=3.33, which is rounded to 3, meaning that each destination
gets 3 calls in 100, total 90, with the last one (which can be the first
in the dispatcher list file, depending on internal sorting and instert)
getting the remaining 10, overall 13 go to this route (so 19 routes will
get 3 calls, and 1 will get 13 calls). Now, depending on the number of
routes, one of them may get a different value, but the fact is that if
the percentage isn't an integer number, then the distribution is not
equal for one of them. For example, with the 6 routes:
total rweight => 6 * 50 = 300; then percentage per route is 50*100/300 =
16.6, rounded to 16, meaning one will get 20.
You may want to do a double check of the rweight algorithm code, I
haven't implemented it, but for weight the above remarks apply.
That was discussed in the past on the mailing list, and very likely it
is not a bug also in this case, but how the distribution can be spread
across 100 calls.
Even more, for r/weight algorithms, it really makes no sense to use them
when there are so many routes with same weight, practically on more than
50, each one will get 1 call and the last in the memory least will get
51. So one gets more than 50% of the calls. From the other perspective,
this is not even feasible to route to all of them in the same step,
because by default kamailio can create 12 branches for a request, with a
maximum configurable value of 31 (iirc). I think round robin or call
load distribution is better for such large number of routes.
Cheers,
Daniel
On 30.03.21 18:57, Julien Chavanton wrote:
Hi Ivan, must be a limitation/problem in the
computation, can you open
an issue.
Since I have built on top of algorithm 11, I could have a look, we may
also notify the original author to see what can be done.
On Tue, Mar 30, 2021 at 8:52 AM Ivan Matvieiev <i.matvieiev(a)kwebbl.com
<mailto:i.matvieiev@kwebbl.com>> wrote:
Hello Community,
There is a module dispatcher and sharing algorithm 11 that features
the ability to redistribute load when the host is enabled or disabled
that is quite valuable for me.
In the test lab I faced unexpected behavior:
- when I add to group <=25 hosts algorithm behaves as per description.
- when a group includes 26 or more hosts, and 100 calls are done for
instance, then about 25 go to the first host and 75 are distributed
among the rest of hosts.
Expected behavior: all hosts of the group having the same rweight
value must receive the same amount of calls no mater what number of
hosts is in the group.
Could you please to help to figure out what is wrong and why when the
dispatcher group consists of 26+ hosts dispatching algorithm 11
behaves differently than when group consists of 25 or less of hosts?
Some configuration notes:
# module configs
modparam("dispatcher", "list_file",
"/etc/kamailio/dispatcher.list")
modparam("dispatcher", "flags", 2)
modparam("dispatcher", "ds_ping_method", "OPTIONS")
modparam("dispatcher", "ds_probing_threshold", 3)
modparam("dispatcher", "ds_inactive_threshold", 10)
modparam("dispatcher", "ds_probing_mode", 3)
modparam("dispatcher", "ds_ping_interval", 10)
modparam("dispatcher", "ds_ping_reply_codes",
"501,403,404,400,200")
modparam("dispatcher", "ds_ping_from",DS_PING_FROM_PARAM)
modparam("dispatcher", "use_default", 0)
# dispatching algorithm call
if ( ds_is_from_list("101")) {
sl_send_reply("100","My calls");
ds_select_dst("100", "11");
return;
}
# dispatcher list group config
100 sip:10.60.27.123:7000 <http://10.60.27.123:7000> 0 10 rweight=50
100 sip:10.60.27.123:7001 <http://10.60.27.123:7001> 0 10 rweight=50
100 sip:10.60.27.123:7002 <http://10.60.27.123:7002> 0 10 rweight=50
100 sip:10.60.27.123:7003 <http://10.60.27.123:7003> 0 10 rweight=50
100 sip:10.60.27.123:7004 <http://10.60.27.123:7004> 0 10 rweight=50
100 sip:10.60.27.123:7005 <http://10.60.27.123:7005> 0 10 rweight=50
100 sip:10.60.27.123:7006 <http://10.60.27.123:7006> 0 10 rweight=50
100 sip:10.60.27.123:7007 <http://10.60.27.123:7007> 0 10 rweight=50
100 sip:10.60.27.123:7008 <http://10.60.27.123:7008> 0 10 rweight=50
100 sip:10.60.27.123:7009 <http://10.60.27.123:7009> 0 10 rweight=50
100 sip:10.60.27.123:7010 <http://10.60.27.123:7010> 0 10 rweight=50
100 sip:10.60.27.123:7011 <http://10.60.27.123:7011> 0 10 rweight=50
100 sip:10.60.27.123:7012 <http://10.60.27.123:7012> 0 10 rweight=50
100 sip:10.60.27.123:7013 <http://10.60.27.123:7013> 0 10 rweight=50
100 sip:10.60.27.123:7014 <http://10.60.27.123:7014> 0 10 rweight=50
100 sip:10.60.27.123:7015 <http://10.60.27.123:7015> 0 10 rweight=50
100 sip:10.60.27.123:7016 <http://10.60.27.123:7016> 0 10 rweight=50
100 sip:10.60.27.123:7017 <http://10.60.27.123:7017> 0 10 rweight=50
100 sip:10.60.27.123:7018 <http://10.60.27.123:7018> 0 10 rweight=50
100 sip:10.60.27.123:7019 <http://10.60.27.123:7019> 0 10 rweight=50
100 sip:10.60.27.123:7020 <http://10.60.27.123:7020> 0 10 rweight=50
100 sip:10.60.27.123:7021 <http://10.60.27.123:7021> 0 10 rweight=50
100 sip:10.60.27.123:7022 <http://10.60.27.123:7022> 0 10 rweight=50
100 sip:10.60.27.123:7023 <http://10.60.27.123:7023> 0 10 rweight=50
100 sip:10.60.27.123:7024 <http://10.60.27.123:7024> 0 10 rweight=50
Kamailio version:
kamailio -v
version: kamailio 5.4.4 (x86_64/linux) e16352
flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC,
F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX,
FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR,
USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE
1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: e16352
compiled on 15:56:46 Feb 15 2021 with gcc 4.8.5
System info
CentOS Linux release 7.7.1908 (Core)
Linux test-carrier-1.loc 3.10.0-1062.4.1.el7.x86_64 #1 SMP Fri Oct 18
17:15:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<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
Funding: https://www.paypal.me/dcmierla
31 Mar
31 Mar
6:25 p.m.
Hello Daniel
Yes, it was clear to me, why my TT was closed.
Apologise for not starting with the mailing list.
Regarding algorithm 11.
Yes, you are right.
To sum up, if you want to have equal call distribution, the number of
hosts must provide integer value when 100 is divided by it.
Thus, the number of hosts permitting equal call distribution is: 1, 2,
4, 5, 10, 20, 25, 50, 100.
With best regards
Ivan
On Tue, Mar 30, 2021 at 9:36 PM Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
Hello,
there was an issue on the tracker, but this looks like the redistribution due to
percentage not being an integer number. I referred to the docs (being noted there),
closed the issue and pointed to sr-users for further discussions.
So, for example, if there are 30 routes each with rweight of 50, that means total rweight
of 1500. With that, each route has the percentage of 50*100/1500=3.33, which is rounded to
3, meaning that each destination gets 3 calls in 100, total 90, with the last one (which
can be the first in the dispatcher list file, depending on internal sorting and instert)
getting the remaining 10, overall 13 go to this route (so 19 routes will get 3 calls, and
1 will get 13 calls). Now, depending on the number of routes, one of them may get a
different value, but the fact is that if the percentage isn't an integer number, then
the distribution is not equal for one of them. For example, with the 6 routes:
total rweight => 6 * 50 = 300; then percentage per route is 50*100/300 = 16.6, rounded
to 16, meaning one will get 20.
You may want to do a double check of the rweight algorithm code, I haven't
implemented it, but for weight the above remarks apply.
That was discussed in the past on the mailing list, and very likely it is not a bug also
in this case, but how the distribution can be spread across 100 calls.
Even more, for r/weight algorithms, it really makes no sense to use them when there are
so many routes with same weight, practically on more than 50, each one will get 1 call and
the last in the memory least will get 51. So one gets more than 50% of the calls. From the
other perspective, this is not even feasible to route to all of them in the same step,
because by default kamailio can create 12 branches for a request, with a maximum
configurable value of 31 (iirc). I think round robin or call load distribution is better
for such large number of routes.
Cheers,
Daniel
On 30.03.21 18:57, Julien Chavanton wrote:
Hi Ivan, must be a limitation/problem in the computation, can you open an issue.
Since I have built on top of algorithm 11, I could have a look, we may also notify the
original author to see what can be done.
On Tue, Mar 30, 2021 at 8:52 AM Ivan Matvieiev <i.matvieiev(a)kwebbl.com> wrote:
Hello Community,
There is a module dispatcher and sharing algorithm 11 that features
the ability to redistribute load when the host is enabled or disabled
that is quite valuable for me.
In the test lab I faced unexpected behavior:
- when I add to group <=25 hosts algorithm behaves as per description.
- when a group includes 26 or more hosts, and 100 calls are done for
instance, then about 25 go to the first host and 75 are distributed
among the rest of hosts.
Expected behavior: all hosts of the group having the same rweight
value must receive the same amount of calls no mater what number of
hosts is in the group.
Could you please to help to figure out what is wrong and why when the
dispatcher group consists of 26+ hosts dispatching algorithm 11
behaves differently than when group consists of 25 or less of hosts?
Some configuration notes:
# module configs
modparam("dispatcher", "list_file",
"/etc/kamailio/dispatcher.list")
modparam("dispatcher", "flags", 2)
modparam("dispatcher", "ds_ping_method", "OPTIONS")
modparam("dispatcher", "ds_probing_threshold", 3)
modparam("dispatcher", "ds_inactive_threshold", 10)
modparam("dispatcher", "ds_probing_mode", 3)
modparam("dispatcher", "ds_ping_interval", 10)
modparam("dispatcher", "ds_ping_reply_codes",
"501,403,404,400,200")
modparam("dispatcher", "ds_ping_from",DS_PING_FROM_PARAM)
modparam("dispatcher", "use_default", 0)
# dispatching algorithm call
if ( ds_is_from_list("101")) {
sl_send_reply("100","My calls");
ds_select_dst("100", "11");
return;
}
# dispatcher list group config
100 sip:10.60.27.123:7000 0 10 rweight=50
100 sip:10.60.27.123:7001 0 10 rweight=50
100 sip:10.60.27.123:7002 0 10 rweight=50
100 sip:10.60.27.123:7003 0 10 rweight=50
100 sip:10.60.27.123:7004 0 10 rweight=50
100 sip:10.60.27.123:7005 0 10 rweight=50
100 sip:10.60.27.123:7006 0 10 rweight=50
100 sip:10.60.27.123:7007 0 10 rweight=50
100 sip:10.60.27.123:7008 0 10 rweight=50
100 sip:10.60.27.123:7009 0 10 rweight=50
100 sip:10.60.27.123:7010 0 10 rweight=50
100 sip:10.60.27.123:7011 0 10 rweight=50
100 sip:10.60.27.123:7012 0 10 rweight=50
100 sip:10.60.27.123:7013 0 10 rweight=50
100 sip:10.60.27.123:7014 0 10 rweight=50
100 sip:10.60.27.123:7015 0 10 rweight=50
100 sip:10.60.27.123:7016 0 10 rweight=50
100 sip:10.60.27.123:7017 0 10 rweight=50
100 sip:10.60.27.123:7018 0 10 rweight=50
100 sip:10.60.27.123:7019 0 10 rweight=50
100 sip:10.60.27.123:7020 0 10 rweight=50
100 sip:10.60.27.123:7021 0 10 rweight=50
100 sip:10.60.27.123:7022 0 10 rweight=50
100 sip:10.60.27.123:7023 0 10 rweight=50
100 sip:10.60.27.123:7024 0 10 rweight=50
Kamailio version:
kamailio -v
version: kamailio 5.4.4 (x86_64/linux) e16352
flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC,
F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX,
FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR,
USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE
1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: e16352
compiled on 15:56:46 Feb 15 2021 with gcc 4.8.5
System info
CentOS Linux release 7.7.1908 (Core)
Linux test-carrier-1.loc 3.10.0-1062.4.1.el7.x86_64 #1 SMP Fri Oct 18
17:15:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
_______________________________________________
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
Funding: https://www.paypal.me/dcmierla
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
1332
days inactive
1333
days old
3 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Ivan Matvieiev -
Julien Chavanton