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

[Matt Jordan]

> On Jan. 10, 2012, 8:31 a.m., wdoekes wrote:
> > branches/1.8/channels/chan_sip.c, line 29291
> > <https://reviewboard.asterisk.org/r/1652/diff/1/?file=22553#file22553line29291>
> >
> >     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.

Don't you mean if (peer->maxms)?

If peer->maxms is 0, then the peer is unmonitored and we shouldn't poke at it.  If peer->maxms is non-zero, then we should poke it.


- Matt


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


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/20120731/751243ef/attachment.htm>