[asterisk-dev] Asterisk 16 Parking Lot Full behavior.

[Steve Sether]

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 at parkCall:3] NoOp("SIP/usitest-XXXXXXXXXXXX-00000024", ""Before blind parkAndAnnounce"") in new stack
-- Executing [blind at parkCall:4] ParkAndAnnounce("SIP/usitest-XXXXXXXXXXXX-00000024", "usitest-main,c(callParking_timeout,s,1)t(600),silence/1:PARKED,Local/usitest-64167f3a547e at 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.rose at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20181220/f5c27417/attachment.html>