[OpenSIPS-Users] OpenSips compilation failing

[Chandan PR]

Hello Everyone,

We are using Opensips 1.9.2 in our production environment for nearly 6-7
years now.
We have come across a need to enable mi_xml_rpc module to get Opensips
stats.

While trying to recompile Opensips we are ending up in the below error:

Makefile.defs:742: You are using an old and unsupported gcc version  (5.4),
compile at your own risk!

cd menuconfig; make ; cd ..

make[1]: Entering directory '/usr/local/src/opensips-1.9.2-tls/menuconfig'

gcc -o configure -g -Wall -DMENUCONFIG_CFG_PATH=\"menuconfig/configs/\"
-DMENUCONFIG_GEN_PATH=\"etc/\" -DMENUCONFIG_HAVE_SOURCES=1  cfg.o curses.o
items.o commands.o menus.o parser.o main.o -lncurses

make[1]: Leaving directory '/usr/local/src/opensips-1.9.2-tls/menuconfig'

./menuconfig/configure --local

make[1]: Entering directory '/usr/local/src/opensips-1.9.2-tls'

Linking opensips

socket_info.o: In function `fix_socket_list':

/usr/local/src/opensips-1.9.2-tls/socket_info.c:586: undefined reference to
`resolvehost'

/usr/local/src/opensips-1.9.2-tls/socket_info.c:674: undefined reference to
`resolvehost'

/usr/local/src/opensips-1.9.2-tls/socket_info.c:644: undefined reference to
`rev_resolvehost'

route.o: In function `fix_actions':

/usr/local/src/opensips-1.9.2-tls/route.c:459: undefined reference to
`resolvehost'

route.o: In function `comp_ip':

/usr/local/src/opensips-1.9.2-tls/route.c:1076: undefined reference to
`rev_resolvehost'

/usr/local/src/opensips-1.9.2-tls/route.c:1061: undefined reference to
`resolvehost'

timer.o: In function `start_timer_processes':

/usr/local/src/opensips-1.9.2-tls/timer.c:593: undefined reference to
`inc_init_timer'

transformations.o: In function `tr_eval_ip':

/usr/local/src/opensips-1.9.2-tls/transformations.c:1206: undefined
reference to `resolvehost'

mem/f_malloc.o: In function `fm_malloc':

/usr/local/src/opensips-1.9.2-tls/mem/f_malloc.c:407: undefined reference
to `pkg_threshold_check'

/usr/local/src/opensips-1.9.2-tls/mem/f_malloc.c:374: undefined reference
to `pkg_threshold_check'

mem/f_malloc.o: In function `fm_free':

/usr/local/src/opensips-1.9.2-tls/mem/f_malloc.c:467: undefined reference
to `pkg_threshold_check'

mem/f_malloc.o: In function `fm_realloc':

/usr/local/src/opensips-1.9.2-tls/mem/f_malloc.c:588: undefined reference
to `pkg_threshold_check'

/usr/local/src/opensips-1.9.2-tls/mem/f_malloc.c:500: undefined reference
to `pkg_threshold_check'

db/db_query.o: In function `db_do_insert':

