[asterisk-dev] [Code Review] dont poke registered sip peers immediately after sip reload to avoid packet storm

wdoekes reviewboard at asterisk.org
Tue Jan 10 08:31:11 CST 2012


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1652/#review5150
-----------------------------------------------------------

Ship it!


I like it.


branches/1.8/channels/chan_sip.c
<https://reviewboard.asterisk.org/r/1652/#comment9605>

    !peer->maxms as below.



branches/1.8/channels/chan_sip.c
<https://reviewboard.asterisk.org/r/1652/#comment9604>

    I believe this should be (!peer->maxms). 0 seems to mean Unmonitored. Negative is undefined as far as I can tell, but all checks are done like !peer->maxms.


- wdoekes


On Jan. 5, 2012, 3:14 a.m., schmidts wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1652/
> -----------------------------------------------------------
> 
> (Updated Jan. 5, 2012, 3:14 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> with a big amount of sip peers registered doing a sip reload causes a packet flood of sip OPTIONS messages cause they are immediately sent out when the peer is loaded back from the astdb.
> This fix prevents this packet storm and just schedule a poke in a random value between 1 ms and peers qualifyfreq or the global qualifyfreq. 
> Another very small fix is to schedule a poke on peers with qualify disabled. This doesnt cost much but its just unnecessary to do this.
> 
> maybe it would be even better to dont call the poke function from source_db on a reload cause poking all peers is done after this again.
> 
> 
> This addresses bug ASTERISK-19154.
>     https://issues.asterisk.org/jira/browse/ASTERISK-19154
> 
> 
> Diffs
> -----
> 
>   branches/1.8/channels/chan_sip.c 349449 
> 
> Diff: https://reviewboard.asterisk.org/r/1652/diff
> 
> 
> Testing
> -------
> 
> tested with 4500 peers with qualify=no and no poke is scheduled after a sip reload.
> tested with 2500 peers with qualify=yes and pokes are scheduled in the right time (1 to 60000 ms)
> 
> 
> Thanks,
> 
> schmidts
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120110/4f5b6509/attachment.htm>


More information about the asterisk-dev mailing list