[OpenSIPS-Users] Opensips not processing replies from callee

[Bogdan-Andrei Iancu]

Hi,

As per trace, reaching the RADIUS servers fails with timeout in OpenSIPS 
-> this keeps the opensips processes blocked a lot (in the IO with 
RADIUS), degenerating in delays at the level of internal timers.

So, before doing load tests, fix the communication with the RADIUS server.

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 23.01.2016 22:03, Husnain Taseer wrote:
> Dear Users,
> I am trying to do the performance test of our newly build opensips 
> proxy server using sipp, but facing many issues. I am also using 
> Freeradius for AAA operations. When I send calls with 1 CPS everything 
> works perfect, but as I increase the CPS opensips stop processing 
> replies from callee. At a rate of 5 cps the call flow turns into:
>
>      sipp (caller) ---------------- Opensips --------------- sipp (Callee)
>
>       -----------INVITE-------->
>
>                                     RADIUS Auth
>
> -----------INVITE--------->
>
>                                             <--------100 Trying------
>
>                                             <-------180 Ringing------
>
> <----------200 OK---------
>
> -----------INVITE-------->
>
> -----------INVITE-------->
>
> -----------INVITE-------->
>
>
> Callee is sending back proper responses which are being processed at 
> low CPS but on high CPS opensips even not printing the logs of 
> on_reply_route section, and as shown in the trace opensips keep 
> sending INVITE of the same call-id even responses have been received. 
> I have tried different opensips versions 2.1.1, 2.1.2 and 1.11.1-tls, 
> but same issue is there for all of these versions. On 200 OK Opensips 
> is also triggering accounting event on FreeRadius server, is it 
> possible that FreeRadius is creating problem on high CPS ?
>
> With Version 2.1.1 and 2.1.2 I am also getting timer warning and 
> opensips accounting stop event error in the logs:
>
> /Jan 22 12:41:29 66-226-76-150 ./opensips[19633]: 
> WARNING:core:utimer_ticker: utimer task <tm-utimer> already schedualed 
> for 116920 ms (now 117020 ms), it may overlap../
> /Jan 22 12:41:29 66-226-76-150 ./opensips[19633]: 
> WARNING:core:utimer_ticker: utimer task <tm-utimer> already schedualed 
> for 117020 ms (now 117120 ms), it may overlap../
> /Jan 22 12:41:29 66-226-76-150 ./opensips[19633]: 
> WARNING:core:utimer_ticker: utimer task <tm-utimer> already schedualed 
> for 117120 ms (now 117220 ms), it may overlap../
> /Jan 22 12:41:29 66-226-76-150 ./opensips[19705]: rc_send_server: no 
> reply from RADIUS server localhost:1813/
> /Jan 22 12:41:29 66-226-76-150 ./opensips[19705]: 
> ERROR:acc:acc_aaa_request: Radius accounting request failed for 
> status: 'Stop' Call-Id: '1-23993 at 104.237.143.243 
> <mailto:1-23993 at 104.237.143.243>'/
> /Jan 22 12:41:29 66-226-76-150 ./opensips[19705]: 
> WARNING:core:handle_timer_job: utimer job <tm-utimer> has a 117290000 
> us delay in execution/
> /Jan 22 12:41:29 66-226-76-150 ./opensips[19653]: 
> WARNING:core:handle_timer_job: timer job <rl-timer> has a 26880000 us 
> delay in execution/
>
> But Radius Accounting stop event is nothing to do with 200OK, because 
> on 200 OK accounting start event is triggered on the RADIUS server 
> which is properly triggered.
> I am using 10 opensips children process and sending 100 calls with 10 
> CPS and duration of all the calls is 10 sec. Currently we are stuck 
> there and not able to move this machine into production please advice 
> how to get rid of this issue.
>
> We also have exactly same revision of Opensips and RADIUS code running 
> perfectly in production, but on this new server we are facing this issue.
>
> Regards,
> Husnain Taseer
> VoIP Developer
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20160125/969fadfa/attachment.htm>