1) Due to some signed vs. unsigned silliness, setting 'eventwhencalled' to
'vars' or 'yes' did exactly the same thing. Thus the sign change of the
ast_true call.
2) The vars2manager function overwrote a \n for every channel variable it parsed, resulting
in bizarre output for the channel variables. This patch remedies this.
(related to issue #11385, however I'm not sure if this will actually be enough to close it)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@89837 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This set of changes fixes an issue that was reported to me on IRC yesterday.
The user, d1mas, was using chan_zap for incoming calls and was having DTMF
recognition issues in some situations. Specifically, he noticed that the
problem occurred when using DISA or WaitExten. He also noticed that when
using Read, the problem did not occur. His system also used DUNDi for
dialplan lookups.
So, he theorized that if the DUNDi lookups blocked for some period of time,
that audio from the zap channel could get lost. If the audio got lost, then
it wouldn't be run through the DTMF detector, and digits could get lost.
He was correct, and the following set of changes fixes the problem. However,
the changes go a little bit further than what was necessary to fix this exact
problem.
1) I updated pbx_extension_helper() to autoservice the associated channel to
handle cases where extension lookups may take a long time. This would
normally be a dialplan switch that does some lookup over the network, such
as the DUNDi or IAX2 switches.
This ensures that even while a DUNDi lookup is blocking, the channel will be
continuously serviced.
2) I made a change to the autoservice code. This is actually something that
has bothered me for a long time. When a channel is in autoservice, _all_
frames get thrown away. However, some frames really shouldn't be thrown
away. The most notable examples are signalling (CONTROL) frames, and DTMF.
So, this patch queues up important frames while a channel is in autoservice.
When autoservice is stopped on the channel, the queued up frames get stuck
back on the channel so that they can get processed instead of thrown away.
3) I made another change to the autoservice code to handle the case where
autoservice is started on channels recursively.
Previously, you could call ast_autoservice_start() multiple times on a
channel, and it would stop the first time ast_autoservice_stop() gets
called. Now, it will ensure that autoservice doesn't actually stop until
the final call to ast_autoservice_stop().
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@89790 65c4cc65-6c06-0410-ace0-fbb531ad65f3
codec that we don't know, Asterisk did not remove that codec from the list.
With this patch, we remove the codec from audio and video rtp objects and
deny it ever existed. Thanks to lasse for testing.
(closes issue #11376)
Reported by: lasse
Patches:
bug11376.txt uploaded by oej (license 306)
Tested by: lasse
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@89630 65c4cc65-6c06-0410-ace0-fbb531ad65f3
app_playback will continue to try to play the remaining files. With this change, no more files will
be played back upon hangup.
(closes issue #11345, reported and patched by IgorG)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@89618 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
This change fixes the problem, with a multi-faceted approach. First, we
do our best to avoid these messages from being created in the first place,
and second, if that fails, we detect when the voicemail message is
zero-length and avoid exiting at that point.
Reported by: dtyoo
Patch by: gkloepfer,tilghman
(Closes issue #11083)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@89540 65c4cc65-6c06-0410-ace0-fbb531ad65f3
invalid, due to the repetition of certain parameters in a single event.
This caused various issues for XML parsers, some of which refused to parse
at all, given the invalidity of the rendered XML. So this commit fixes
the XML output, ensuring that each entity parameter has a unique name, thus
ensuring valid XML.
Reported by: msetim
Patch by: tilghman
(Closes issue #10220)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@89536 65c4cc65-6c06-0410-ace0-fbb531ad65f3
the conlock as well as the hints lock, it must be locked in that respective order.
In order to prevent a potential deadlock, we need to lock the conlock prior to
locking the hints lock in ast_hint_state_changed (see the call stack example on
issue #11323 for how this can happen).
(closes issue #11323, reported by eelcob, suggestion for patch by eelcob, patch by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@89457 65c4cc65-6c06-0410-ace0-fbb531ad65f3
what build options were used. We agreed that we should remove this before
making a 1.4 release, and then we can put it back in. Then, we can take a
month or so to play around with it to get it how we want it.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@89339 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If you upgrade to this version of Asterisk, you must rebuild *all* of your modules that came from other sources before trying to run this version. If you are using Digium's G.729 binary codec module, you will need v33 or newer.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@89325 65c4cc65-6c06-0410-ace0-fbb531ad65f3
has a call out to the station, but the user has pressed a line button to answer
the call instead of picking up the handset. If they do, the phone sends out a
new INVITE. So, the SLAStation app must check to see if it is picking up a
ringing trunk, and ensure that the other stations stop ringing.
(reported internally, patched by me, tested by mogorman)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@89296 65c4cc65-6c06-0410-ace0-fbb531ad65f3
