[asterisk-bugs] [Asterisk 0010455]: Qualify intervals >1000ms create needless double OPTIONS transmissions

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10455 
====================================================================== 
Reported By:                jtodd
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   10455
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   tweak
Priority:                   low
Status:                     new
Asterisk Version:           1.4.10  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             08-14-2007 20:34 CDT
Last Modified:              09-04-2007 15:37 CDT
====================================================================== 
Summary:                    Qualify intervals >1000ms create needless double
OPTIONS transmissions
Description: 

If "qualify=" is larger than 1000ms, then the re-transmit interval (T1)
should be much higher, either whatever qualify= is set to, or the last
value that was returned from the OPTIONS query.  Otherwise, the one-second
default timer triggers another OPTIONS transmission, which doubles the
amount of traffic to the peer every interval.
====================================================================== 

---------------------------------------------------------------------- 
 jtodd - 09-04-07 15:37  
---------------------------------------------------------------------- 
Ah... unless this patch is actually using T1.  I don't know what
"default_qualify" means - is that it?   If T1 is equal to the last qualify
time, then my test will be invalid since I'm actually testing on a local
LAN and using ethernet disconnection as a one-shot latency simulator (I
didn't test on my production system yet.) 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
09-04-07 15:37  jtodd          Note Added: 0069933                          
======================================================================