FOOD FOR THOUGHT Timeout to move onto the next outbound route

[hchucky]

When I dial out my primary trunk is "circuit-busy" so it rolls to the next trunk in line and successfully dials out. My question is how do I control the timeout value between the time it tries one trunk then gives up and goes onto the next one? In my case it is taking 30 sec. This is causing issues because when my primary trunk is offline (different story) everybody who uses the phone for outbound calls hangs up before the timeout because they assume it is just not going to work.

I am running the latest PIAF stack (Asterisk 1.8).

Thanks,
HC

 

[hchucky]

I'm not getting a response here and looking back clearly this belongs in the Help forum. Moderator, can you move this posting to the Help forum?

HC

 

[rossiv]

Hmm...Are you meaning from in one outbound route to move onto the next trunk or for one outbound route to move to another?
If you are talking about trunk to trunk, I am running 1.8 and I have not experienced this. I once had a GVoice trunk misconfigured and it just skipped through it and went on to the next one. It sent Asterisk a All Circuits Busy and my OB Route moved on. Can you post a log that shows where the hang up is appearing, as well as the output of 'status'?
Thanks!

 

[hchucky]

So let's say you have two outbound trunks setup for a given route. As an example take the first trunk and change the password on it to something erroneous so it will not properly register. Now make an outbound call. During that call you will notice there is a long pause while it tries to make an outbound call on the first trunk. After roughly 30 sec it will give up (time out) and move onto the second trunk in the order and successfully complete the call using that trunk.

What I am trying to figure out is how do I adjust the amount of time that it tries to make the call on the first trunk before giving up and going onto the next.

HC

 

[hchucky]

Thx for the response. I took a shot in the dark and figured that changing the password would recreate my problem. I just tested it for myself. As you pointed out, it goes to the next trunk with very little delay.

Sometimes when I reboot my firewall my trunk ends up in a Registration Sent state. When it is in this state that is when I see the delay. I don't know how to force it into this state to test.

Once the timeout is exceeded I see the following in the log:
-- SIP/callwithus-000000c3 is circuit-busy
== Everyone is busy/congested at this time (1:0/1/0)

HC

 

[gregc]

I have a similar question/issue.

What happens if your call does go through to the provider but takes more than a few seconds to connect? I'm having that issue with a provider where some calls take 40+ seconds before they ring.

Is there anyway to have it timeout if there is a delay in the called time and ring/progress time of more than a predetermined amount?

[2011-05-05 09:39:40] VERBOSE[22499] logger.c:     -- Called flowroute-out/1509XXXXXXX
[2011-05-05 09:40:20] VERBOSE[22499] logger.c:     -- SIP/flowroute-out-00000175 is ringing
[2011-05-05 09:40:22] VERBOSE[22499] logger.c:     -- SIP/flowroute-out-00000175 is ringing

[2011-05-05 09:43:19] VERBOSE[22619] logger.c:     -- Called flowroute-out/1509XXXXXXX
[2011-05-05  09:43:53] VERBOSE[22619] logger.c:     -- SIP/flowroute-out-00000181 is  making progress passing it to SIP/105-00000180

Flowroute is working on the issue, but it would be nice if there was a failover option to go to the next provider in my trunk settings.

-Greg

 

[gregc]

Having this issue again.

Any ideas about how to set a trunk timeout when the connection time is more then 5 seconds (so that the call moves on to the next trunk in the outgoing route)?

I see on this page they have a timeout parameter. But it is referencing outdated versions of asterisk.

Any ideas??

-Greg

 

[jackal]

Hmm, this question has been asked several times in several different threads here, but I haven't seen anyone ever post an answer. (Sorry for the necropost...this is the most "active" threads with this question--the others all died out when no one replied.)

So...any updates on how to customize the timeout before it fails over to the next trunk in the outbound route?

I'm having a similar issue with Flowroute as mentioned above, where it looks like the call is being successfully passed, but it never connects. After 30 seconds, it'll fail over to the next trunk, but that's too long. If it doesn't go in the first 10 or even 5 seconds, I'd like it to roll over to the next trunk. Is there a way to configure this anywhere (ideally, on a per-trunk basis--I'd like to give my AnveoDirect LCR trunks more time to test and failover internally to their network, but I'll take a global config if necessary)?

 

[briankelly63]

May be of help:

https://groups.google.com/forum/#!topic/nzvoip/osmkhS4Ykc0

 

[jackal]

May be of help:

https://groups.google.com/forum/#!topic/nzvoip/osmkhS4Ykc0

Thanks. A lot of off-topic discussion of FreeSWITCH there, but this nugget is I think what is most helpful:

