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

[Olle E. Johansson]

John Todd wrote:
> I'm having a problem with Asterisk sending too many INVITEs to a peer for a single call.  I can't quite figure out why there are these rapid INVITEs sent to the call proxy.  The call completes correctly (to, in this example, an echo test found via ENUM) but the number of INVITEs is really out of control and is a Bad Thing overall.
> 
> My notes:
> 
> 1) This isn't a firewall problem - there aren't any.  Additionally, you'll note that the INVITEs are all 
> being replied to eventually.
> 
> 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.

> 3) Here is the peer definition for this system:
> 
> [testbed]
> type=peer
> username=9
> secret=dio0sywa82a
> host=10.0.3.173
> insecure=very
> context=default
> qualify=4000 
> 
> 6) The INVITEs create a huge logjam of "100 Trying" and "200 OK with SDP" messages.  This is Bad.
Can we see a SIP debug?


> cookies*CLI> testbed
>     -- Executing Dial("SIP/2598-dbb4", "SIP/437800047111 at testbed") in new stack
>     -- Called 437800047111 at testbed
>     -- SIP/testbed-6b7c answered SIP/2598-dbb4
>     -- Attempting native bridge of SIP/2598-dbb4 and SIP/testbed-6b7c
>     -- Executing Hangup("SIP/2598-dbb4", "") in new stack
> cookies*CLI> 
Looks fine.


> 10) The (post-407) INVITEs are identical to each other - there are no differences in Call-ID, branch, tag, nonces, or SDP.  I then compared the INVITES between a working peer and the broken peer to each other - they're almost identical except for IP addresses, so nothing obvious there, either.
Good.


> 11) Each INVITE in a "sip debug" output is tagged with something like "Retransmitting #4 (no NAT) to 10.0.3.173:5060:" but there 
> are no timer statements that I could see in the debug.
Turn on debug to 4. There should be messages about changing T1 timers then.

> 
> I am _totally_ stumped here.  I have changed the names of the peers, changed the qualify= statement, moved the peers around in sip.conf, stood on my head, etc.  Your insights on this would be appreciated, since I'm not quite sure what Asterisk is up to with these rapid INVITE sequences.  I'm thinking "bug" but maybe there is some subtle config option that I'm overlooking, so I'll ask the list before I file the bug.  Maybe it's just that I've had too much caffeine today and the obvious solution is the one that's the most difficult to see.
If you turn off qualify, we will use the default 500 ms as Timer T1.

/O