<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;">><i>ParkAndAnnounce
</i>
> I actually missed this detail from the original email. Yeah,
> ParkAndAnnounce might also behave a lot differently since it's going to
> involve the origination of channels. Honestly instead of relying on that
> you could simply have some script listen to manager for ParkedCall events
> and have that make the announcements for you. Might be better than relying
> on a separate and generally less battle tested approach to parking.

Hi Jonathan,

We're a PBX service provider that's multi-homed, so on Asterisk 11 we already have a custom solution that does mapping between virtual parking lots and the real parking lot.  It resembles a virtual memory manager in many ways. With the new parking lot in Asterisk 13+ supporting templates and creating a parking lot on-the-fly, I wanted to try to eliminate this complexity since it would reduce our complexity quite a bit.  So I suppose we could go back to that, but I'd rather not if possible.

For similar reasons, we can't stop supporting the Park feature of the Polycomm phones either since our customers rely on it.

It doesn't sound like I'm doing anything wrong, or there's any easy way around this other than scripting a solution to just see if the lot is full before performing a park.

Is there anyone from Digium that can respond to this?  Dropping the call just doesn't seem like the "right thing" for ParkAndAnnounce to do.  Can this be fixed in some way?  I could see simply just playing a message to the parkee when the call is full, and using whatever the timeout behavior is set to.  Alternatively if Asterisk simply returned the call to timeout behavior, and possibly set a channel variable like to indicate the lot is full, we could then play the message or do whatever was appropriate.  

Even adding a dialplan command to query the number of free spaces in a lot would be helpful (though still suffer from race conditions mentioned above).

I don't think we'd want to try to fix this ourselves with a patch.  We're not really C programmers, and haven't any aspirations to go down that road.
</pre>
  </body>
</html>