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

[Rusty Newton (JIRA)]

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

Rusty Newton commented on ASTERISK-21303:
-----------------------------------------

@D KULL

I'd recommend running it by some other users on the asterisk-users list. Then if you feel there is a bug, you could file a new report. When posting on the list you would definitely need to include more detail on two points for anyone to help:

1. "qualifygap/qualifypeers seems not be able to address the situation"

2. "Asterisk is unable to throttle the OPTIONS storm that ensues"

You would probably also want to provide pastebin links to logs that demonstrate the specific issue and example configs showing what you did to try and remedy it.

If you filed a new bug. You'll want to be clear whether you are saying that the qualify options are not behaving as "expected" by documentation. Or whether you are claiming that Asterisk has a bug that prevents it from handling OPTIONS requests in an expected way.

Thanks!
                
> 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