This change makes URIENCODE and QUOTE behave similarly, since the documentation
states that the argument is not optional, for both.
(closes issue #15439)
Reported by: pkempgen
Patches:
20090706__issue15439.diff.txt uploaded by tilghman (license 14)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@207945 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In certain cases, due to the way Set() works in 1.4, values may not get set
properly. This is a workaround for 1.4 only that corrects for these issues,
without making func_odbc more difficult to use properly.
(closes issue #14614)
Reported by: wdoekes
Patches:
20090309__bug14614__2.diff.txt uploaded by tilghman (license 14)
double_set_unescape_workaround_for_func_odbc.osso-and-tilghman-1.diff uploaded by wdoekes (license 717)
Tested by: wdoekes, tilghman
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@189537 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The change is to remove autoservice usage from dialplan functions that do not
need it because they do not perform operations that potentially block.
(closes issue #13940)
Reported by: tbelder
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@163253 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: john8675309
Patches:
patch.13597 uploaded by murf (license 17)
Tested by: murf, john8675309
This patch causes the setcid func to update the CDR
clid after setting the channel field.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@160703 65c4cc65-6c06-0410-ace0-fbb531ad65f3
try to find the channel by name in the list,
which is slow and resource consuming, but rather
to pay attention to the result codes from the
ast_bridge_call, to which I added the
AST_PBX_NO_HANGUP_PEER_PARKED value, which
now are returned when a channel is parked.
If you get AST_PBX_KEEPALIVE,
then don't touch the channel pointer.
If you get AST_PBX_NO_HANGUP_PEER, or
AST_PBX_NO_HANGUP_PEER_PARKED, then don't
touch the peer pointer.
Updated the several places where the results
from a bridge were not being properly obeyed,
and fixed some code I had introduced so that
the results of the bridge were not overridden
(in trunk).
All the places that previously tested for
AST_PBX_NO_HANGUP_PEER now have to check for
both AST_PBX_NO_HANGUP_PEER and AST_PBX_NO_HANGUP_PEER_PARKED.
I tested this against the 4 common parking
scenarios:
1. A calls B; B answers; A parks B; B hangs up while A is getting the parking
slot announcement, immediately after being put on hold.
2. A calls B; B answers; A parks B; B hangs up after A has been hung up, but
before the park times out.
3. A calls B; B answers; B parks A; A hangs up while B is getting the parking slot announcement, immediately after being put on hold.
4. A calls B; B answers; B parks A; A hangs up after B has been hung up, but before the park times out.
No crash.
I also ran the scenarios above against valgrind, and accesses looked good.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@152535 65c4cc65-6c06-0410-ace0-fbb531ad65f3
match the trailing \0 of a string) we need to check that first, otherwise
we end up with incorrect results. Fix suggested by reporter.
(closes issue #13787)
Reported by: meitinger
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@152059 65c4cc65-6c06-0410-ace0-fbb531ad65f3
workspace. To signal an error (and no change to the workspace), -1 should be
returned instead.
(closes issue #13340)
Reported by: kryptolus
Patches:
20080827__bug13340__2.diff.txt uploaded by Corydon76 (license 14)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@146799 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: arkadia
Tested by: murf, arkadia
Options added to forkCDR() app and the CDR() func to
remove some roadblocks for CDR applications.
The "show application ForkCDR" output was upgraded
to more fully explain the inner workings of forkCDR.
The A option was added to forkCDR to force the
CDR system to NOT change the disposition on the
original CDR, after the fork. This involves
ast_cdr_answer, _busy, _failed, and so on.
The T option was added to forkCDR to force
obedience of the cdr LOCKED flag in the
ast_cdr_end, all the disposition changing
funcs (ast_cdr_answer, etc), and in the
ast_cdr_setvar func.
The CHANGES file was updated to explain ALL
the new options added to satisfy this bug report
(and some requests made verbally and via
email, irc, etc, over the past months/year)
The 's' option was added to the CDR() func,
to force it to skip LOCKED cdr's in the
chain.
Again, the new options should be totally transparent
to existing apps! Current behavior of CDR,
forkCDR, and the rest of the CDR system should
not change one little bit. Until you add the
new options, at least!
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@122046 65c4cc65-6c06-0410-ace0-fbb531ad65f3
rizzo brought up some issues related to the way that the metadata required
for menuselect and the rest of the build system is extracted from the source
files. Since I had a few hours to kill on an airplane today, I decided to
improve this situation... so now the system caches the extracted metadata
and uses it to build the menuselect 'tree' as much as it can. The result
of this is that when a single source file is changed, only the metadata for
that file needs to be extracted again, and the rest is used from the cache
files. I also reduced the number of forked processes required to do the
metadata extraction; it was actually possible to do most of what we needed
in the Makefiles themselves without using any shell scripts at all! On my
laptop, these changes resulted in an 80% decrease in the time required
for the 'menuselect.makeopts' automatic check to occur after editing a single
source file.
While doing this work I also cleaned up a few minor things in the Makefiles,
adding a check for 'awk' to the configure script and changed all remaining
places we use 'grep' or 'awk' to use the ones found by the configure script,
and changed the 'prep_tarball' script to build the menuselect metadata so
that tarballs of Asterisk will include it and won't require the user to
wait while it is extracted after unpacking.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@93180 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The ast_set_callerid() function needed to lock the channel. Also, the handlers
for the CALLERID() dialplan function needed to lock the channel when reading
or writing callerid values directly on the channel structure.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@90145 65c4cc65-6c06-0410-ace0-fbb531ad65f3
on the existence of a channel, with no real reason. This should make func_curl
once again work without a channel.
Reported by jmls.
Fixed by tilghman.
Closes issue #11090
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@87120 65c4cc65-6c06-0410-ace0-fbb531ad65f3
