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 <d...@ag-projects.com> 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
