On Thur, Dec 20, 2018 at 10:57 AM Kevin Harwell <kharw...@digium.com>

Have you tested, or currently running with the exact same setup but with
another version of Asterisk and you are not seeing the delay?

I tested Asterisk 13.20 under the same dialplan and config, and I couldn't 
replicate the problem after a good 10-15 attempts. When I switched back to 16.1 
I could replicate it multiple times after 2-3 attempts.

Asterisk 11 is problematic since parking is of course quite different, but 
we've had no problems like this in several years of using the same dialplan, 
and some minor config changes with 16.


What's the exact test scenario you are running?

Probably more complicated than is worth getting into.  By simple, I meant 
merely monitoring AMI output, not the dialplan or Asterisk config.  So the 
delay isn't being caused by the component connected to the AMI.  I'll work on 
trying to provide a simple scenario with a simple dialplan next week that's 
easy to replicate, or at least figure out if there's something specific to our 
setup that causes this.


After 'n' seconds of park time are you sending the call back to the dialplan

We do do this, but I set the timeout to 10 minutes so it wouldn't interfere 
with my testing.  The delays I'm seeing are more like 30 seconds to a minute, 
and happen before the call gets sent back to the return_context I set in 
ParkAndAnnounce.

-- 
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Reply via email to