Having gone and looked at the SIP protocol spec
(http://www.ietf.org/rfc/rfc3261.txt) I think thing I care about is that
we get from Calling to Proceeding state fairly quickly (ie, "stuff is
happening, please wait"), which happens when the "100 Trying" status
comes back (or 183/Early Media). This appears to be controlled by Timer
B in the SIP protocol, which defaults to 64*T1, which in turn defaults
to 64*0.5s = 32s. Unfortunately I'm not clear if Timer B is supposed to
be cancelled after moving into Proceeding state or not -- the spec seems
to imply that it should get cancelled, which would be convenient for me.

Asterisk 1.6 seems to add a "timerb" SIP option (both in the [general]
section and per-peer section) which should allow setting this value;
Freeswitch allows setting T1x64 (which controls Timer B and a few other
timers with similar meanings for other-than-INVITE cases).

I'm finding precious little online with regards to documentation about this parameter and what it does, and it doesn't appear to exist in any of the files in /etc/asterisk, so while I could add it to sip_*.conf (sip_custom_post.conf?), I have no idea what the parameter does and what else it might break. Any tips or ideas?

FWIW, something slightly different seems to be happening than is discussed in that Google Groups thread--in my case, it's not that the provider (peer) is down but rather that the provider is reachable and is trying to pass the call but something is wrong with the route and the call can't complete. Eventually, the trunk times out and Asterisk moves on to the next trunk, but the Yealink W52P I installed here has a hard cutoff of about 30 seconds, where if the call does not proceed to a certain state (RINGING?) by that time, the call times out.

I did some testing with a softphone that doesn't timeout as quickly as my Yealink W52P, and I could then actually hear the call progress through several iterations of "The number you are calling cannot be reached from your area" as each provider presumably was trying different routes until finally one worked (a good 2-3 minutes into the call). I worked around it by defining a new outbound route and forcing caller ID (apparently the ILEC and CLEC in Alaska don't like calls to toll-free numbers they own/host being passed to them from an out-of-state provider but with a 907 area code attached to the CID...it works fine if I call from a local landline/cell or if I call via a SIP provider and force a non-907 area code), so at least the case that I encountered and would be the most prevalent problem is OK for now.

 

[briankelly63]

When all is said and done this sounds more like a carrier selection and routing issue. Reminds me of some of the issues I used to have before switching to Anveo Direct which gave me much more control over outbound routing.
Calls should just go through, with a good provider and proper routing they do.

 

[jackal]

When all is said and done this sounds more like a carrier selection and routing issue. Reminds me of some of the issues I used to have before switching to Anveo Direct which gave me much more control over outbound routing.
Calls should just go through, with a good provider and proper routing they do.

I just tried with native caller ID over Anveo Direct.

One sailed through immediately on ISP Telecom OnNet. (Ironically, this was to GCI, the published support 800 number for the Alaska-based CLEC that currently owns the CID I'm spoofing on this trunk as I prepare to port my number away from them).

Another (to RAVN, a local Alaska-based regional airline carrier) did complete on IDT Platinum after a long delay--the Anveo SIP logs show 26 seconds for Anveo to respond with a 102 INVITE.

The third and fourth (both to Northern Air Cargo, a local freight cargo operations in Alaska, and both on IDT Platinum, according to the Anveo CDR) both failed with a 102 CANCEL in Anveo's SIP logs.

(I specify the callees to establish that these are decidedly local Alaska companies who most certainly get their toll-free DIDs from either ACS or GCI, the ILEC and CLEC for Anchorage, respectively--these would not be toll-free DIDs hosted out-of-state.)

I think I simply have to go back to spoofing an out-of-state number when calling TF numbers. Seemingly, ACS and/or GCI simply can't (or don't want to) properly handle billing Alaska intrastate rates if the actual carrier is a third-party--I'm guessing that ACS and GCI have negotiated fairly favorable rates with each other (as normally, TF inbound rates can hit the double-digits of cents per minute if the caller has a 907 area code, and we in Alaska in years past have had issues calling out-of-state TF numbers that block Alaskan callers), and something about the carrier being Lower-48-based but presenting a 907 area code screws something up such that ACS and/or GCI can't (or don't want to) complete the call.

Anyway, back to the topic of this thread--the preference would be to attempt the normal, preferred trunk with the normal (actual, local-to-Alaska) CID, but if the trunk does not complete the call within a specified time, the PBX should roll onto a subsequent trunk (on which I would spoof an out-of-state CID). The default wait time before trying a subsequent trunk is too long and causes my Yealink W52P to time out and hang up before the PBX gets a chance to get to a working route. Hence my post to this thread looking to see if any solution had been devised.

 

[briankelly63]

At least with anveo you can pick the carrier and route right down to the number and know whats going on with the anveo sip traces.