[SR-Users] UAC reg_random_delay issue

Daniel-Constantin Mierla miconda at gmail.com
Wed Aug 16 10:29:24 CEST 2017


Hello,

the registrations are done each timer interval as soon as init_time +
reg_delay > crt_timer. As you have reg_delay spread across 60sec and the
timer run each 60sec, very likely all of them are done at once or
sometimes in two timer callback executions.

You have to set the timer interval to a lower value, try with 5 or 10
seconds and see the results.

Cheers,
Daniel


On 16.08.17 10:02, Ivo Vastert wrote:
> Hi,
>
> We're currently using 60 as well there:
>
> modparam("uac", "reg_timer_interval", 60)
>
>
> Br,
>
> Ivo
>
>
> On Wed, Aug 16, 2017 at 8:22 AM, Daniel-Constantin Mierla
> <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>
>     Hello,
>
>     I asked about reg_timer_interval parameter.
>
>     Cheers,
>     Daniel
>
>
>     On 16.08.17 01:32, Ivo Vastert wrote:
>>     Hi,
>>
>>     We are currently using 60:
>>
>>     modparam("uac", "reg_random_delay", 60)
>>
>>     On Tuesday, August 15, 2017, Daniel-Constantin Mierla
>>     <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>>
>>         Hello,
>>
>>         what is the value for reg_timer_interval parameter?
>>
>>         Cheers,
>>         Daniel
>>
>>
>>         On 15.08.17 12:54, Ivo Vastert wrote:
>>>         Hi,
>>>
>>>         I'm using the UAC module in Kamailio to setup about 500
>>>         outbound registration towards a single host.
>>>         The issue I'm currently experiencing is that when we start
>>>         Kamailio all this 500 registrations are initiated at once
>>>         towards the host which can't handle all the requests at the
>>>         same time.
>>>
>>>         Therefor I tried to spread the registrations using the
>>>         reg_random_delay function:
>>>         modparam("uac", "reg_random_delay", 60)
>>>
>>>         I would expect that this would spread the registrations over
>>>         about a minute but in reality the registrations are spread
>>>         as follow:
>>>
>>>         Starttime / Registrations
>>>         21:59:14151
>>>         21:59:15166
>>>         21:59:16127
>>>         21:59:1860
>>>         21:59:2235
>>>
>>>         So Kamailio is started at 21:59:14 and initiates 151
>>>         registrations,
>>>         1 second after start another 166
>>>         2 seconds after start another 127
>>>         4 seconds after start another 60
>>>         8 seconds after start the last 35
>>>
>>>         In reality it looks like some increment is applied instead
>>>         of calculating a random starting offset for each outbound
>>>         registration?
>>>         Is there any solutions to this issue available?
>>>
>>>         Best regards,
>>>
>>>         Ivo Vastert
>>>
>>>
>>>         _______________________________________________
>>>         Kamailio (SER) - Users Mailing List
>>>         sr-users at lists.kamailio.org
>>>         https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>         <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>>
>>         -- 
>>         Daniel-Constantin Mierla
>>         www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
>>         Kamailio Advanced Training - www.asipto.com <http://www.asipto.com>
>>         Kamailio World Conference - www.kamailioworld.com <http://www.kamailioworld.com>
>>
>
>     -- 
>     Daniel-Constantin Mierla
>     www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
>     Kamailio Advanced Training - www.asipto.com <http://www.asipto.com>
>     Kamailio World Conference - www.kamailioworld.com <http://www.kamailioworld.com>
>
>

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - www.asipto.com
Kamailio World Conference - www.kamailioworld.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20170816/523c01fb/attachment.html>


More information about the sr-users mailing list