Re: [OpenSIPS-Users] Mediaproxy hanging sessions on high load
Hi Dan Thanks for replying. I understand that best case scenario is to run on a physical dedicated server, but unfortunately this is impossible on all cases and virtual machines is the only viable ($$) solution. About the "frozen" sessions, as as workaround, I'll test dropping these sessions directly using dispatcher interface. If it works, a console will solve the problem. The problem is that I cannot reproduce this scenario, on some clients it happens, on some I have same quantity of calls and never happens. I'll try to find a workaround on the timer. Thanks for all help, you guys are great. On Fri, Mar 17, 2017 at 3:08 PM, Dan Pascu wrote: > > On 17 Mar 2017, at 3:54, Daniel Zanutti wrote: > > > Adrian > > > > You may be correct, overload can be the problem. But since the call is > already finished, how can I remove from the relay? > > One way is to issue commands to the dispatcher to end certain sessions, in > the same way that opensips issues them when it receives a BYE. But this is > easier said than done, because you will need to find out the call-id , > from-tag and to-tag of the call in order to do that. > > At some point we had the idea to add this kind of functionality to the > monitoring web page allowing you to click a button next to a call to > forcefully end it, but it never come to fruition. > > The only thing you can do for now is make sure you have at least another > relay connected to the dispatcher, so it can absorb new calls, the run > /etc/init.d/media-relay stop-gracefully and wait until this relay has no > more active traffic, then you can run /etc/init.d/media-relay restart to > restart it. > > -- > Dan > > > > > > ___ > 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
Re: [OpenSIPS-Users] Mediaproxy hanging sessions on high load
On 17 Mar 2017, at 3:54, Daniel Zanutti wrote: > Adrian > > You may be correct, overload can be the problem. But since the call is > already finished, how can I remove from the relay? One way is to issue commands to the dispatcher to end certain sessions, in the same way that opensips issues them when it receives a BYE. But this is easier said than done, because you will need to find out the call-id , from-tag and to-tag of the call in order to do that. At some point we had the idea to add this kind of functionality to the monitoring web page allowing you to click a button next to a call to forcefully end it, but it never come to fruition. The only thing you can do for now is make sure you have at least another relay connected to the dispatcher, so it can absorb new calls, the run /etc/init.d/media-relay stop-gracefully and wait until this relay has no more active traffic, then you can run /etc/init.d/media-relay restart to restart it. -- Dan ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Mediaproxy hanging sessions on high load
On 16 Mar 2017, at 16:22, Daniel Zanutti wrote: > Hi Dan > > Looks like this problem is only happening on virtual machines, not on > physical machines. And only while they are on high load. We have recommended since forever that people run a media relays on real hardware, yet time and again people ignore that and use virtual machines. I rest my case. > > But i'm not sure about the kernel rule, is there any way to check it? You can check the conntrack rules in /proc/net/ip_conntrack > > Please take a look at this case, this Relay will never halt because there are > more than 3k sessions that will never finish internally (the call has already > hangup hours ago): Ok, so that is what you meant by "the relay starts to hangup sessions". This is something we encountered as well, but not to the extent you mention. In our case we have some 30-50 sessions in that state after 1-2 months of usage. It seems to always be associated with some network failures where sessions are not ended properly. We do not know exactly what causes it and given it's small impact for us it was never a priority to debug it. All I know is that it seems to be correlated with dialog updates that remove a RTP stream by setting its port to 0, without ending the session. > Is there any way to drop these sessions? Maybe using the internal timeout > system of mediaproxy? Mediaproxy already employs several timeout mechanisms, both of its own as well as leveraging the timeout mechanism the linux conntrack implementation provides for rules that receive no traffic for a while. The problem is not the lack of those, the problem seems to be that under certain conditions which we have not yet identified, those timeouts seem to be ignored. -- Dan ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Monitoring Mediaproxy
Understood. Thanks for explanation. Regards On Fri, Mar 17, 2017 at 2:47 PM, Dan Pascu wrote: > > On 16 Mar 2017, at 15:58, Daniel Zanutti wrote: > > > Hi Dan > > > > This is exactly how I'm monitoring but looking to the dispatcher it's > kind hard on a Nagios like system, because I'm monitoring Relay A, B and C, > but the status will be on dispatcher machine D. But ok, if it's the only > way. > > The relay doesn't listen for network connections, you cannot connect > directly to a relay. A relay will only connect to all configured > dispatchers. The dispatcher on the other hand has a control port where you > can connect and give commands, including fetching statistics from relays > over the connections the relay already established with the dispatcher. > > -- > Dan > > > > > > ___ > 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
Re: [OpenSIPS-Users] Monitoring Mediaproxy
On 16 Mar 2017, at 15:58, Daniel Zanutti wrote: > Hi Dan > > This is exactly how I'm monitoring but looking to the dispatcher it's kind > hard on a Nagios like system, because I'm monitoring Relay A, B and C, but > the status will be on dispatcher machine D. But ok, if it's the only way. The relay doesn't listen for network connections, you cannot connect directly to a relay. A relay will only connect to all configured dispatchers. The dispatcher on the other hand has a control port where you can connect and give commands, including fetching statistics from relays over the connections the relay already established with the dispatcher. -- Dan ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] [Release] OpenSIPS 2.3.0 major release, beta version
Hi Team,
Firstly Congrats on a job well done on getting the new Version
out.
Now a qick question on the acc changes.
I inject several parmeter using the db_extra modparam. This looks
to have changes significantly.
if I to the following in 2.2 for example:
modparam("acc", "db_extra", "caller_id=$fU;
callee_id=$tU;
caller_domain=$fd;
callee_domain=$td)
is this correct for 2.3
modparam("acc", "extra_fields", "db: caller_id->caller_id; callee_id -> callee_id,caller_domain -> caller_domain;callee_domain -> callee_domain")
and set these in the script at the appropriate places?
$acc_extra(caller_id) = $fU;
$acc_extra(callee_id) = $tU;
$acc_extra(caller_domain) = $fd;
$acc_extra(callee_domain) = $td;
R
On 16/03/2017 19:59, Ramachandran, Agalya (Contractor) wrote:
Congrats team for the next mile stone achievement!!!
Regards,
Agalya
-Original Message-
From: Users [mailto:users-boun...@lists.opensips.org] On Behalf Of Bogdan-Andrei Iancu
Sent: Thursday, March 16, 2017 3:03 PM
To: users@lists.opensips.org; developensips ; n...@lists.opensips.org; busin...@lists.opensips.org
Subject: [OpenSIPS-Users] [Release] OpenSIPS 2.3.0 major release, beta version
Hi All !!
Almost 2 months ago I was posting [1] : “A new year has arrived, so it is the time for a new OpenSIPS major release – for OpenSIPS version 2.3 “.
Well, this just happened !!
I’m happy to announce the beta version of the OpenSIPS 2.3.0 major release. Curios to find out more about this release ?
See the philosophy behind this release by reading the overview of OpenSIPS 2.3.o, code name *integration* :
http://www.opensips.org/About/Version-Overview-2-3-0
Enjoy it !!!
[1] https://blog.opensips.org/2017/01/12/introducing-opensips-2-3/
--
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
OpenSIPS Summit May 2017 Amsterdam
http://www.opensips.org/events/Summit-2017Amsterdam.html
___
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
--
Richard Robson
Greenlight Support
01382 843843
supp...@greenlightcrm.com
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
