Hello,
On 11/2/12 6:06 PM, Spencer Thomason wrote:
Hello, I'm trying to address a problem where sometimes our upstream providers have slow call setup times. We use drouting with multiple providers for each route to handle failover in the event of an outage but in this case, we get a 100 Trying but sometimes a 18[03] response takes 4-5 seconds or we never get it because the caller cancels the request. What would be a "safe" amount of time to allow a PSTN gateway to reply with a 180/183? What I'm trying to avoid is a scenario where the PSTN legitimately takes a long time to setup (i.e. an international call to some cell phone providers) and we needlessly failover which will actually increase the post dial delay for the user.
My thought is this for example:
route[PSTN] { t_set_fr(1000); # set fr timer to 1 second so we failover quickly if no provisional response t_on_reply("PSTN_REPLY");
# Routing logic}
onreply_route[PSTN_REPLY] { if (status=~"1[0-9][0-9]") { t_set_fr(4000); # set fr timer to 4 seconds }
if (status=~"18[03]") { t_reset_fr(); # reset timer if we get a 180 or 183 }}
Also, if we failover because of slow call setup for a particular route, I'd like to temporarily avoid that gateway for that route (but only that route).
I'm curious if anyone has any pointers or how they solved this.
updating the timer on sip responses should be the way to go -- it was not clear if you tried what you showed above or was just a proposal?
Regarding the temporarily avoid that destination address for a route, you can use htable module with some auto-expire to store (number, gatateway) and before sending out, check if you have an item in htable matching the dialed number and if selected gateway matches the value, if yes, then use the next gateway.
Cheers, Daniel