Christian Schlatter wrote:
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:[EMAIL PROTECTED]
4.113318 SIP/SDP Request: INVITE sip:[EMAIL PROTECTED]
4.113339 SIP/SDP Request: INVITE sip:[EMAIL PROTECTED]
4.121283 SIP/SDP Request: INVITE sip:[EMAIL PROTECTED]
4.129283 SIP/SDP Request: INVITE sip:[EMAIL PROTECTED]
4.145284 SIP/SDP Request: INVITE sip:[EMAIL PROTECTED]
4.177281 SIP/SDP Request: INVITE sip:[EMAIL PROTECTED]
(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
Christian,
Even better would be the ability to tune T* parameters in general/peer
sections (i.e. t1timer=500, etc) to override the values generated by the
OPTIONS pings...
--
Kristian Kielhofner
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
