<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" 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.">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>
</body>
</html>