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",
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
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
I'm testing Asterisk 16, and I'm seeing a very serious delay in
bridging, and other events being displayed in the AMI, either that, or
I'm misunderstanding how things are supposed to work.
My test setup is very simple, I'm using netcat to connect to port 5038,
and outputting to a file. I've
/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
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
On Thur, Dec 20, 2018 at 10:57 AM Kevin Harwell
Have you tested, or currently running with the exact same setup but with
another version of Asterisk and you are not seeing the delay?
I tested Asterisk 13.20 under the same dialplan and config, and I couldn't
replicate the problem after a
I'm having an issue in Asterisk 16 where when I record a new greeting,
the greeting doesn't play when I call the users voicemail.
I've tracked this down NULL being inserted into the context column of
the voicemail table. When Asterisk retrieves the greeting, and the
Context column is is
I'm having a lot of trouble getting PJSIP to send a fax via T.38 in
Asterisk 16.14.1.
From the pcap, I see the call being made, it connects, RTP goes in both
directions, the far-end requests a re-invite using t.38, Asterisk sends
an OK, the OK is acked, and the far ends starts sending t.38
This is in fact the exact problem. We use local channels when sending out
faxes.
Thanks for your quick reply.
On Tue, Dec 1, 2020 at 6:23 PM Steve Sether http://lists.digium.com/mailman/listinfo/asterisk-dev>> wrote:
/I'm having a lot of trouble getting PJSIP to send a fax vi
We've had some trouble with the AMI sometimes locking up. During this
time it won't new connections, and doesn't send out sending out data.
Running asterisk -rx "manager show eventq" can grow to over 100K events,
and many megabytes of content. Sometimes the problem seems to resolve
itself,
We've been running Asterisk 16 in a production environment for several
months. During this time we've had several times where Asterisk locks
up, and stops responding to SIP messages and won't recover until
Asterisk is restarted. RTP passes through, so existing conversations
aren't affected,
We're running Asterisk certified/16.8-cert5
I looked through the changelog for the cert versions 6 - 11, but didn't
see this fix ported to this branch. Did I miss something, or has this
fix just not been back-ported yet?
On Mon, Oct 4, 2021 at 11:12 AM Steve Sether
wrote:
> We
;.
We'll be switching back to the mainline Asterisk 16 branch.
On Mon, Oct 4, 2021 at 8:02 PM Kevin Harwell
wrote:
> On Mon, Oct 4, 2021 at 4:36 PM Steve Sether
> wrote:
>
>>
>> We're running Asterisk certified/16.8-cert5
>>
>> I looked through the changel
, this isn't a one in a million chance like
you sometimes see with deadlock/timing issues.
Please contact me, Steve Sether, sset...@usinternet.com for more
information.
Thank you.
--
--
_
-- Bandwidth and Colocation Provided
We've had a couple instances of a deadlocks recently. This happened
while we were trying to move phones from one Asterisk server to
another. It's too much to describe here what goes in in this process,
but from an Asterisk perspective it's a lot of reloading the dialplan
regenerating
16 matches
Mail list logo
