Assuming the dialplan knows anything about the state of the call file that triggered it, and/or not testing for such state.
Expecting the dialplan to continue on no-answer without setting a time limit on the Dial call (which needs to less than that from the call file system).
Using the deprecated chan_sip channel driver.
Testing for ANSWER without using the g option on Dial (without g, the dialplan stops immediately after Dial, for answered calls), so DIALSTATUS will never be ANSWER.
On (1), you will need to use AstDB, or global variables, to track the state of the call (I guess you could also read the call file, which I assume gets updated after each try). Although you could do the whole sequence in the dialplan, but you’d run into the time limit for call file calls.
I’m not sure of any official way of doing that. I guess you would have to encode the call file name into the extension and read the actual call file.
In the call file, for the overall time and in the Dial application parameters, for the Dial application.
In the Dial application options, although it wouldn’t do anything useful with your current dialplan, as you would end up going straight to Hangup, which is the default for answered call with no g option.
Hi, I see the documentation, but I still have the same problem.
I don’t understand the various options well, therefore I have integrate a timeout (200 seconds), to manage retrys on the call file, but not execute the second chiamata.
[dialinternal2]
exten => 7001,1,Dial(SIP/7001, 200)
same => n,ExecIf($["${DIALSTATUS}" != "ANSWER"]?Dial(SIP/${DEST2}@SIPtrunkCisco))
same => n,Hangup
FileCall
MaxRetries: 2
RetryTime: 60
WaitTime: 20
I have used too goto:
[dialinternal2]
exten => 7001,1,Dial(SIP/7001,200,G(ESTERN_PHONE))
same => n(ESTERN_PHONE),Dial(SIP/${DEST2}@SIPtrunkCisco))
same => n,Hangup
also in this case it does not make the second call
You need to hire someone who does. You are trying to do something which is unusual; that means you really need a good understanding of how thing work and what is possible, or to delegate that to someone else.
Note that g is not the same as G. Your dialplan will call the second number even if the first number answers, and in that case, it will immediately drop the successful call to the first number, to make a, possibly unsuccessful, call to the second number, which doesn’t make sense.
Your call file timeout is an order of magnitude less than the Dial timeout, so DIal will not timeout, and will not generate a NOANSWER status.
As suggested before, you will need something to act as an explicit state variable to tell you whether you are on the third attempt.
Note I don’t do paid consultancy work, and there is more to that than a quick solution; it needs to be properly specified and tested, and it also needs to be maintained, as it seems likely that you will not know how to change it to meet future requirement changes.