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

[Jonathan Rose]

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 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.

On Thu, Dec 20, 2018 at 10:24 AM Steve Sether <ssether at usinternet.com>
wrote:

> 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 <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
> 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=
> --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>
> 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=



-- 

*Jonathan R. Rose*Senior Systems Engineer

Emergency CallWorks
Motorola Solutions

email: jonathan.rose at motorolasolutions.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20181220/561f9827/attachment.html>