[SR-Users] occasional processing delay and UAC remote registration

Dmitri Savolainen savolainen at erinaco.ru
Mon Sep 3 13:13:10 CEST 2018


>
>   in my 4.1.5 kamailio server
>
5.1.5 of course

On 3 September 2018 at 14:11, Dmitri Savolainen <savolainen at erinaco.ru>
wrote:

> Hi all.
>
> i encountered  in my 4.1.5 kamailio server some inconstant issue.
>
> I have 2 listen address:
> addr1 for incoming SIP requests and as source addr for remote
> registration (via UAC module)
> addr2 for incoming SIP requests only
>
> uac config for regs:
> modparam("uac", "reg_keep_callid", 1)
> modparam("uac", "reg_random_delay", 120)
> modparam("uac", "reg_retry_interval", 300)
> modparam("uac", "reg_timer_interval", 40)
>
> i have response time checking tool, that send OPTIONS every second,
> which immedeately replied by sl_send_reply("200")  without any processing.
> Usualy respose time <1ms.
>
> Sometimes (2-3 per day) addr1 stop to response for these OPTIONS (timeout
> >5sec), while addr2  continue responding with time <1ms.  In kamailio.log
> at this moment bunch of messages like
>
> ERROR: uac [uac_reg.c:1034]: uac_reg_tm_callback(): got sip response 403
>> while registering
>
> ERROR: uac [uac_reg.c:1034]: uac_reg_tm_callback(): got sip response 408
>> while registering
>
>
> That is normal: some remotes are broken.
>
> The problem is:
> 1. usually these messages appearing is not the reason of problem, but all
> problems are while these messages in log
> 2. it may be on OFF peak  / ON peak day period
> 3. in my test installation i have much more remote failure registration (X
> 10), and the problem is not manifested more often (but i can catch it 2-3
> per day)
>
> I think adding more workers for addr1 may help (now 8 worker and 16 CPUs).
> But it is interesting to understand the source of this issue
>
>
>
>
> --
> Savolainen Dmitri
>



-- 
Savolainen Dmitri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20180903/5d7d20a9/attachment.html>


More information about the sr-users mailing list