<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<pre style="white-space: pre-wrap; color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-style: initial; text-decoration-color: initial;">On Thur, Dec 20, 2018 at 10:57 AM Kevin Harwell <a class="moz-txt-link-rfc2396E" href="mailto:kharwell@digium.com"><kharwell@digium.com></a>
> 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.
</pre>
</body>
</html>