If we have a network issue, we send a BYE to the remote site and either they don’t see if or we don’t get their 200 OK to our BYE then Asterisk keeps sending it over and over. The timing looks something like this:
1st BYE: 02:37:48.941626
2nd BYE: 02:37:49.140928 (200 ms after last BYE - What I have set for t1min)
3rd BYE: 02:37:49.541413 (400 ms after last BYE - Seems to be t1min*2)
4th BYE: 02:37:51.941651 (2400 ms after last BYE )
5th BYE: 02:37:55.141208 (3200 ms after last BYE)
6th BYE: 02:37:59.142028 (4000 ms after last BYE)
Is there any way to limit how many BYE’s Asterisk will send before it gives up? How do I lower the amount of times between each BYE?
Why do you need to address the symptom? Why are you not addressing the cause?
Although you should be planning to move to chan_pjsip. (For a start, google is no longer returning the best copy of sip.conf.sample, as chan_sip no longer exists in the master branch of the GIT source tree.
The same backoff strategy is used for BYE as for INVITE. There are two things that will end the retransmissions, other than a good response, one is the number of retries. The retries are done using an exponential back off, with 500ms being the default starting value (t1). This is configurable. There is also an overall maximum time, which defaults to 32 seconds. These timers should be fairly clearly documented in the sample configuration file, and for chan_psjip, they are at:
chan_sip also uses qualify to determine a better value of t1 dynamically. t1min will be used to limit how low the adaptive algorithm can go.
The number of retries is specified in the SIP RFC, and the only way of reducing them is by setting an overall timeout that expires first.
However, this still comes down to why bother. You are only removing a symptom, and I don’t see what problem the symptom is causing. You need to fix the cause.