[Asterisk-Dev] Bug in SIP code - OPTIONS requests don't die

[John Todd]

So, I have a peer who is sending me calls via SIP to my system, from 
two different hosts both running Asterisk (we're experimenting with 
different methods of VoIP call transport, so that's why it's not IAX 
or IAX2 in this example.)  He has turned on the "qualify=" option in 
his sip.conf.  This, however, seems to cause heartache for my 
Asterisk server, and every "OPTIONS" request creates a new SIP call, 
or partial SIP call as the case may be.  Eventually, my Asterisk 
processes lock up and have to be killed off manually.

The example list below increases every time one of his hosts 
communicates with my Asterisk server via an OPTIONS request.  Using 
CVS as of 2003/04/08.

JT



[IP addresses randomized to protect the innocent]

pri1*CLI> sip show channels
Peer             Username    Call ID      Seq (Tx/Rx)  Lag      Jitter  Format
199.3.33.1    (None)      35936ef435c  00101/00103  00000ms  0000ms  0
199.3.33.1    (None)      4624715e6cd  00101/00103  00000ms  0000ms  0
199.3.33.1    (None)      65badb7264d  00101/00103  00000ms  0000ms  0
199.3.33.1    (None)      6d38c1bf3ed  00101/00103  00000ms  0000ms  0
199.3.33.1    (None)      65955865779  00101/00103  00000ms  0000ms  0
199.3.33.1    (None)      055537ff00a  00101/00103  00000ms  0000ms  0
199.3.33.1    (None)      7f49a1dd7f4  00101/00103  00000ms  0000ms  0
199.3.33.1    (None)      248dcf662a0  00101/00103  00000ms  0000ms  0
199.3.33.1    (None)      27f5e3a87e3  00101/00103  00000ms  0000ms  0
199.3.33.1    (None)      4c2af5b8649  00101/00103  00000ms  0000ms  0
199.3.33.1    (None)      28a9afaa738  00101/00103  00000ms  0000ms  0
199.3.33.1    (None)      6e1d452337b  00101/00103  00000ms  0000ms  0
199.3.33.1    (None)      41b2c9ae776  00101/00103  00000ms  0000ms  0
199.3.33.1    (None)      6e18415c28f  00101/00103  00000ms  0000ms  0
199.3.33.1    (None)      0586870256e  00101/00103  00000ms  0000ms  0
199.3.33.1    (None)      6d5c95c036b  00101/00103  00000ms  0000ms  0
199.3.33.1    (None)      7ae840f86db  00101/00103  00000ms  0000ms  0
199.3.33.1    (None)      4c5c07e708b  00101/00103  00000ms  0000ms  0
64.22.32.10   (None)      6f9408bc2a7  00101/00103  00000ms  0000ms  0
199.3.33.1    (None)      06ad9d5168b  00101/00103  00000ms  0000ms  0
199.3.33.1    (None)      46dfebde617  00101/00103  00000ms  0000ms  0
64.22.32.10   (None)      7a1b97f9198  00101/00103  00000ms  0000ms  0
199.3.33.1    (None)      3212497826b  00101/00103  00000ms  0000ms  0
199.3.33.1    (None)      3927998202b  00101/00103  00000ms  0000ms  0
64.22.32.10   (None)      50269f7d5d7  00101/00103  00000ms  0000ms  0
199.3.33.1    (None)      2ff5a09d52e  00101/00103  00000ms  0000ms  0
199.3.33.1    (None)      163e67302d1  00101/00103  00000ms  0000ms  0
64.22.32.10   (None)      0d6768652ec  00101/00103  00000ms  0000ms  0
199.3.33.1    (None)      650a1e6b237  00101/00103  00000ms  0000ms  0
199.3.33.1    (None)      60502f2e3da  00101/00103  00000ms  0000ms  0
64.22.32.10   (None)      7e4cda33722  00101/00103  00000ms  0000ms  0
199.3.33.1    (None)      0f23490244e  00101/00103  00000ms  0000ms  0
199.3.33.1    (None)      45f5ec8e7c5  00101/00103  00000ms  0000ms  0
64.22.32.10   (None)      1a88e546289  00101/00103  00000ms  0000ms  0
199.3.33.1    (None)      60dba25a1aa  00101/00103  00000ms  0000ms  0
199.3.33.1    (None)      12c7e14b43e  00101/00103  00000ms  0000ms  0
64.22.32.10   (None)      6aec4b0f4c7  00101/00103  00000ms  0000ms  0
199.3.33.1    (None)      223d278252a  00101/00103  00000ms  0000ms  0
199.3.33.1    (None)      36cb854f40e  00101/00103  00000ms  0000ms  0
199.3.33.1    (None)      5b55bd0562f  00101/00103  00000ms  0000ms  0
199.3.33.1    (None)      2845487e2c3  00101/00103  00000ms  0000ms  0
64.22.32.10   (None)      149d50ac4fc  00101/00103  00000ms  0000ms  0
42 active SIP channel(s)
pri1*CLI>