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.
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.
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.