[asterisk-users] SIP T1 timer and qualify=yes

Christian Schlatter cs at unc.edu
Tue Aug 29 11:12:06 MST 2006


I ran in the same issues as John Todd did some while ago:

http://lists.digium.com/pipermail/asterisk-users/2005-November/129541.html


I use qualify=yes to ping our internal SIP proxies for failover and 
therefore I have very low delays, e.g.

Name/username    Host            Dyn Nat ACL Port     Status
mid2-3           xx.xx.xx.xx                 5060     OK (1 ms)

which causes Asterisk to use a very small T1 to retransmit SIP requests:

Time        Protocol Info
4.107899    SIP/SDP  Request: INVITE sip:test4 at 152.23.129.203
4.113318    SIP/SDP  Request: INVITE sip:test4 at 152.23.129.203
4.113339    SIP/SDP  Request: INVITE sip:test4 at 152.23.129.203
4.121283    SIP/SDP  Request: INVITE sip:test4 at 152.23.129.203
4.129283    SIP/SDP  Request: INVITE sip:test4 at 152.23.129.203
4.145284    SIP/SDP  Request: INVITE sip:test4 at 152.23.129.203
4.177281    SIP/SDP  Request: INVITE sip:test4 at 152.23.129.203

(this looks like a SIP DOS attack to me)

Setting T1 according the SIP qualify delay only makes sense if the delay 
measurements are done with the final target of a SIP request. If I ping 
a SIP proxy instead, the ping delay does not say anything about the 
actual end-to-end SIP signaling path delay.

My recommendation would be to statically set T1 to 500ms according to 
RFC 3261. If that is not an option I'd set a minimum T1 that is at least 
100ms.

-Christian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 1951 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20060829/4c9cd24c/smime.bin


More information about the asterisk-users mailing list