Fast busy and voip server failover

Asterisk Asterisk Support
1

I have several VOIP servers that I use to make outgoing calls.
So here is my simple dial out configuration for 10 digit dialing.

[macro-dial]
exten => s,1,Dial(SIP/${ARG1}@voicemeup,45,)
exten => s,n,Dial(SIP/${ARG1}@voipms,45,)

[dialout]
exten => _1XXXXXXXXXX,1,Macro(dial,${EXTEN:1})
exten => _1XXXXXXXXXX,n,Dial(SIP/${EXTEN}@pstn,15,)

So when I make a call, usually the first voip server handles the call unless it is unreachable for whatever reason. If neither server is reachable (say the internet is down), the call is sent to the pstn.

But here is the problem. The Dial() command succeeds and does not return (that is, it connects to the voip server successfully) even when the voip server has some internal problem and cannot make the call and just plays fast busy to the caller.

Is there a way to detect fast busy (and perhaps other symptoms, like no audio) and allow the dial command to fall through to the next voip server? Ideally, all while still sending ring tone to the caller.

2

You should use ${DIALSTATUS} or ${HANGUPCAUSE} variables to write a more efficient dialing failover

3

No. His problem is that the ITSP is broken and is answering the call before the PSTN destination answers.

4

Any particular or common reason that could lead to this behavior in a ISTP David?

5

It’s an easy way of making sure that early media works (i.e. turn it into normal media). If you are primarily providing a service to phones, rather than PABXes, it doesn’t matter that you actually answer the call.

(You will actually find that a lot of the Asterisk dialplans you see here unnecessarily answer the incoming call before initiating the outgoing call, and I think that FreePBX always does that.)

6

Actually, the OP may be wrong and the call may not be succeeding, but actually still be in early media, in which case the problem lies with the PSTN operator, who is signalling busy in band, as early media, rather than than as a clearing cause.

You would need to turn up the logging from the nothing provided until you saw the Ringing, Progress, Answered etc. status. If the call reaches Progress, but not Answered, it is not successful, but rather in early media.

Asterisk cannot tell the difference between early media used to play ringback, used for free information lines, or used to play back failure tones.

If it is still in early media, it will failover after 45 seconds, or the network gets tired of sending early media.

7

Its clear to me that the real source of the problem is the ITSP. When I opened a ticket with the ITSP, I said:

But I did not receive any answer to that question.

It may be true that when the problem occurs, asterisk is still in early media, and will fail the call in 45 seconds. Adding logging would aid in diagnosing that aspect. But the caller doesn’t want to wait 45 seconds before the next server is tried.

I guess I just need to find an ITSP that works better with asterisk.