I have some providers to make calls, but if some routes are not completed for one provider, I forward it for another route(provider), with my actual dialplan this problem is solved ok. But I generate others problem, like if the call was refused the system try again, until pass for my last contingency route, total are 4 routes, and this is not good.
The same occurs if the destiny number is busy, or if the number doesn’t existe. How can I solve it with the best solution?
Other problem is that I generate many register in my CDR table for bill, with wrong informations.
My actual dialplan:
exten => _XXXXXXX.,1,Dial(SIP/saida-solaris_c/5576055${CALLERID(num):0:2}${EXTEN},90/nj,tT)
same => n,ExecIf([${HANGUPCAUSE}=19]?Dial(SIP/saida-solaris_b/160155${CALLERID(num):0:2}${EXTEN},90/nj,tT))
same => n,ExecIf([${HANGUPCAUSE}=19]?Dial(SIP/saida-solaris/001110155${CALLERID(num):0:2}${EXTEN},90/nj,tT))
same => n,ExecIf([${HANGUPCAUSE}=19]?Dial(SIP/backup-saida-myvoiptraffic/55${CALLERID(num):0:2}${EXTEN},90/nj,tT))
You need to address this to your SIP provider, as it looks like they are not distinguishing different failure causes. Of course it could be the PSTN network that is using in band voice announcements, rather than giving proper cause codes. I assume any reasonable SIP provider would use ISDN, and not analogue connections, as analogue is not capable of distinguishing these cases.
Your dialplan seems to be adequate. The problem is that cause code 19 is being used for more things than you want it to be. The only other possibility is to read the actual SIP status code, but I suspect that is also always the same.
Actually 19 probably isn’t the right condition. It means that there was no answer, which, in an ideal world would not be worth trying on an alternative route. I would actually check for multiple cause codes, but if you are getting 19 for network congestion, I would say you had a problem with your provider, that needs addressing with the provider.
No. Telephone networks don’t work that way; you cannot ask whether a call will fail; you have to make the call and handle the error.
Also, note, in the typical ITSP system, the ITSP will make a real ISDN call, map the cause code into the nearest SIP final status, then Asterisk will map that status into an ISDN cause code. That process is lossy. If you want to avoid the lossiness, you need to cut out the ITSP and use an ISDN card in Asterisk to go direct to ISDN.
Even then, as I suggested before, the PSTN may not send an ISDN cause code, it may just send an SIT sequence and then a voice announcement saying something like “all lines to xyz are busy”.
In any case, if you have congestion, the congestion might arise between when you tested and when you make the call.
My ITSP has many returns of ISDN but I don’t treat the many errors of ISDN because was complicated in the first time, when I found a problem and should to resolve soon, then I solve the problem but now I am in this situation.
I think the best form to solve it is treat the many differents returns of ISDN, but I only don’t want to do it one by one, wish reuse the dialplan of anyone if it already exists.
In most cases, you ONLY need to handle CONGESTION and CHANUNAVAIL for failover. Many of the other ISDN messages indicate issues on the called party side. i.e. BUSY
[OUTBOUND]
exten => _X.,1,NoOp(Trying Provider One)
same => n,Dial(SIP/provider01/${EXTEN})
same => n,GotoIf($["${DIALSTATUS}"="CONGESTION"]?PROVIDER02,${EXTEN},1)
same => n,GotoIf($["${DIALSTATUS}"="CHANUNAVAIL"]?PROVIDER02,${EXTEN},1)
[PROVIDER02]
exten => _X.,1,NoOp(Trying Provider Two)
same => n,Dial(SIP/provider02/${EXTEN})