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

Kristian Kielhofner kris at krisk.org
Tue Aug 29 19:04:00 MST 2006


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: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

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



More information about the asterisk-users mailing list