https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r302785 | russell | 2011-01-19 16:35:15 -0600 (Wed, 19 Jan 2011) | 15 lines
Resolve a memory leak with the manager interface is disabled.
The intent of this check as it stands in previous versions of Asterisk was to
check if there are any active sessions. If there were no sessions, then the
function would return immediately and not bother with queueing up the manager
event to be processed. Since the conversion of storing sessions in an astobj2
container, this check will always pass. I changed it to go back to checking
what was intended.
The side effect of this was that if the AMI is disabled, the manager event
queue is populated anyway, but the code that runs to clear out the queue
never runs. A producer with no consumer is a bad thing.
Reported internally by kmorgan.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302786 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302713 | rmudgett | 2011-01-19 15:29:22 -0600 (Wed, 19 Jan 2011) | 29 lines
Merged revisions 302693 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302693 | rmudgett | 2011-01-19 15:25:41 -0600 (Wed, 19 Jan 2011) | 22 lines
Merged revisions 302671 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302671 | rmudgett | 2011-01-19 15:21:56 -0600 (Wed, 19 Jan 2011) | 15 lines
DTMF transfer plays the wrong sounds for wrong number or other call failure.
* Set the default for features.conf.sample xferfailsound option to "beeperr"
as documented instead of "pbx-invalid" and corrected the use of it in DTMF
blind transfer (#1).
* Improved DTMF blind transfer handling of wrong numbers.
Most of the concerns in this issue were taken care of by the patch for
issue 17999: Issues with DTMF triggered attended transfers.
(closes issue #18379)
Reported by: gincantalupo
Tested by: rmudgett
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302732 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302634 | tilghman | 2011-01-19 14:24:57 -0600 (Wed, 19 Jan 2011) | 22 lines
Merged revisions 302599 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r302599 | tilghman | 2011-01-19 14:13:24 -0600 (Wed, 19 Jan 2011) | 15 lines
Kill zombies.
When we ast_safe_fork() with a non-zero argument, we're expected to reap our
own zombies. On a zero argument, however, the zombies are only reaped when
there aren't any non-zero forked children alive. At other times, we
accumulate zombies. This code is forward ported from res_agi in 1.4, so that
forked children are always reaped, thus preventing an accumulation of zombie
processes.
(closes issue #18515)
Reported by: ernied
Patches:
20101221__issue18515.diff.txt uploaded by tilghman (license 14)
Tested by: ernied
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302644 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302555 | seanbright | 2011-01-19 14:03:32 -0500 (Wed, 19 Jan 2011) | 14 lines
Merged revisions 302554 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r302554 | seanbright | 2011-01-19 14:02:29 -0500 (Wed, 19 Jan 2011) | 7 lines
Don't call strlen() when we only need to look at the next character or two.
(closes issue #18042)
Reported by: wdoekes
Patches:
astsvn-inefficient-ast-uri-decode.patch uploaded by wdoekes (license 717)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302556 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302549 | seanbright | 2011-01-19 13:43:11 -0500 (Wed, 19 Jan 2011) | 17 lines
Merged revisions 302548 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r302548 | seanbright | 2011-01-19 13:37:09 -0500 (Wed, 19 Jan 2011) | 10 lines
Properly handle partial reads from fgets() when handling AGIs.
When fgets() failed with EAGAIN, we were continually decrementing the available
space left in our buffer, resulting in botched command handling.
(closes issue #16032)
Reported by: notahat
Patches:
agi_buffer_patch2.diff uploaded by fnordian (license 110)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302550 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r302412 | seanbright | 2011-01-19 10:31:39 -0500 (Wed, 19 Jan 2011) | 10 lines
Use appropriate type for requested format in chan_local.
We were passing and storing the requested format as an int instead of format_t
resulting in truncation.
(closes issue #18238)
Reported by: whizemen
Patches:
0018238_speex16.patch uploaded by whizemen (license 1143)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302413 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302266 | jpeeler | 2011-01-18 14:19:57 -0600 (Tue, 18 Jan 2011) | 34 lines
Merged revisions 302265 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r302265 | jpeeler | 2011-01-18 14:13:52 -0600 (Tue, 18 Jan 2011) | 27 lines
Convert device state callbacks to ao2 objects to fix a deadlock in chan_sip.
Lock scenario presented here:
Thread 1
holds ast_rdlock_contexts &conlock
holds handle_statechange hints
holds handle_statechange hint
waiting for cb_extensionstate
Locked Here: chan_sip.c line 7428 (find_call)
Thread 2
holds handle_request_do &netlock
holds find_call sip_pvt_ptr
waiting for ast_rdlock_contexts &conlock
Locked Here: pbx.c line 9911 (ast_rdlock_contexts)
Chan_sip has an established locking order of locking the sip_pvt and then
getting the context lock. So the as stated by the summary, the operations in
thread 2 have been modified to no longer require the context lock.
(closes issue #18310)
Reported by: one47
Patches:
statecbs_ao2.mk2.patch uploaded by one47 (license 23),
modified by me
Review: https://reviewboard.asterisk.org/r/1072/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302270 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r293493 | twilson | 2010-11-01 09:58:00 -0500 (Mon, 01 Nov 2010) | 14 lines
Only offer codecs both sides support for directmedia
When using directmedia, Asterisk needs to limit the codecs offered to just
the ones that both sides recognize, otherwise they may end up sending audio
that the other side doesn't understand.
(closes issue #17403)
Reported by: one47
Patches:
sip_codecs_simplified4 uploaded by one47 (license 23)
Tested by: one47, falves11
Review: https://reviewboard.asterisk.org/r/967/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302048 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r301946 | rmudgett | 2011-01-14 15:09:57 -0600 (Fri, 14 Jan 2011) | 13 lines
Deadlock between dahdi_request() and pri_dchannel() processing an incomming call.
The sig_pri_new_ast_channel() is called with the channel private lock held
when pri_dchannel() calls it and no channel private lock held when
dahdi_request() calls it. The use of pri_grab() in
sig_pri_new_ast_channel() could leave the channel private lock held when
it returns if the lock was not held before calling it.
Make sig_pri_new_ast_channel() just lock the PRI span lock instead of
using pri_grab(). It is safe to do this because dahdi_request() does not
have the channel private lock and the deadlock potential with the PRI span
lock is only between pri_dchannel() and other threads.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@301947 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r301790 | jpeeler | 2011-01-14 11:32:52 -0600 (Fri, 14 Jan 2011) | 42 lines
Resolve deadlock involving REFER.
Two fixes:
1) One must always have the private unlocked before calling
pbx_builtin_setvar_helper to not invalidate locking order since it locks the
channel.
2) Unlock the channel before calling pbx_find_extension, which starts and stops
autoservice during the lookup. The problem scenario as illustrated by the
reporter:
Thread: do_monitor
-----------------------
handle_request_do
handle_incoming
handle_request_refer
ast_parking_ext_valid
pbx_find_extension
ast_autoservice_stop
while (chan_list_state == as_chan_list_state) { usleep(1000); }
Thread: autoservice_run
-----------------------
autoservice_run
chan = ast_waitfor_n
ast_waitfor_nandfds
ast_waitfor_nandfds_classic / simple / complex (depending on your system)
ast_channel_lock(c[x]);
handle_request_do and schedule_process_request_queue locks the owner
if it exists. The autoservice thread is waiting for the channel lock, which
wasn't ever released since the do_monitor thread was waiting for autoservice
operations to complete. Solved by unlocking the channel but keeping a reference
to guarantee safety.
(closes issue #18403)
Reported by: jthurman
Patches:
20110103-blind_deadlock.diff uploaded by jthurman (license 614)
issue18403.patch uploaded by jpeeler (license 325)
Tested by: jthurman
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@301791 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r301595 | mnicholson | 2011-01-12 12:51:37 -0600 (Wed, 12 Jan 2011) | 22 lines
Merged revisions 301594 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r301594 | mnicholson | 2011-01-12 12:50:31 -0600 (Wed, 12 Jan 2011) | 15 lines
Removed a usleep(1) that shouldn't be necessary in session_do, and removed the
ms_t member from the mansession_session structure.
Merged revisions 301591 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r301591 | mnicholson | 2011-01-12 12:39:03 -0600 (Wed, 12 Jan 2011) | 5 lines
Don't store the thread id for the manager session in the structure we pass to
the thread for the manager session.
ABE-2543
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@301596 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r301504 | jpeeler | 2011-01-12 12:12:08 -0600 (Wed, 12 Jan 2011) | 26 lines
Merged revisions 301503 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r301503 | jpeeler | 2011-01-12 12:11:49 -0600 (Wed, 12 Jan 2011) | 19 lines
Merged revisions 301502 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r301502 | jpeeler | 2011-01-12 12:10:42 -0600 (Wed, 12 Jan 2011) | 12 lines
Fix CPU spike when pressing DTMF after agent login.
The problem here is that DTMF was being continuously deferred and requeued
since ast_safe_sleep is called in a loop. There are serveral other places in the
code that sleeps and then loops in a similar fashion. Because of this fact I
opted to not defer DTMF any more, which will not affect the original fix:
https://reviewboard.asterisk.org/r/674
(closes issue #18130)
Reported by: rgj
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@301505 65c4cc65-6c06-0410-ace0-fbb531ad65f3
the warning, if no user interface for menuselect warning was found is not right.
you have to rerun configure before make menuselect after installing a proper user interface.
(closes issue 0018594)
Reported by: Dovid
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@301445 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r301221 | pabelanger | 2011-01-09 16:40:34 -0500 (Sun, 09 Jan 2011) | 21 lines
Merged revisions 301220 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r301220 | pabelanger | 2011-01-09 16:38:24 -0500 (Sun, 09 Jan 2011) | 14 lines
SOUND_CACHE_DIR now defaults to empty
Sounds files included in the Asterisk tarball were being ignored and
re-downloaded. Users wanting to cache the files can still override the setting
using the --with-sounds-cache option.
(closes issue #18589)
Reported by: pabelanger
Patches:
issue18589.patch uploaded by pabelanger (license 224)
Tested by: pabelanger
Review: https://reviewboard.asterisk.org/r/1074/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@301222 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r301134 | rmudgett | 2011-01-07 19:11:31 -0600 (Fri, 07 Jan 2011) | 7 lines
The DTMF attended transfer feature cannot callback a chan_dahdi BRI phone.
The DAHDI ISDN channel name is not dialable.
Make a channel name like DAHDI/i3/400-12 dialable when the sequence number
is stripped off of the name.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@301135 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r301047 | jpeeler | 2011-01-07 13:58:30 -0600 (Fri, 07 Jan 2011) | 15 lines
Merged revisions 301046 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r301046 | jpeeler | 2011-01-07 13:57:42 -0600 (Fri, 07 Jan 2011) | 8 lines
Fix regression causing forwarding voicemails to not work with file storage.
I had actually already fixed this in 295200 in 1.4 and thought it wasn't
missing in the other branches for some reason.
(closes issue #18358)
Reported by: cabal95
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@301048 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r300955 | jpeeler | 2011-01-07 11:24:14 -0600 (Fri, 07 Jan 2011) | 21 lines
Merged revisions 300951 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r300951 | jpeeler | 2011-01-07 11:23:37 -0600 (Fri, 07 Jan 2011) | 14 lines
Merged revisions 300918 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r300918 | jpeeler | 2011-01-07 11:13:21 -0600 (Fri, 07 Jan 2011) | 7 lines
Ensure good bye prompt in voicemail is played at the correct time.
Specifically in the case of timing out but not leaving voicemail nothing
should be heard. And when leaving voicemail it should be heard.
ABE-2647
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@300959 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If your postgres connection died suddenly in between res_config_pgsql
queries, the next query will fail because the query is executed on a
disconnected/disconnecting handle. The query is abandoned and is
returned from in error.
Now we will reconnect and try again if a query was run on a
disconnected connection.
(closes issue #18071)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@300882 65c4cc65-6c06-0410-ace0-fbb531ad65f3
