[Home]

Summary:ASTERISK-10084: Qualify intervals >1000ms create needless double OPTIONS transmissions
Reporter:John Todd (jtodd)Labels:
Date Opened:2007-08-14 20:34:57Date Closed:2011-06-07 14:07:54
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
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.

****** ADDITIONAL INFORMATION ******

Transcript from a phone at the other end of a geostationary satellite link (~1100ms away - qualify set to 3000).  The first OPTIONS times out at 1000ms (despite my qualify being set to 3000) and re-transmits another OPTIONS packet.    Just as the other OPTIONS packet is out on the wire, the first reply comes back.  Then, eventually the second OPTIONS reply comes back.  We only need to do this once, since we've been given a hint that the qualify is excessively large.

391.345451 203.22.183.82 -> 12.33.218.182 SIP Request: OPTIONS sip:7433@192.168.2.186:5060;user=phone;transport=udp
392.345083 203.22.183.82 -> 12.33.218.182 SIP Request: OPTIONS sip:7433@192.168.2.186:5060;user=phone;transport=udp
392.358876 12.33.218.182 -> 203.22.183.82 SIP/SDP Status: 200 OK, with session description
393.090744 12.33.218.182 -> 203.22.183.82 SIP/SDP Status: 200 OK, with session description
Comments:By: Tilghman Lesher (tilghman) 2007-09-04 14:28:13

Patch to test uploaded.
By: John Todd (jtodd) 2007-09-04 15:35:02

Didn't seem to make a difference.  The re-transmits are still happening every 1000ms.  See tethereal output below - all re-transmits of OPTIONS seem to be 1000ms, even though qualify= is set to 3000 for this peer.


60.046680 203.33.19.82 -> 208.134.22.198 SIP Request: OPTIONS sip:1234@208.134.22.198:1121
60.104898 208.134.22.198 -> 203.33.19.82 SIP Status: 200 OK
[unplug phone here to simulate latency]
120.104216 203.33.19.82 -> 208.134.22.198 SIP Request: OPTIONS sip:1234@208.134.22.198:1121
121.104807 203.33.19.82 -> 208.134.22.198 SIP Request: OPTIONS sip:1234@208.134.22.198:1121
122.103550 203.33.19.82 -> 208.134.22.198 SIP Request: OPTIONS sip:1234@208.134.22.198:1121
123.103293 203.33.19.82 -> 208.134.22.198 SIP Request: OPTIONS sip:1234@208.134.22.198:1121
124.104032 203.33.19.82 -> 208.134.22.198 SIP Request: OPTIONS sip:1234@208.134.22.198:1121
By: John Todd (jtodd) 2007-09-04 15:37:31

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.)
By: Tilghman Lesher (tilghman) 2007-09-05 09:51:30

Okay, I'm looking at this again, and I'm not seeing where the options is retransmitted once a second.  The OPTIONS packet is by default only sent once every 60 seconds, when the host is up, and once every 10 seconds, when the host is down.

I also see that an OPTIONS request is sent whenever Asterisk receives a registration attempt, so is it possible that your phone is not registering, but you have a defaultip defined, and each registration attempt results in an OPTIONS packet?
By: Tilghman Lesher (tilghman) 2007-11-13 11:44:16.000-0600

To recap what we discussed on IRC, you need to increase DEFAULT_RETRANS in chan_sip.c (probably to about 3000) and recompile.
By: Tilghman Lesher (tilghman) 2007-12-24 23:42:01.000-0600

No response from reporter.