Timeout - 408

1. Brekeke Product Name and version:
2.4.3.9
2. Java version:
6.20
3. OS type and the version:
Win7
4. UA (phone), gateway or other hardware/software involved:
Linksys
5. Select your network pattern from http://www.brekeke-sip.com/bbs/network/ ... terns.html :

6. Your problem:

Regarding timeouts. When Brekeke sends out an invite, there is a timeout if no reponse comes back within the "response timeout "setting on the ARS screen.

I'm wondering has anyone seen a situation whereby the trying message comes back from the destination within the timout period, but nothing else. Usually after the trying comes ringing but the destination is not returning ringing or busy or any error code. 32 seconds after the destination sends "trying" the call terminates with a 408 timeout. Has anyone seen a variable to shorten this second timeout scenario? We are seeing 32 seconds of dead air while this 32 second delay occurs, then we see failover to secondary destination. Is the 32 second delay configurable?

In summary, the "ARS response timeout" is working if there is a timeout receiving the first response from the destination. But what if there is a timeout receiving the second response like ringing or busy. Right now those timeouts after the initial "trying" are taking 32 seconds. Are they configurable? Should any response that exceeds the "ARS response timeout" "timeout", not just the first one "trying"?

Hi, Are you using Wifi as the Internet connection?

Anyway.. you can tune the timeout at dialplan.
&net.sip.timeout.provisioning

It is the the timeout for the provisioning time ( after the SIP server receives 100 Trying and before the server receives a subsequent response.)
Its default is 60000ms (=1min).

if you want to set 10sec..
&net.sip.timeout.provisioning = 10000

Let you try!

James,

Thank you! That's exactly what i need.

James,

Not using Wifi. I just want the PBX ARS failover to occur in 5 seconds. I had a carrier that had a failure where they only responded to the invite with trying, but nothing afterwards. It took 32 seconds to fail over to the alternate carrier. I presume i can avoid this type of failure automatically. I had to disable the ARS route to get the traffic from trying this route for 32 seconds before moving on to the next carrier. To get a quick failover i think i need get this setting to 5 seconds. I might try 10 at first to be safe. Again thanks.

Well the situation described has not happened since my last post. The timeout did work as far as terminating the call, but the pbx ars failover did not recognize the timeout 408 generated by the sip server.

I set the timeout value to 3000 ms and the call terminated with a 408 after 3 seconds but the ARS did not try the next pattern. Is the ARS failover only recognizing errors generated by remote systems and not errors generated by the bundled sip server as a result of net.sip.timeout.provisioning=3000? It appears this is the case. I'm certain the ARS is set up correctly and i even put the sole 408 as an error code in the ARS to trigger a failover.

Is the primary and failover ARS working properly when other failover cases? i tried your case, it works. i use pbx v2473
maybe you can capture packets to check if it tried the failover target.

Thanks for giving me hope Hope.

Since you had it working i just kept trying different angles.
What i found is that the &net.sip.timeout.provisioning = 5000 to timeout after 5 seconds only would work if i put it in the "From PBX1" sip dial plan. When i put net.sip.timeout.provisioning = 5000 in the SIP configuration Advanced Screen, it caused both legs to time out which is the ata calling the pbx and the pbx calling the provider. This caused the pbx to not try another ARS on Failover since we made the ATA to PBX leg timeout. It appears this will be very helpful to people because i'm seeing more and more carriers/providers not able to provide a timely timeout because they don't use Brekeke too! It leaves a very bad impression to make a caller wait 10-20 seconds for the first ring of a call. Now, it's not a a problem when a carrier is not able to provide a timely connection thanks to this Brekeke feature. Thank you Brekeke!!!!