A cheat sheet for anyone trying to control FreeSWITCH bridge behaviour if you’re trying to move calls around if not answered / responded to:
originate_timeout
How long to wait for any response to from the remote peer (100 TRYING, 180 RINGING, etc).
This is useful for knowing when to give up and try a different peer as this peer is dead.
originate_retries
How many times to retransmit the INVITE if no 100 TRYING / 180 RINGING is received.
Like originate_timeout, this is handy for giving up sooner when a peer is dead and moving onto others.
progress_timeout
How long we wait between sending the SIP INVITE before we get a 180/183 before we give up.
This is handy to find out if the remote end isn’t able to reach the endpoint you’re after (page the UE in a cellular context).
bridge_answer_timeout
How long do we wait between the INVITE and a 200 OK (Including RINGING) – This is useful for “no answer” timeouts.
If you want to know why a bridge failed, ie no answer timeout reached, error on the remote end, etc, we can see why with the following variable:
variable_last_bridge_hangup_cause: [PROGRESS_TIMEOUT]
Which will allow you to tell if it’s no answer or progress timeout to blame.
Hi Nick,
I’m always surprised of the amount of helpful material you publish. I have been
looking at these values myself and have also been battling ‘leg_timeout’. Not much doco on it but it looks like it waits for a 183 with SDP. If only 180 Ringing (no sdp), it will timeout and try the next gateway. That is what I am seeing at the moment. Would love it if you had any experience with it, in particular for mobile calls (in Australia). Our leg_timeout is on 8 seconds for our 1st gateway and I suspect it is way too short and should be 15 seconds.
Thanks for all your Kamailio posts too.