The most notable problem is that people have been seeing storms of VNAK frames
being sent due to really old frames mysteriously being in the retransmission
queue and never getting removed.
It was possible that a dynamic thread got created, but did not acquire its lock
before the thread that created it signals it to perform an action. When this
happens, the thread will sleep until it hits a timeout, and then get destroyed.
So, the action never gets performed and in some cases, means a frame doesn't
get transmitted and never gets freed since the scheduler never gets a chance
to reschedule transmission.
Another less severe race condition is in the handling of a timeout for a dynamic
thread. It was possible for it to be acquired to perform at action at the same
time that it hit a timeout. When this occurs, whatever action it was acquired
for would never get performed.
(patch contributed by Mihai and SteveK)
(closes issue #10289)
(closes issue #10248)
(closes issue #10232)
(possibly related to issue #10359)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77887 65c4cc65-6c06-0410-ace0-fbb531ad65f3
due to sending packets in the wrong order during hangup.
Also make sure we clear tones/messages on the correct line/instance.
Issue 10291, patch by DEA, tested by sbisker and myself.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77883 65c4cc65-6c06-0410-ace0-fbb531ad65f3
thinking the 'n' option was in use.
(closes issue #10320, reported by jfitzgibbon, patched by me, tested by blitzrage and me)
Thank you blitzrage for all the testing you've done lately with queues! It's much appreciated!
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77854 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fixes an issue where if a caller calls into a queue where no one is logged in, they would wait forever even if a member
logged in at some point.
(closes issue #10346, reported by and tested by blitzrage, patched by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77852 65c4cc65-6c06-0410-ace0-fbb531ad65f3
servers between endpoints, the Asterisk servers will not keep retransmitting the re-invites.
(closes issue #10274, reported by cstadlmann, patched by me with approval from file)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77824 65c4cc65-6c06-0410-ace0-fbb531ad65f3
request an "unknown" character such as a comma.
Instead, skip the character and move on.
Issue 10083, initial patch by jsmith, modified by me.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77795 65c4cc65-6c06-0410-ace0-fbb531ad65f3
queue. In the network_thread() loop, it traverses the list using the
AST_LIST_TRAVERSE_SAFE macro. However, to remove an element of the list within
this loop, it used AST_LIST_REMOVE, instead of AST_LIST_REMOVE_CURRENT, which I
believe could leave some of the internal variables of the SAFE macro invalid.
Mihai says that he already made this change in his local copy and it didn't help
his VNAK storm issues, but I still think it's wrong. :)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77794 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: seanbright
Patches:
res_agi.carefulwrite.1.4.07252007.patch uploaded by seanbright (license 71)
res_agi.carefulwrite.trunk.07252007.patch uploaded by seanbright (license 71)
Allow the "agi_network: yes" line to be printed out in the AGI debug output.
Also, allow partial writes to be handled when writing out this line just like
it is for all of the others.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77788 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: fnordian
Patches:
asterisk-1.4.9-channel.c.patch uploaded by fnordian (license 110)
Additional changes by me
Fix some problems in channel_find_locked() which can cause an infinite loop.
The reference to the previous channel is set to NULL in some cases. These changes
ensure that the reference to the previous channel gets restored before needing
it again.
I'm not convinced that the code that is setting it to NULL is really the right
thing to do. However, I am making these changes to fix the obvious problem
and just leaving an XXX comment that it needs a better explanation that what
is there now.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77780 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: kkiely
Instead of directly mucking with the extension/context/priority of the channel we are transferring when it has a PBX simply call ast_async_goto on it. This will ensure that the channel gets handled properly and sent to the right place.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77778 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: fnordian
Patches:
asterisk-1.4.9-channel.c.patch uploaded by fnordian (license 110)
Restore previous behavior where if we failed to lock the channel we wanted we would return to exactly the same point as if we had just reentered the function.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77771 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: prashant_jois
Patches:
cdr_pgsql.patch uploaded by prashant (license 114)
Finish the Postgresql connection after the log messages are printed so we don't access invalid memory.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77540 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: julianjm
Patches:
chan_sip_device_state_hold_fix.v1.diff.txt uploaded by julianjm (license 99)
Clear ONHOLD flag when decrementing the onHold peer count. If we did not do this the count may keep decreasing.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77536 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: litnialex
If a DTMF end frame comes from a channel without a begin and it is going to a technology that only accepts end frames (aka INFO) then use the minimum DTMF duration if one is not in the frame already.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77460 65c4cc65-6c06-0410-ace0-fbb531ad65f3
under dev mode, AST_DEVMODE will get defined in buildopts.h. Change 1.4 to
define it in the same way that trunk does. Also, revert the change that added
this define in the Makefile
The advantage to doing it this way is that buildopts.h gets installed when
you install Asterisk. Then, when building any out of tree modules, or
building asterisk-addons, these modules know which options the rest of Asterisk
was built with.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77410 65c4cc65-6c06-0410-ace0-fbb531ad65f3
attempted compilation. The makefile now defines AST_DEVMODE if configure was run with --enable-dev-mode. Also, changes were
made to acccomodate 64 bit systems in ast_backtrace.
Thanks to qwell, kpfleming, and Corydon76 for their roles in allowing me to get this committed
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77380 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch sets the connection to NULL after calls to PQfinish so that the problem does not occur.
Also in this patch, prashant_jois informed me that it is safe to pass a null pointer to PQfinish, so
I have removed the check for conn's existence from my_unload_module.
(closes issue 10295, reported by junky, patched by me with input from prashant_jois)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77318 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: jtodd
Add SPEECH_DTMF_TERMINATOR variable so the user can specify the digit to terminate a DTMF string with. If none is specified then no terminator will be used.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77176 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r76802 | qwell | 2007-07-24 11:32:04 -0500 (Tue, 24 Jul 2007) | 3 lines
Don't create the Asterisk channel until we are starting the PBX on it.
(ASA-2007-018)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@76805 65c4cc65-6c06-0410-ace0-fbb531ad65f3