/usr/local/src/opensips-1.9.2-tls/db/db_query.c:294: undefined reference to
`cleanup_rows'

collect2: error: ld returned 1 exit status

Makefile.rules:35: recipe for target 'opensips' failed

make[1]: *** [opensips] Error 1

make[1]: Leaving directory '/usr/local/src/opensips-1.9.2-tls'

Any help on how to resolve this would be greatly appreciated.

PS: Currently we won't be able to move the production environment to latest
version. So need to enable mi_xml_rpc module on the version 1.9.2

-- 

Regards,
Chandan Ravishankar
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] OpenSips Load balancer. - Overcome limitations of Call Driven Load Balancing

[Chandan PR]

Hi Jon, and All

While I was thinking through this approach, one question popped up in my
thought.

Since we run on a full load most of the hours, even if we limit the number
of calls to the faulty destination, it is very much possible that call
drain can happen as the faulty destination errors out immediately.

The only option to make sure the faulty destination doesn't get any calls
is by disabling it right..

Let me know what you think.


On Fri, Jul 24, 2020 at 7:42 PM Jon Abrams  wrote:

> Hi Chandan,
>
> There may be something else purpose built for this, but you can use
> the dialog profiles to track and limit the port usage:
>
> set_dlg_profile("outcarrier","$avp(out_carrier_id)");
>
> if ($avp(out_max_call_limit) > 0)
> {
> set_dlg_profile("profile","$avp(out_qos_profile_id)");
> if
> (get_profile_size("profile","$avp(out_qos_profile_id)","$var(out_gw_count)"))
> {
> if ($var(out_gw_count)>$avp(out_max_call_limit))
> {
> xlog("LIMIT: Call $ci - Max call limit hit by
> $avp(src_addr) on QosProfile $avp(out_qos_profile_id) to gw
> $avp(out_gw_id)\n");
> return(-1);
> }
> }
> }
>
> On Fri, Jul 24, 2020 at 8:55 AM Chandan PR  wrote:
> >
> > Hello Everyone,
> >
> > Currently, we are using Open Sips Load balancer in Call Driven load
> balancing.
> >
> > Our scenario is as below:
> >
> > D - Total Destinations configured at OpenSips
> > P - No of Ports/Sessions Each Destination can handle concurrently
> > C - Total Capacity = D*P
> >
> > We have a Call Loader which loads calls to OpenSips at C and as when the
> result comes further calls get loaded.
> > For some reason, if any destination is not in the right state and sends
> error responses without accepting calls, this introduces a drain scenario.
> > In the drain scenario where all new calls are given to the faulty
> destination as it has more availability.
> >
> > We are currently handling this by
> >
> > Running the loader at 80% of C
> > Disabling the destination in Opensips if 75% of the calls fail for the
> particular destination (Attached loadbalancer.cfg file).
> >
> >
> > But even in this case, it is possible that may call error out as the
> destination is free and calls are loaded.
> >
> > We would like to avoid this scenario to the max possible extent by
> limiting the number of calls we send to this particular destination.
> >
> > Couple of options I see are as below:
> >
> > Wait for a brief period before sending the response to loader when the
> error happens
> > Make OpenSips aware of the destination capacity and adjust ports
> accordingly
> >
> > Write a custom script to poll destination capacity and use MI functions
> to adjust accordingly
> > Or is there any possibility to integrate similar to FreeSwitch driven
> routing
> >
> > Are there any other possibilities of adjusting the OpenSips capacity
> dynamically or make it limit the calls sent to the particular destination?
> >
> > --
> >
> > Regards,
> > Chandan Ravishankar
> > ___
> > Users mailing list
> > Users@lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


-- 

Regards,
Chandan Ravishankar <https://about.me/chandanpr>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] OpenSips Load balancer. - Overcome limitations of Call Driven Load Balancing

[Chandan PR]

Thanks for the response Jon.
Let me have a look at it.

On Fri, Jul 24, 2020 at 7:42 PM Jon Abrams  wrote:

> Hi Chandan,
>
> There may be something else purpose built for this, but you can use
> the dialog profiles to track and limit the port usage:
>
> set_dlg_profile("outcarrier","$avp(out_carrier_id)");
>
> if ($avp(out_max_call_limit) > 0)
> {
> set_dlg_profile("profile","$avp(out_qos_profile_id)");
> if
> (get_profile_size("profile","$avp(out_qos_profile_id)","$var(out_gw_count)"))
> {
> if ($var(out_gw_count)>$avp(out_max_call_limit))
> {
> xlog("LIMIT: Call $ci - Max call limit hit by
> $avp(src_addr) on QosProfile $avp(out_qos_profile_id) to gw
> $avp(out_gw_id)\n");
> return(-1);
> }
> }
> }
>
> On Fri, Jul 24, 2020 at 8:55 AM Chandan PR  wrote:
> >
> > Hello Everyone,
> >
> > Currently, we are using Open Sips Load balancer in Call Driven load
> balancing.
> >
> > Our scenario is as below:
> >
> > D - Total Destinations configured at OpenSips
> > P - No of Ports/Sessions Each Destination can handle concurrently
> > C - Total Capacity = D*P
> >
> > We have a Call Loader which loads calls to OpenSips at C and as when the
> result comes further calls get loaded.
> > For some reason, if any destination is not in the right state and sends
> error responses without accepting calls, this introduces a drain scenario.
> > In the drain scenario where all new calls are given to the faulty
> destination as it has more availability.
> >
> > We are currently handling this by
> >
> > Running the loader at 80% of C
> > Disabling the destination in Opensips if 75% of the calls fail for the
> particular destination (Attached loadbalancer.cfg file).
> >
> >
> > But even in this case, it is possible that may call error out as the
> destination is free and calls are loaded.
> >
> > We would like to avoid this scenario to the max possible extent by
> limiting the number of calls we send to this particular destination.
> >
> > Couple of options I see are as below:
> >
> > Wait for a brief period before sending the response to loader when the
> error happens
> > Make OpenSips aware of the destination capacity and adjust ports
> accordingly
> >
> > Write a custom script to poll destination capacity and use MI functions
> to adjust accordingly
> > Or is there any possibility to integrate similar to FreeSwitch driven
> routing
> >
> > Are there any other possibilities of adjusting the OpenSips capacity
> dynamically or make it limit the calls sent to the particular destination?
> >
> > --
> >
> > Regards,
> > Chandan Ravishankar
> > ___
> > Users mailing list
> > Users@lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


-- 

Regards,
Chandan Ravishankar <https://about.me/chandanpr>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] OpenSips Load balancer. - Overcome limitations of Call Driven Load Balancing

[Chandan PR]

Hello Everyone,

Currently, we are using Open Sips Load balancer in Call Driven load
balancing .

Our scenario is as below:

*D* - Total Destinations configured at OpenSips
*P* - No of Ports/Sessions Each Destination can handle concurrently
*C* - Total Capacity = D*P

We have a Call Loader which loads calls to OpenSips at C and as when the
result comes further calls get loaded.
For some reason, if any destination is not in the right state and sends
error responses without accepting calls, this introduces a drain scenario.
In the drain scenario where all new calls are given to the faulty
destination as it has more availability.

We are currently handling this by

   1. Running the loader at 80% of C
   2. Disabling the destination in Opensips if 75% of the calls fail for
   the particular destination (Attached loadbalancer.cfg file).


But even in this case, it is possible that may call error out as the
destination is free and calls are loaded.

We would like to avoid this scenario to the max possible extent by limiting
the number of calls we send to this particular destination.

Couple of options I see are as below:

   1. Wait for a brief period before sending the response to loader when
   the error happens
   2. Make OpenSips aware of the destination capacity and adjust ports
   accordingly
  - Write a custom script to poll destination capacity and use MI
  functions to adjust accordingly
  - Or is there any possibility to integrate similar to FreeSwitch
  driven routing
  


Are there any other possibilities of adjusting the OpenSips capacity
dynamically or make it limit the calls sent to the particular destination?

-- 

Regards,
Chandan Ravishankar 


loadbalancer.cfg
Description: Binary data
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] OpenSips FIFO command - frequency advise

[Chandan PR]

Hi,

As part of the load balancer script, we are publishing some custom
statistics per destination (which can help us in identifying nodes that may
go bad).

We are planning to use the output of opensipsctl fifo get_statistics
dynamic: command as a feedback loop to the call publisher.

Any advice on the frequency considerations we should have for running fifo
commands?
Can we afford to run this every minute without much impact on the
performance?

Wanted to start on a good frequency for running load tests to understand
the impact.

Thanks in advance.
-- 

Regards,
Chandan Ravishankar 
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Load Balancer Hooks

[Chandan PR]

Thanks for the info, Ben. Let me have a look.

On Wed, Jul 8, 2020 at 7:34 PM Ben Newlin  wrote:

> I don’t know if there is anything in 1.9, which is quite old, but in 2.0+
> there is an event that you can subscribe to.
>
>
>
>
> https://opensips.org/docs/modules/2.4.x/load_balancer.html#event_E_LOAD_BALANCER_STATUS
>
>
>
> Ben Newlin
>
>
>
> *From: *Users  on behalf of Chandan PR <
> chandan...@webshar.org>
> *Reply-To: *OpenSIPS users mailling list 
> *Date: *Wednesday, July 8, 2020 at 10:00 AM
> *To: *OpenSIPS users mailling list 
> *Cc: *Naveen Kumar 
> *Subject: *[OpenSIPS-Users] Load Balancer Hooks
>
>
>
> Hi,
>
>
>
> Is it possible to add hooks to notify an endpoint
>
>- when a particular destination is disabled (via lb_disable())
>- when a particular destination is enabled after a successful probing
>
> This is needed for us to slow down the requests to OpenSips when few
> destinations are down. Without this feedback loop, we won't be knowing if
> we need to limit the number of calls we need to send.
>
>
>
> We are currently on Opensips 1.9.
>
> --
>
>
>
> Regards,
>
> Chandan Ravishankar <https://about.me/chandanpr>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


-- 

Regards,
Chandan Ravishankar <https://about.me/chandanpr>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Load Balancer Hooks

[Chandan PR]

Hi,

Is it possible to add hooks to notify an endpoint

   - when a particular destination is disabled (via lb_disable())
   - when a particular destination is enabled after a successful probing

This is needed for us to slow down the requests to OpenSips when few
destinations are down. Without this feedback loop, we won't be knowing if
we need to limit the number of calls we need to send.

We are currently on Opensips 1.9.
-- 

Regards,
Chandan Ravishankar 
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Load Balancer - Checking Node Health

[Chandan PR]

Thanks a lot Razvan. Will try them and keep the group posted about the
results.

On Wed, Jan 11, 2017 at 2:01 PM, Răzvan Crainea  wrote:

> Hi, Chandan!
>
> Is there any way you could monitor the endpoints? If so, you can use the
> load balancer pinging, that will automatically disable the end point when
> it is not responding, and monitor the state over MI.
>
> If there is no way you monitor the endoints, you could:
> 1. Check the tm transactions ended with 4xx status. If you see a spike,
> send an alert. The comand to do that is:
> opensipsctl fifo get_statistics 4xx_transactions
>
> 2. Create your own statistics in the script based on the endpoint. In the
> script, do something like this:
> if (t_check_status("486"))
> update_stat("$stat(tran_486_$si)", "+1");
>
> Again, monitor these statistics over MI and if you see spikes, send alerts.
>
> These are the solutions I am thinking of. Hope they are helpful.
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Solutionswww.opensips-solutions.com
>
> On 01/11/2017 08:51 AM, Chandan PR wrote:
>
> Hi,
>
> Recently one of our endpoints stopped responding and due to which nearly
> almost all of the calls ended up in 486.
>
> Is there any functions we can use to monitor the response codes per node
> over a duration so that we can raise an alert to take corrective actions in
> such cases.
>
> *The version of OpenSips we are using is 1.9.x*
>
> Regards,
> Chandan
>
>
> ___
> Users mailing 
> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Load Balancer - Checking Node Health

[Chandan PR]

Hi,

Recently one of our endpoints stopped responding and due to which nearly
almost all of the calls ended up in 486.

Is there any functions we can use to monitor the response codes per node
over a duration so that we can raise an alert to take corrective actions in
such cases.

*The version of OpenSips we are using is 1.9.x*

Regards,
Chandan
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Load Balancer - Delay in clearing dialogs

[Chandan PR]

Thanks for the input Bogdan.

We found that the problem was due to some calls failing to get the response.

Since we had the dialog timeout of 6 hours, which was not in sync with
application logic, we were sending more calls than available destinations.

We have updated the dialog timeout in par with the application and this
should resolve the issue for us.

Regards,
Chandan

On Wed, Aug 17, 2016 at 3:15 PM, Bogdan-Andrei Iancu 
wrote:

> Hi Chandan,
>
> Could you check what is the status of the calls (see the "State" field) ?
> I guess the call are listed in state 5 (terminated) - and this is the
> reason why you do not see them as counted by LB.
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>
> On 16.08.2016 12:47, Chandan PR wrote:
>
> Hi Guys,
>
> Opendsips Version : 1.9.x
>
> We have configured the load balancer with 8 ports.
>
> When the calls are ongoing, the lb_list shows the load balancer is running
> full.
>
> root@Dev-Chandan-Opensips-LB:/usr/local/opensips/sbin# ./opensipsctl fifo
> lb_list
> Destination:: sip:192.168.248.62:5060 id=152 group=1 enabled=yes
> auto-re=on
> Resource:: channel max=4 load=4
> Destination:: sip:192.168.248.64:5060 id=153 group=1 enabled=yes
> auto-re=on
> Resource:: channel max=4 load=4
>
> When I check the dialog_list, I see some older dialogs which are yet to be
> cleared.
>
> root@Dev-Chandan-Opensips-LB:/usr/local/opensips/sbin# ./opensipsctl fifo
> dlg_list | grep "callid"
> callid:: 14713396610041471339775929_ZTLT_931
> callid:: 14713396610151471339775929_ZTLT_937
> callid:: 14713396610221471339775929_ZTLT_942
> callid:: 14713396610081471339775929_ZTLT_933
> callid:: 14713396610181471339775929_ZTLT_939
> callid:: 14713396610191471339775929_ZTLT_940
> callid:: 14713396610131471339775929_ZTLT_936
> callid:: 14713396610031471339775929_ZTLT_930
> callid:: 14713396610061471339775929_ZTLT_932
> callid:: 14713396610161471339775929_ZTLT_938
> callid:: 14713396610271471339775929_ZTLT_945
> callid:: 14713396610371471339775929_ZTLT_951
> callid:: 14713396610101471339775929_ZTLT_934
> callid:: 14713396610311471339775929_ZTLT_947
> callid:: 14713396610211471339775929_ZTLT_941
> callid:: 14713396610241471339775929_ZTLT_943
> callid:: 14713396610341471339775929_ZTLT_949
> callid:: 14713396610011471339775929_ZTLT_929
> callid:: 14713396610111471339775929_ZTLT_935
> root@Dev-Chandan-Opensips-LB:/usr/local/opensips/sbin# ./opensipsctl fifo
> dlg_list | grep "callid" | wc -l
> 13
> root@Dev-Chandan-Opensips-LB:/usr/local/opensips/sbin#
>
> *Even when the lb_list shows the load as 0, I see some dialogs present and
> getting cleared after around 10-12 seconds.*
>
> What would be the impact of this delay in clearing the dialogs? Can this
> lead to lot many calls rejected with "Destination Full" (We are
> experiencing this issue in our production, where a huge number of calls
> rejected)?
>
> Is there any way to reduce this delay or clear the dialogs immediately?
>
> *Dialog Module Settings:*
>  DIALOG module
> loadmodule "dialog.so"
> modparam("dialog", "dlg_match_mode", 1)
> modparam("dialog", "default_timeout", 21600)  # 6 hours timeout
> modparam("dialog", "db_mode", 2)
> modparam("dialog", "db_url",
> "mysql://opensips:opensipsrw@localhost/opensips") #
>
>
> *Load Balancer Script:*
> #
> # $Id: opensips_loadbalancer.m4 9723 2013-02-01 15:10:50Z bogdan_iancu $
> #
> # OpenSIPS loadbalancer script
> # by OpenSIPS Solutions 
> #
> # This script was generated via "make menuconfig", from
> #   the "Load Balancer" scenario.
> # You can enable / disable more features / functionalities by
> #   re-generating the scenario with different options.
> #
> # Please refer to the Core CookBook at:
> #  http://www.opensips.org/Resources/DocsCookbooks
> # for a explanation of possible statements, functions and parameters.
> #
>
>
> ### Global Parameters #
>
> debug=3
> log_stderror=no
> log_facility=LOG_LOCAL1
>
> fork=yes
> children=4
>
> /* uncomment the following lines to enable debugging */
> #debug=6
> #fork=no
> #log_stderror=yes
>
> /* uncomment the next line to enable the auto temporary blacklisting of
>not available destinations (default disabled) */
> #disable_dns_blacklist=no
>
> /* uncomment the next line to enable IPv6 lookup after IPv4 dns
>lookup failures (default disabled) */
> #dns_try_ipv6=yes
>
> /* comment the next line to enable the auto discovery of local aliases
>ba

[OpenSIPS-Users] Load Balancer - Delay in clearing dialogs

[Chandan PR]

Hi Guys,

Opendsips Version : 1.9.x

We have configured the load balancer with 8 ports.

When the calls are ongoing, the lb_list shows the load balancer is running
full.

root@Dev-Chandan-Opensips-LB:/usr/local/opensips/sbin# ./opensipsctl fifo
lb_list
Destination:: sip:192.168.248.62:5060 id=152 group=1 enabled=yes auto-re=on
Resource:: channel max=4 load=4
Destination:: sip:192.168.248.64:5060 id=153 group=1 enabled=yes auto-re=on
Resource:: channel max=4 load=4

When I check the dialog_list, I see some older dialogs which are yet to be
cleared.

root@Dev-Chandan-Opensips-LB:/usr/local/opensips/sbin# ./opensipsctl fifo
dlg_list | grep "callid"
callid:: 14713396610041471339775929_ZTLT_931
callid:: 14713396610151471339775929_ZTLT_937
callid:: 14713396610221471339775929_ZTLT_942
callid:: 14713396610081471339775929_ZTLT_933
callid:: 14713396610181471339775929_ZTLT_939
callid:: 14713396610191471339775929_ZTLT_940
callid:: 14713396610131471339775929_ZTLT_936
callid:: 14713396610031471339775929_ZTLT_930
callid:: 14713396610061471339775929_ZTLT_932
callid:: 14713396610161471339775929_ZTLT_938
callid:: 14713396610271471339775929_ZTLT_945
callid:: 14713396610371471339775929_ZTLT_951
callid:: 14713396610101471339775929_ZTLT_934
callid:: 14713396610311471339775929_ZTLT_947
callid:: 14713396610211471339775929_ZTLT_941
callid:: 14713396610241471339775929_ZTLT_943
callid:: 14713396610341471339775929_ZTLT_949
callid:: 14713396610011471339775929_ZTLT_929
callid:: 14713396610111471339775929_ZTLT_935
root@Dev-Chandan-Opensips-LB:/usr/local/opensips/sbin# ./opensipsctl fifo
dlg_list | grep "callid" | wc -l
13
root@Dev-Chandan-Opensips-LB:/usr/local/opensips/sbin#

*Even when the lb_list shows the load as 0, I see some dialogs present and
getting cleared after around 10-12 seconds.*

What would be the impact of this delay in clearing the dialogs? Can this
lead to lot many calls rejected with "Destination Full" (We are
experiencing this issue in our production, where a huge number of calls
rejected)?

Is there any way to reduce this delay or clear the dialogs immediately?

*Dialog Module Settings:*
 DIALOG module
loadmodule "dialog.so"
modparam("dialog", "dlg_match_mode", 1)
modparam("dialog", "default_timeout", 21600)  # 6 hours timeout
modparam("dialog", "db_mode", 2)
modparam("dialog", "db_url",
"mysql://opensips:opensipsrw@localhost/opensips") #


*Load Balancer Script:*
#
# $Id: opensips_loadbalancer.m4 9723 2013-02-01 15:10:50Z bogdan_iancu $
#
# OpenSIPS loadbalancer script
# by OpenSIPS Solutions 
#
# This script was generated via "make menuconfig", from
#   the "Load Balancer" scenario.
# You can enable / disable more features / functionalities by
#   re-generating the scenario with different options.
#
# Please refer to the Core CookBook at:
#  http://www.opensips.org/Resources/DocsCookbooks
# for a explanation of possible statements, functions and parameters.
#


### Global Parameters #

debug=3
log_stderror=no
log_facility=LOG_LOCAL1

fork=yes
children=4

/* uncomment the following lines to enable debugging */
#debug=6
#fork=no
#log_stderror=yes

/* uncomment the next line to enable the auto temporary blacklisting of
   not available destinations (default disabled) */
#disable_dns_blacklist=no

/* uncomment the next line to enable IPv6 lookup after IPv4 dns
   lookup failures (default disabled) */
#dns_try_ipv6=yes

/* comment the next line to enable the auto discovery of local aliases
   based on revers DNS on IPs */
auto_aliases=no


listen=udp:192.168.248.111:5060   # CUSTOMIZE ME

disable_tcp=no
listen=tcp:192.168.248.111:5060   # CUSTOMIZE ME

disable_tls=yes




### Modules Section 

#set module path
mpath="/usr/local/opensips/lib64/opensips/modules/"



 SIGNALING module
loadmodule "signaling.so"

 StateLess module
loadmodule "sl.so"

 Transaction Module
loadmodule "tm.so"
modparam("tm", "fr_timer", 30)
modparam("tm", "fr_inv_timer", 120)
modparam("tm", "restart_fr_on_each_reply", 0)
modparam("tm", "onreply_avp_mode", 1)

 Record Route Module
loadmodule "rr.so"
/* do not append from tag to the RR (no need for this script) */
modparam("rr", "append_fromtag", 0)

 MAX ForWarD module
loadmodule "maxfwd.so"

 SIP MSG OPerationS module
loadmodule "sipmsgops.so"

 FIFO Management Interface
loadmodule "mi_fifo.so"
modparam("mi_fifo", "fifo_name", "/tmp/opensips_fifo")
modparam("mi_fifo", "fifo_mode", 0666)

 URI module
loadmodule "uri.so"
modparam("uri", "use_uri_table", 0)

 MYSQL module
loadmodule "db_mysql.so"

 AVPOPS module
loadmodule "avpops.so"

 ACCounting module
loadmodule "acc.so"
/* what special events should be accounted ? */
modparam("acc", "early_media", 0)
modparam("acc", "report_cancels", 0)
/* by default we do not adjust the direct of the sequential requests.
   if you enable this parameter, be sure the enable "append_fromtag"
   in "rr" module */
modparam("acc", "detect_direction", 0)
modparam("acc", "failed_transacti

[OpenSIPS-Users] OpenSips rejecting calls even though the destination is not disabled

[Chandan PR]

Hi Guys,

We are observing an issue where OpenSips is rejecting calls as Destination
Full, even when the destination is not disabled...

We are not sending too many calls for all the destinations to be full.

The script is as below:

#
# $Id: opensips_loadbalancer.m4 9723 2013-02-01 15:10:50Z bogdan_iancu $
#
# OpenSIPS loadbalancer script
# by OpenSIPS Solutions 
#
# This script was generated via "make menuconfig", from
#   the "Load Balancer" scenario.
# You can enable / disable more features / functionalities by
#   re-generating the scenario with different options.
#
# Please refer to the Core CookBook at:
#  http://www.opensips.org/Resources/DocsCookbooks
# for a explanation of possible statements, functions and parameters.
#


### Global Parameters #

debug=3
log_stderror=no
log_facility=LOG_LOCAL1

fork=yes
children=4

/* uncomment the following lines to enable debugging */
#debug=6
#fork=no
#log_stderror=yes

/* uncomment the next line to enable the auto temporary blacklisting of
   not available destinations (default disabled) */
#disable_dns_blacklist=no

/* uncomment the next line to enable IPv6 lookup after IPv4 dns
   lookup failures (default disabled) */
#dns_try_ipv6=yes

/* comment the next line to enable the auto discovery of local aliases
   based on revers DNS on IPs */
auto_aliases=no


listen=udp:192.168.21.111:5060   # CUSTOMIZE ME

disable_tcp=no
listen=tcp:192.168.21.111:5060   # CUSTOMIZE ME

#disable_tls=yes




### Modules Section 

#set module path
mpath="/usr/local/opensips/lib64/opensips/modules/"



 SIGNALING module
loadmodule "signaling.so"

 StateLess module
loadmodule "sl.so"

 Transaction Module
loadmodule "tm.so"
modparam("tm", "fr_timer", 30)
modparam("tm", "fr_inv_timer", 120)
modparam("tm", "restart_fr_on_each_reply", 0)
modparam("tm", "onreply_avp_mode", 1)

 Record Route Module
loadmodule "rr.so"
/* do not append from tag to the RR (no need for this script) */
modparam("rr", "append_fromtag", 0)

 MAX ForWarD module
loadmodule "maxfwd.so"

 SIP MSG OPerationS module
loadmodule "sipmsgops.so"

 FIFO Management Interface
loadmodule "mi_fifo.so"
modparam("mi_fifo", "fifo_name", "/tmp/opensips_fifo")
modparam("mi_fifo", "fifo_mode", 0666)

 URI module
loadmodule "uri.so"
modparam("uri", "use_uri_table", 0)

 MYSQL module
loadmodule "db_mysql.so"

 AVPOPS module
loadmodule "avpops.so"

 ACCounting module
loadmodule "acc.so"
/* what special events should be accounted ? */
modparam("acc", "early_media", 0)
modparam("acc", "report_cancels", 0)
/* by default we do not adjust the direct of the sequential requests.
   if you enable this parameter, be sure the enable "append_fromtag"
   in "rr" module */
modparam("acc", "detect_direction", 0)
modparam("acc", "failed_transaction_flag", "ACC_FAILED")
/* account triggers (flags) */
modparam("acc", "log_flag", "ACC_DO")
modparam("acc", "log_missed_flag", "ACC_MISSED")


 DIALOG module
loadmodule "dialog.so"
modparam("dialog", "dlg_match_mode", 1)
modparam("dialog", "default_timeout", 21600)  # 6 hours timeout
modparam("dialog", "db_mode", 2)
modparam("dialog", "db_url",
"mysql://opensips:opensipsrw@localhost/opensips") # CUSTOMIZE ME


 LOAD BALANCER module
loadmodule "load_balancer.so"
modparam("load_balancer", "db_url",
"mysql://opensips:opensipsrw@localhost/opensips") # CUSTOMIZE ME
modparam("load_balancer", "probing_method", "OPTIONS")

modparam("load_balancer", "probing_interval", 15)





### Routing Logic 


# main request routing logic
route{
if (!mf_process_maxfwd_header("3")) {
send_reply("483","looping");
exit;
}


if ( has_totag() ) {
# sequential request -> obey Route indication
xlog("Loose Route for $avp(iurl) over $avp(dest) $avp(calltype) \n");
loose_route();
t_relay();
exit;
}

# handle cancel and re-transmissions
if ( is_method("CANCEL") ) {
if ( t_check_trans() )
t_relay();
exit;
}


# from now on we have only the initial requests
if (!is_method("INVITE")) {
send_reply("405","Method Not Allowed");
exit;
}

# initial request
record_route();
$avp(iurl) = $(hdr(P-Nuance-Initial-URL));
$avp(calltype) = $(hdr(P-Nuance-Call-Type));
xlog("Sending call $fu $avp(iurl) $avp(calltype) \n");
# LB function returns negative if no suitable destination (for requested
resources) is found,
# or if all destinations are full
if ( !load_balance("1","channel") ) {
xlog("All Destinations are full. Sending 500! $fu
$(hdr(P-Nuance-Initial-URL))");
 send_reply("500","Service full");
 exit;
}
$avp(dest) = $du;
xlog("Call sent over $avp(dest) $fu $(hdr(P-Nuance-Initial-URL))\n");
t_on_reply("test");
# arm a failure route for be able to catch a failure event and to
do
# failover to the next available destination
t_on_failure("LB_failed");

# send

Re: [OpenSIPS-Users] OpenSips rejecting too many calls

[Chandan PR]

Thanks for the input Daniel.

Guys,

Right now we are observing crazy amount of rejections...But the destination
was disabled only a few times..

Any additional data that would be useful to collect?

Regards,
Chandan

On Wed, Aug 10, 2016 at 6:26 PM, Daniel Zanutti 
wrote:

> Hi Chandan
>
> I would suggest upgrading to 1.11.X first, it will be very
> straightforward. If you still have problems, migrating to 2.2 will probably
> not solve them and you may find new ones.
>
> Regards
>
> On Wed, Aug 10, 2016 at 9:16 AM, Chandan PR 
> wrote:
>
>> Hi Guys,
>>
>> We are using OpenSips, 1.9 Load Balancer with Probing Interval set to 15
>> seconds.
>>
>> Yesterday we observed huge number of calls being rejected by Open Sips as
>> Destinations were full.
>>
>> But the number of error codes which results in disabling the gateway was
>> pretty less on the gateway end.
>>
>> The log file was not rolled over and it was of size ~2.5G.
>>
>> Any one has faced similar issue?
>>
>> I see a new event "E_LOAD_BALANCER_STATUS" available in latest versions,
>> which helps in knowing when the destination was disabled or enabled.
>>
>> Any other possible options in 1.9.x to know the details about when the
>> destination was disabled or enabled?
>>
>> How easy or difficult it is to migrate from 1.9.x to 2.2?
>>
>> Any migration tutorials/links/docs for the same?
>>
>> Thanks,
>> Chandan
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] OpenSips rejecting too many calls

[Chandan PR]

Hi Guys,

We are using OpenSips, 1.9 Load Balancer with Probing Interval set to 15
seconds.

Yesterday we observed huge number of calls being rejected by Open Sips as
Destinations were full.

But the number of error codes which results in disabling the gateway was
pretty less on the gateway end.

The log file was not rolled over and it was of size ~2.5G.

Any one has faced similar issue?

I see a new event "E_LOAD_BALANCER_STATUS" available in latest versions,
which helps in knowing when the destination was disabled or enabled.

Any other possible options in 1.9.x to know the details about when the
destination was disabled or enabled?

How easy or difficult it is to migrate from 1.9.x to 2.2?

Any migration tutorials/links/docs for the same?

Thanks,
Chandan
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] OpenSips Reply logged 4 times and not sent back to originator

[Chandan PR]

Hi Guys,

Our Load Balancer configuration is as below:

route{
if (!mf_process_maxfwd_header("3")) {
send_reply("483","looping");
exit;
}


if ( has_totag() ) {
# sequential request -> obey Route indication
loose_route();
t_relay();
exit;
}

# handle cancel and re-transmissions
if ( is_method("CANCEL") ) {
if ( t_check_trans() )
t_relay();
exit;
}


# from now on we have only the initial requests
if (!is_method("INVITE")) {
send_reply("405","Method Not Allowed");
exit;
}

# initial request
record_route();
# LB function returns negative if no suitable destination (for requested
resources) is found,
# or if all destinations are full
if ( !load_balance("1","channel") ) {
 send_reply("500","Service full");
 exit;
}
t_on_reply("test");
# arm a failure route for be able to catch a failure event and to
do
# failover to the next available destination
t_on_failure("LB_failed");

# send it out
if (!t_relay()) {
sl_reply_error();
}

}

onreply_route[test] {
xlog("Reply $rs received from $si for the call $avp(iurl)");
}

In the opensips.log file, for some of the calls I see the reply 200 logged
4 times. And whenever that happens, the same is not sent back to the
originator of the call.

At the end of the day some calls are ending up in ambiguous result codes as
they don't receive 200 OK. And all the calls in this category, we see the
reply 200 logged 4 times in the log.

Any clue on what could be the issue?


Regards,
Chandan
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] OpenSips as Load Balancer - Handling Failure Scenarios

[Chandan PR]

Hi Bogdan-Andrei Iancu,

Sorry for the late reply. This was not the issue with OpenSips. It was an
edge case and fr_inv_timer configuration value was less.

Works perfectly fine after updating the fr_inv_timer value.

Regards,
Chandan

On Tue, May 31, 2016 at 7:23 PM, Bogdan-Andrei Iancu 
wrote:

> Hi Chandan,
>
> If the call is rejected by callee, your opensips should receive a negative
> reply and trigger the failure route - what is the reply code you get back
> from callee ? Is your failure route triggered ?
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>
> On 31.05.2016 16:31, Chandan PR wrote:
>
> Hi Guys,
>
> I am trying to configure OpenSips as Load Balancer for our outbound
> dialling.
>
> I am following the example from:
> http://www.opensips.org/Documentation/Tutorials-LoadBalancing-1-9.
>
> Right now when the user rejects the call, instead of ending up in 486 we
> are ending up in 408.
>
> This is due to the call being ended up in the failure_route after the
> timeout (fr_inv_timer).
>
> Is there a way or configuration to send the response codes from the reply
> back to client, instead of waiting for timeout?
>
>
> Regards,
> Chandan
>
>
> ___
> Users mailing 
> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] OpenSips as Load Balancer - Handling Failure Scenarios

[Chandan PR]

Hi Guys,

I am trying to configure OpenSips as Load Balancer for our outbound
dialling.

I am following the example from:
http://www.opensips.org/Documentation/Tutorials-LoadBalancing-1-9.

Right now when the user rejects the call, instead of ending up in 486 we
are ending up in 408.

This is due to the call being ended up in the failure_route after the
timeout (fr_inv_timer).

Is there a way or configuration to send the response codes from the reply
back to client, instead of waiting for timeout?


Regards,
Chandan
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users