On Wed, Dec 26, 2018, at 3:59 PM, Steve Sether wrote:
> Jira seems to be closed to outsiders opening bug reports. I'm happy to
> open one, but I don't have access. Is there some other way I can open
> a bug report? IIRC Jira charges per user, so if that's the case I can
> certainly see why
On 12/26/2018 2:58 PM, Steve Sether wrote:
Jira seems to be closed to outsiders opening bug reports. I'm happy to open
one, but I don't have access. Is there some other way I can open a bug report?
IIRC Jira charges per user, so if that's the case I can certainly see why they
don't want to
Jira seems to be closed to outsiders opening bug reports. I'm happy to open
one, but I don't have access. Is there some other way I can open a bug report?
IIRC Jira charges per user, so if that's the case I can certainly see why they
don't want to create an account for one user creating a
On Fri, Dec 21, 2018 at 12:56 PM Steve Sether
wrote:
> Thanks for suggesting TryExec. It works perfectly as a workaround for what I
> want to do, and I can play an error message when the park fails.
>
> Should I open up a bug report in Jira for this? I assume it's open to the
> public.
>
>
Thanks for suggesting TryExec. It works perfectly as a workaround for what I
want to do, and I can play an error message when the park fails.
Should I open up a bug report in Jira for this? I assume it's open to the
public.
On Thu, Dec 20, 2018 at 10:57 AM Jonathan Rose
> The call doesn't appear to move to the next line in the dialplan when the lot
> is full.
If this is an urgent issue, could you use this closed issue’s example code to
check whether the last slot is full before attempting ParkAndAnnounce?
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
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--0024",
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
If you are using parking hints you can query the state of the hint and see
if the highest numbered spot is available.
ExecIf($["${EXTENSION_STATE(709@parkedcalls)}" = "INUSE]?Playback(lot-full))
On Wed, Nov 28, 2018 at 10:19 AM Steve Sether
wrote:
> >*ParkAndAnnounce
> *
> > I actually missed
/ParkAndAnnounce /
I actually missed this detail from the original email. Yeah,
ParkAndAnnounce might also behave a lot differently since it's going to
involve the origination of channels. Honestly instead of relying on that
you could simply have some script listen to manager for ParkedCall
>ParkAndAnnounce
I actually missed this detail from the original email. Yeah,
ParkAndAnnounce might also behave a lot differently since it's going to
involve the origination of channels. Honestly instead of relying on that
you could simply have some script listen to manager for ParkedCall events
This might work better in general if you use DTMF feature transfers to park
instead of trying to use an on-phone transfer button to send the call to a
park extension. Asterisk has internal logic to check an extension that you
send a parked call to and will rely on res_parking functionality to
I'm testing the behavior of when the parking lot is full. I came across
this post from Asterisk 12 beta, 5 years ago that describes the behavior
I'm seeing.
I call ParkAndAnnounce, and when the lot is full Asterisk drops the
call, and sends a BYE to the caller. This just doesn't work for
14 matches
Mail list logo
