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 <jonathan.r...@motorolasolutions.com
<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>>
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
--
_____________________________________________________________________
-- 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
