[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