[asterisk-bugs] [JIRA] (ASTERISK-21303) qualifygap SIP general setting appears broken

[D KULL (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-21303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=207373#comment-207373 ] 

D KULL commented on ASTERISK-21303:
-----------------------------------

I am experiencing the same issue with a smaller setup (about 500 qualified users). There doesn't seem to be a good solution to this with the configuration options. qualifygap/qualifypeers seems not be able to address the situation. The issue appears randomly and Asterisk is unable to throttle the OPTIONS storm that ensues. The only solution is a complete restart.
                
> qualifygap SIP general setting appears broken
> ---------------------------------------------
>
>                 Key: ASTERISK-21303
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21303
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/General, PBX/pbx_realtime
>    Affects Versions: 11.2.1
>            Reporter: JoshE
>            Assignee: Rusty Newton
>
> Running Asterisk 11 with around 1600 realtime peers, all of which are qualified behind remote NAT.  
> I am seeing an extremely painful issue with sip reloads generating massive storms of OPTIONS messages, most of which can't be responded to within 2000 ms, so the peer goes missing.  In the case where SRV endpoints are used, this generates a storm of traffic to secondary/tertiary servers, which puts the entire system in a loop.
> My initial solution was to use the qualifygap setting in sip.conf [general].  However, this appears to actually be broken.  When setting this setting to 500 or even 1200, I am still seeing many, many options messages / time period.  I am not sure I have implemented qualifygap correctly, as there is effectively no documentation on it.  I am not sure what the "group" referenced in the comments ("Number of milliseconds between each group of peers being qualified") refers to.  The sip_poke_all_peers seems to not differentiate anything on the basis of any sort of group.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira