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

Rusty Newton (JIRA) noreply at issues.asterisk.org
Tue Apr 2 16:35:01 CDT 2013


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

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

I'll leave this in "Waiting for Feedback" for the documentation patch then. Yeah if you find a potential bug in ODBC open that up in a separate issue. Of course you may want to run it by others on the asterisk-users list first to help verify. 

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: JoshE
>
> 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



More information about the asterisk-bugs mailing list