[Asterisk-Users] SIP rapid INVITE re-transmission: bug, or config problem?

[John Todd]

At 9:43 AM +0100 11/29/05, Olle E. Johansson wrote:
>
>John Todd wrote:
>[snip]
>  > 2) The intervals between the INIVTEs after the 407 sequence are: 
>34ms, 30ms, 49ms, 91ms.
>  > This is _way_ too fast for response timers to be expiring for 
>reliable re-transmissions of INVITEs... isn't it?  According to 
>DEFAULT_RETRANS in chan_sip.c, the proper delay should be 1000ms 
>between retransmissions.
>
>No, it's twice the known roundtrip time or twice 500 ms. Since you 
>have qualify on, we propably know the roundtrip time and do the 
>retransmissions based on that.
[snip]

Yes, this seems to be the case.  Turning off "qualify" solved the 
problem.  Thanks to you and Kevin for spotting the issue; I forgot 
that T1 was changed by "qualify=" and I has assumed 500ms.

This is where chan_sip3's tune-able T1 timer would be very handy.  I 
have a low-latency network (3ms) between the client (Asterisk) and 
SER, but it takes about 40ms for several database dips and some other 
"magic" to happen before either a 4xx or 2xx can be transmitted back 
to the client, so this leads to a storm of INVITEs since T1 (and 
2*T1, and 2*2*T1, etc.) is very low.

I can't leave "qualify=" turned off, since I use that as a failure 
short-circuit (i.e.: if the OPTIONS queries fail, I'd always prefer 
to have that SIP peer be immediately invalidated instead of sending 
the INVITEs for 60 seconds during a Dial attempt.)

The right way to do it is to insert a "100 Trying" as a conditional 
response as an immediate reply to Asterisk, which should solve the 
issue, so this is what I'll try to implement on my SER platform. 
Thanks!

JT