Possible race conditions with AGI scripts?

Asterisk Asterisk APIs
1

So I have some existing php AGI scripts that have been around for years. We were having some delays .. a little over a second from the initial answering of a call and the next AGI script that might be called.

Our initial php script cpinbound.php is the script that handles answering the call. At the end of this script there is a for loop that plays a second of silence to keep the channel alive until a next script might execute. Here’s the code.

for($i = 0; $i < 15; $i++) {
    $test_hangup = $agi->stream_file('silence/1','','');
    if($test_hangup['result'] < 0 || $test_hangup['code'] >= 500) {
        syslog(LOG_NOTICE, "UII=$UII cpinbound.php: alert: DNIS $dnis stream_file 'silence/1' failed, result: " . $test_hangup['result'] . ", code: " .$test_hangup['code']);
        sleep(1);
        exit;
    }
}

So we removed the sleep(1) and the delay went away. But now sometimes when a new AGI script is executed, we’ll get a CANCEL. I have no idea why the original sleep(1) was put there, but assume it is to avoid possible race conditions.

Here’s the AMI message that occurs sometimes when the next script has been Redirected.

Action: Redirect|Channel: PJSIP/sip_proxy_7-000006f4|Exten: cpplay|Context: cpcommands|Priority: 1|"

And here’s the AMI cancel:

Action: CANCEL|Channel=PJSIP/sip_proxy_7-000006f4|UII: 1770917094-000000000001006568-SR-000-000000000000DEN140-51432CAA|Session: 01|Reason: REJECT timeout|

Are there any known issues with race conditions between AGI execution on the same channel? Could the tear down of the previous cpinbound.php AGI call somehow conflict with the next AGI script that is executed?