a backslash. Unfortunately, this does not universally work on all databases,
since on databases which natively use the backslash as a delimiter, the
backslash itself needs to be delimited, but on other databases that have no
delimiter, backslashing the backslash causes an error.
So the only solution that I can come up with is to create an option in res_odbc
that explicitly specifies whether or not backslash is a native delimiter. If
it is, we use it natively; if not, we use the ESCAPE clause to make it one.
Reported by: elguero
Patch by: tilghman
(Closes issue #11364)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@89559 65c4cc65-6c06-0410-ace0-fbb531ad65f3
It is documented behavior that if a parking extension already exists while using PARKINGEXTEN,
dialplan execution will continue. If blind transferring to a Park with PARKINGEXTEN, you
must keep this in mind, and handle the failure yourself.
Issue 11237, reported by jon.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@89248 65c4cc65-6c06-0410-ace0-fbb531ad65f3
issue a reload, further use of that class could result in a crash due to
dividing by zero. This set of changes fixes up some places to prevent this
from happening.
(closes issue #10948)
Reported by: jcomellas
Patches:
res_musiconhold_division_by_zero.patch uploaded by jcomellas (license 282)
Additional changes added by me.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@89037 65c4cc65-6c06-0410-ace0-fbb531ad65f3
valid, therefore, those clients must be considered as buddies. The resource
string helps us make the distinction between clients.
Closes issue #10707, reported by yusufmotiwala.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@84902 65c4cc65-6c06-0410-ace0-fbb531ad65f3
without resource from a buddy that is known to have a resource list.
Revert a change I previously made, where Asterisk could point to a
freed memory location.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@84890 65c4cc65-6c06-0410-ace0-fbb531ad65f3
EAGAIN unless we didn't read an entire line. If there is a newline at the
end if the read buffer, break, because we got the whole thing.
(reported and patched by bmd)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@84236 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This version of the patch maintains the original behavior of the code when
not using FastAGI.
(closes issue #10553)
Reported by: juggie
Patches:
res_agi_fgets-4.patch uploaded by juggie (license 24)
res_agi_fgets_1.4svn.patch uploaded by juggie (license 24)
Slight mods by me
Tested by: juggie, festr
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@82929 65c4cc65-6c06-0410-ace0-fbb531ad65f3
mapping, but won't always match the activated on/by access controls. In that
case, the code needs to keep trying features for a match.
(reported by Atis on the asterisk-dev list, patched by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@82594 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: juggie
Patches:
res_agi_fgets-2.patch uploaded by juggie (license 24)
Tested by: juggie
When using fastagi, fgets() can return before a full line is read. Add explicit
handling for the case where it gets interrupted.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@82245 65c4cc65-6c06-0410-ace0-fbb531ad65f3
you complete the transfer before the announcement of the parking spot finishes,
then the channel being parked will hear the remainder of the announcement.
These changes make it so that will not happen anymore.
Basically, res_features sets a flag on the channel is playing the announcement
to so that the file streaming core knows that it needs to watch out for a
channel masquerade, and if it occurs, to abort the announcement.
(closes BE-182)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@81599 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: dimas
Don't output a bridge failed warning message if it failed because one of the channels was part of the masquerade process. That is perfectly normal.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@81401 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: mustardman
Patches:
asterisk-mohposition.diff.txt uploaded by jamesgolovich (license 176)
This patch fixes a few problems with music on hold.
* Fix issues with starting at the beginning of a file when it shouldn't.
* Fix the inuse counter to be decremented even if the class had not been
set to be deleted when not in use anymore
* Don't arbitrarily limit the number of MOH files to 255
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@81042 65c4cc65-6c06-0410-ace0-fbb531ad65f3
after we already looked it up by name. This causes broken behavior if there is
more than one feature defined with the same digit pattern.
(closes issue #10539, reported by bungalow, patch by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@80573 65c4cc65-6c06-0410-ace0-fbb531ad65f3
without reading the whole line when using fastagi. When this happens,
errno was set to EINTR or EAGAIN. This patch accounts for the possibility
and lets fgets continue in that case.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@80360 65c4cc65-6c06-0410-ace0-fbb531ad65f3
delete classes from memory that were no longer in the config. This patch fixes
that problem as well as another one. Previously, if you reloaded MOH using the
"moh reload" CLI command, which behaved differently than "module reload ...",
MOH had to be stopped on every channel and started again immediately. However,
there was no way to tell what class was being used, so they would all fall back
to the default class.
(closes issue #10139)
Reported by: blitzrage
Patches:
asterisk-10139-advanced.diff.txt uploaded by jamesgolovich (license 176)
Tested by: jamesgolovich
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@79778 65c4cc65-6c06-0410-ace0-fbb531ad65f3
McKeehan in issue #10184.
Upon priority change, the resource list is not NULL terminated when
moving an item to the end of the list. This makes Asterisk endlessy
loop whenever it needs to read the list. Jids with different resource and
priority values, like in Gmail's and GoogleTalk's jabber clients put
that problem in evidence.
Upon reception of a 'from' attribute with an empty resource string,
Asterisk crashes when trying to access the found->cap pointer if the
resource list for the given buddy is not empty. This situation is
perfectly valid and must be handled. The Gizmoproject's jabber client
put that problem in evidence.
Also added a few comments in the code as well as a handle for the
capabilities from Gmail's jabber client, which are stored in a caps:c tag
rather than the usual c tag.
Closes issue #10184.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@79665 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: 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: fkasumovic
Patches:
res_conver.patch uploaded by fkasumovic (license #101)
Use the last occurance of . to find the extension, not the first occurance.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@76067 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: juggie
Patches:
10210-1.4-grr.patch uploaded by juggie (license #24)
Tested by: juggie, blitzrage
Log a warning if someone uses DeadAGI on a live channel.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@75437 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r75059 | russell | 2007-07-13 15:07:21 -0500 (Fri, 13 Jul 2007) | 6 lines
Ensure that adding a user to the list of users of a specific music on hold
class is not done at the same time as any of the other operations on this list
to prevent list corruption. Using the global moh_data lock for this is not
ideal, but it is what is used to protect these lists everywhere else in the
module, and I am only changing what is necessary to fix the bug.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@75067 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: blitzrage
Patches submitted by: juggie, qwell, me
Tested by: blitzrage
When trying to find a music on hold class to use, try all of the options,
instead of only the first one that is set. Also, change the MusicOnHold
applications to not hang up on the channel when a class can not be found.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@74162 65c4cc65-6c06-0410-ace0-fbb531ad65f3
native bridge function. This fixes a problem where when two zap channels are
natively bridged and one does a flash hook, the other channel did not receive
music on hold. (Reported to me directly by Doug Bailey at Digium)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@73512 65c4cc65-6c06-0410-ace0-fbb531ad65f3
still can't build *_odbc.so!", check for ltdl directly, instead of just listing
it as another library to include in the unixodbc check in the configure script.
This also makes ltdl show up as a dependency in menuselect so people know what
to go install. (related to issue #9989, patch by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@69702 65c4cc65-6c06-0410-ace0-fbb531ad65f3
blitzrage's test machines. It was one of the situations where he was seeing
hung channels, and may be the cause of some of the reports from other people.
(related to issue #9235)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@69579 65c4cc65-6c06-0410-ace0-fbb531ad65f3
crashes while we are trying to find a workaround.
Iksemel development seems to have stalled and we might have to stop using the
TCP/TLS connections in that library and use our own, which would scale better
from a poll/select perspective I guess. It would also make it easier to migrate
to OpenSSL and stop Asterisk from depending on both OpenSSL and GnuTLS.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@68027 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Due to a bug in the iksemel library, this will not work if you are using GTLS
in the connection. That's being investigated. If you figure out a way to handle
that without us having to patch iksemel, let us know in the bug report. Thanks.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@67993 65c4cc65-6c06-0410-ace0-fbb531ad65f3
snmp library more than once without completely unloading the module and loading
it again.
(issue #9571, reported by hristo, additional helpful debug information from festr,
patch from me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@67872 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r62796 | kpfleming | 2007-05-02 19:53:46 -0400 (Wed, 02 May 2007) | 7 lines
increase reliability and efficiency of static Realtime config loading via ODBC:
don't request fields we aren't going to use
don't request sorting on fields that are pointless to sort on
explicitly request the fields we want, because we can't expect the database to always return them in the order they were created
(reported by blitzrage in person (!), patch by me)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@62807 65c4cc65-6c06-0410-ace0-fbb531ad65f3
don't request sorting on fields that are pointless to sort on
use ast_build_string() instead of snprintf()
don't request the list of fieldnames that resulted from the query when we both knew what they were before we ran the query _AND_ we aren't going to do anything with them anyway
(patch by me, inspired by blitzrage's bug report about res_config_odbc)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@62797 65c4cc65-6c06-0410-ace0-fbb531ad65f3