<div dir="ltr">Since you know it's returning a non-zero value which is causing it to hangup the call, you can work around this by putting your <span style="white-space:pre-wrap">ParkAndAnnounce as the arguments to a TryExec application. This does seem like a bug though. It shouldn't be exiting non-zero, it should be exiting with zero and setting an error value.</span></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Dec 20, 2018 at 10:24 AM Steve Sether <<a href="mailto:ssether@usinternet.com">ssether@usinternet.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  

    
  
  <div bgcolor="#FFFFFF">
    <pre>I've been focusing on a few other things lately, so it's taken me a bit to circle back to this.

The call doesn't appear to move to the next line in the dialplan when the lot is full.

The console output looks like this:

-- Executing [blind@parkCall:3] NoOp("SIP/usitest-XXXXXXXXXXXX-00000024", ""Before blind parkAndAnnounce"") in new stack
-- Executing [blind@parkCall:4] ParkAndAnnounce("SIP/usitest-XXXXXXXXXXXX-00000024", "usitest-main,c(callParking_timeout,s,1)t(600),silence/1:PARKED,Local/usitest-64167f3a547e@parkCall_do_park") in new stack
[2018-12-20 10:02:22] NOTICE[8035][C-00000016]: parking/parking_bridge.c:150 generate_parked_user: Failed to get parking space in lot 'usitest-main'. All full.
== Spawn extension (parkCall, blind, 4) exited non-zero on 'SIP/usitest-XXXXXXXXXXXX-00000024'



The relevant part of the dialplan looks like this:

 same => n,NoOp("Before blind parkAndAnnounce")
 same => n,ParkAndAnnounce(${DYNAMICPARKINGNAME},c(callParking_timeout,s,1)t(${HASH(lot_info,park_time)}),silence/1:PARKED,Local/${DIALEDPEERNUMBER}@parkCall_do_park)
 same => n,NoOp("After blind parkAndAnnounce")

I can provide any more information anyone requests.

On Wed, Nov 28, 2018 at 13:05 PM Jonathan Rose <<a href="mailto:asterisk-dev%40lists.digium.com?Subject=Re%3A%20%5Basterisk-dev%5D%20Asterisk%2016%20Parking%20Lot%20Full%20behavior.&In-Reply-To=%3CCABkuVgKHhzWdFxwq1D-BtbNFY79PmQ3HXArvEtwSsQ1CBo1Q_A%40mail.gmail.com%3E" title="[asterisk-dev] Asterisk 16 Parking Lot Full behavior." target="_blank">jonathan.rose@motorolasolutions.com</a>>
wrote:

> That's a bit of a flawed approach. The highest parking space can be
> occupied while other spots are open. Parked calls don't get shuffled to
> lower spots as lower numbered parking spots are freed up. Plus there are
> multiple modes for selecting the parking space for a call. That would be a
> safer method to use for findslot=first since you'd only hit false negatives
> if the parking lot was filling up for at least a little while, but if
> findslot=next then you could any number of calls in the parking lot when
> that space has a user in it.

> I checked through the park_and_announce application for differences in how
> it would handle a transfer and didn't really see anything that should cause
> these kinds of differences. If parking fails it looks like it'll move on in
> the dialplan in the same fashion as the regular park application. So I
> don't really think that's the culprit here.

> Consider running us through an example of it happening with verbosity set
> to 3 so that we can get running dialplan output</pre>
  </div>

-- <br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.api-2Ddigital.com&d=DwIGaQ&c=q3cDpHe1hF8lXU5EFjNM_A&r=50uagQBTpQAKCx3KjAwJcMd6ygCPToAyDAxH5npANtf7nLmyZ65ofHGUgyJr9BW8&m=gQ9QRcKPRY19PWapuCTKjacOL6Sat8UCIVj8G4ZSMoU&s=n_sSshKmKcRUA672c_2jR_PhPN41s2AzpHvYT7ry8qQ&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.com/v2/url?u=http-3A__www.api-2Ddigital.com&d=DwIGaQ&c=q3cDpHe1hF8lXU5EFjNM_A&r=50uagQBTpQAKCx3KjAwJcMd6ygCPToAyDAxH5npANtf7nLmyZ65ofHGUgyJr9BW8&m=gQ9QRcKPRY19PWapuCTKjacOL6Sat8UCIVj8G4ZSMoU&s=n_sSshKmKcRUA672c_2jR_PhPN41s2AzpHvYT7ry8qQ&e=</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
   <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.digium.com_mailman_listinfo_asterisk-2Ddev&d=DwIGaQ&c=q3cDpHe1hF8lXU5EFjNM_A&r=50uagQBTpQAKCx3KjAwJcMd6ygCPToAyDAxH5npANtf7nLmyZ65ofHGUgyJr9BW8&m=gQ9QRcKPRY19PWapuCTKjacOL6Sat8UCIVj8G4ZSMoU&s=tLfx3WibHLD9ypbxNpYHcbjIQM_IENrzkBIFmrGDkRI&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.digium.com_mailman_listinfo_asterisk-2Ddev&d=DwIGaQ&c=q3cDpHe1hF8lXU5EFjNM_A&r=50uagQBTpQAKCx3KjAwJcMd6ygCPToAyDAxH5npANtf7nLmyZ65ofHGUgyJr9BW8&m=gQ9QRcKPRY19PWapuCTKjacOL6Sat8UCIVj8G4ZSMoU&s=tLfx3WibHLD9ypbxNpYHcbjIQM_IENrzkBIFmrGDkRI&e=</a></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div><b>Jonathan R. Rose<br></b><span><span>Senior Systems Engineer<br><br></span></span></div>Emergency CallWorks<br></div>Motorola Solutions<br><br></div><div>email: <a href="mailto:jonathan.rose@motorolasolutions.com" target="_blank">jonathan.rose@motorolasolutions.com</a><br></div></div></div></div>