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@152.23.129.203
> 4.113318 SIP/SDP Request: INVITE sip:test4@152.23.129.203
> 4.113339 SIP/SDP Request: INVITE sip:test4@152.23.129.203
> 4.121283 SIP/SDP Request: INVITE sip:test4@152.23.129.203
> 4.129283 SIP/SDP Request: INVITE sip:test4@152.23.129.203
> 4.145284 SIP/SDP Request: INVITE sip:test4@152.23.129.203
> 4.177281 SIP/SDP Request: INVITE sip:test4@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