in the name. Could probably do with a better fix in trunk, but this bug has
been open way too long without a better solution.
Reported by: stevedavies
Patch by: tilghman
(Closes issue #9668)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@96575 65c4cc65-6c06-0410-ace0-fbb531ad65f3
calls ast_hint_extension, which attempts to readlock the same lock. Recursion with read-write locks is
dangerous, so the inner lock needs to be removed. I did this by copying the "guts" of ast_hint_extension
into ast_merge_contexts_and_delete (sans the extra lock).
(this change is inspired by the locking problems seen in issue #11080, but I have no idea if this is the
problematic area experienced by the reporters of that issue)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@95577 65c4cc65-6c06-0410-ace0-fbb531ad65f3
in ast_hint_state_changed(). This makes it get locked recursively which now
causes a deadlock.
(closes issue #11080, thanks to callguy for the access to a deadlocked machine)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@94831 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fixes a problem where Asterisk claims that a translation path can not be
found for channels involving video.
(closes issue #11638)
Reported by: cwhuang
Tested by: cwhuang
Patch suggested by cwhuang, with some additional changes by me.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@94828 65c4cc65-6c06-0410-ace0-fbb531ad65f3
autoservice, remember it and ensure that the channel has the same setting when
autoservice gets stopped. (pointed out by d1mas, patched up by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@94801 65c4cc65-6c06-0410-ace0-fbb531ad65f3
we only care about the END of a digit. That way, no magic digit emulation stuff
will happen when all we're doing is queueing up END frames.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@94797 65c4cc65-6c06-0410-ace0-fbb531ad65f3
inserted into the channel list. The reason is because some manager users
immediately queue requests from the channel when they see that event and are
confused when Asterisk reports no such channel. (Closes issue #11632)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@94767 65c4cc65-6c06-0410-ace0-fbb531ad65f3
make the transition to treating this as an error a bit less painless, just issue
a huge error message for now. Then, later, we can reinstate the code that treats
it as a failure.
(Thanks to philippel for the feedback)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@93000 65c4cc65-6c06-0410-ace0-fbb531ad65f3
We do not want to do this (see bug below for details).
This makes it so that if a [ is found without a ], the entire config will fail, and nothing in it will be loaded.
Isue #10690.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@92696 65c4cc65-6c06-0410-ace0-fbb531ad65f3
queued up if autoservice gets a NULL return from ast_read().
* Make the process of queueing the hangup frame more efficient by putting the
frame where it is going to end up and avoiding some locking and extra memory
allocations and freeing.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@91777 65c4cc65-6c06-0410-ace0-fbb531ad65f3
because a hangup actually causes a NULL frame to be received, not a hangup frame.
Queueing a hangup if we receive a NULL frame during autoservice corrects this problem
(closes issue #11467, reported by jmls, patched by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@91737 65c4cc65-6c06-0410-ace0-fbb531ad65f3
against older Asterisk 1.4 headers will now load properly with just a warning
indicating that they are old and may cause problems.
(patch by paravoid)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@91501 65c4cc65-6c06-0410-ace0-fbb531ad65f3
a lock that we are waiting on for a mutex, not rwlocks. This should fix the
problem where people have reported "core show locks" crashing sometimes.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@91074 65c4cc65-6c06-0410-ace0-fbb531ad65f3
when looking up extensions. This code was added to handle the case where a
dialplan switch was in use that could block for a long time. However, the way
that I added it, it did this for all extension lookups. However, lookups in the
in-memory tree of extensions should _not_ take long enough to matter. So, move
the autoservice stuff to be only around executing a switch.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@90967 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is the merge of the forward-loop branch. The main change here is that call-forwards can no longer loop.
This is accomplished by creating a datastore on the calling channel which has a linked list of all devices
dialed. If a forward happens, then the local channel which is created inherits the datastore. If, through this
progression of forwards and datastore inheritance, a device is attempted to be dialed a second time, it will simply
be skipped and a warning message will be printed to the CLI. After the dialing has been completed, the datastore
is detached from the channel and destroyed.
This change also introduces some side effects to the code which I shall enumerate here:
1. Datastore inheritance has been backported from trunk into 1.4
2. A large chunk of code has been removed from app_dial. This chunk is the section of code
which handles the call forward case after the channel has been requested but before it has
been called. This was removed because call-forwarding still works fine without it, it makes the
code less error-prone should it need changing, and it made this set of changes much less painful
to just have the forwarding handled in one place in each module.
3. Two new files, global_datastores.h and .c have been added. These are necessary since the datastore
which is attached to the channel may be created and attached in either app_dial or app_queue, so they
need a common place to find the datastore info. This approach was taken in case similar datastores are
needed in the future, there will be a common place to add them.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@90735 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Now, it automatically increases the reference count to reflect the reference
that is now held by the container.
This was done to be more consistent with ao2_unlink(), which automatically
releases the reference held by the container. It also makes it so it is
no longer possible for a pointer to be invalid after ao2_link() returns.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@90348 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
executed in the dialplan if you have debug set to anything non-zero. This seems pointless
due to the fact that these channel variables are not referenced anywhere else in the code and
their names are esoteric enough that they would not be practical to reference in the dialplan. Plus
the fact that this behavior isn't documented anywhere means that the change is not likely to cause
any disruption. If anything, this may actually cause a slight performance increase if running with
debug on.
The motivating influence for this code change is the eventwhencalled option for queues. If set to
vars, all channel variables will be output to the manager. These unnecessary channel variables make
the output a lot more difficult to deal with.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@90059 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
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
ways that channel variables are handled. In general, they were not handled in
a thread-safe way. The channel _must_ be locked when reading or writing from/to
the channel variable list.
What I have done to improve this situation is to make pbx_builtin_setvar_helper()
and friends lock the channel when doing their thing. Asterisk API calls almost
all lock the channel for you as necessary, but this family of functions did not.
(closes issue #10923, reported by atis)
(closes issue #11159, reported by 850t)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@88805 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Previously, the SRV record support in Asterisk was broken. There was no
guarantee on what record Asterisk would choose to actually use. This set of
changes improves the situation by ensuring that Asterisk will choose the
highest priority record.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@88719 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The issue here is that the channel frame readq handling got broken when the
code was converted to use the linked list macros. It caused corruption of the
list head and tail pointers. So, I fixed up the usage of the linked list
macros and in passing, simplified the code. I also documented what the code
is doing, as it was a bit difficult to figure out at first.
This bug showed itself with crashes showing messed up head/tail pointers for
the readq. However, there are a couple of crashes that aren't quite as obvious,
but I think may be related. So, if your bug gets closed by this commit, but
you still have a problem, please reopen or create a new bug report.
(closes issue #10936)
(closes issue #10595)
(closes issue #10368)
(closes issue #11084)
(closes issue #10040)
(closes issue #10840)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@88709 65c4cc65-6c06-0410-ace0-fbb531ad65f3
any channel datastores from the old channel to the new one. However, it did
not use the linked list macros properly to accomplish the task. The existing
code would only work if there was only a single datastore on the old channel.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@88624 65c4cc65-6c06-0410-ace0-fbb531ad65f3
and ast_string_field_free_all to ast_string_field_reset_all
to avoid misuse (due to too similar names and an error in
documentation). Fix two related memory leaks in app_meetme.
No need to merge to trunk, different fix already applied there.
Not applicable to 1.2
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@88471 65c4cc65-6c06-0410-ace0-fbb531ad65f3
when traversing the list of allocated chunks so that they can be printed out
to the CLI.
(Thanks to eliel on #asterisk-dev for pointing this out!)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@87373 65c4cc65-6c06-0410-ace0-fbb531ad65f3
the BEGIN is less than that of the defined minimum DTMF duration.
(closes issue #11051)
Reported by: casper
Patches:
channel.c.86664.diff uploaded by casper (license 55)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@86750 65c4cc65-6c06-0410-ace0-fbb531ad65f3
and modify channel data that may change elsewhere. I went through every timer
callback in the source tree to make sure that none of them did any additional
locking that could introduce deadlocks, and all is well.
(closes issue #10765)
Reported by: Ivan
Patches:
ast_1_4_11_svn_patch_channel_rc.diff uploaded by Ivan (license 229)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@86330 65c4cc65-6c06-0410-ace0-fbb531ad65f3
me in issue #11018, doesn't really make sense. There is no reason to have
the base64 decode function force a '\0' terminated buffer, when the result is
almost always binary, anyway. In fact, this caused some breakage, as some code
in res_crypto passed in a buffer exactly the right size to get its binary
result, which got stomped on by this patch.
(closes issue #11018, reported by dimas)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@86237 65c4cc65-6c06-0410-ace0-fbb531ad65f3
some amount of time. Be a little bit more careful and prepare all of the
output in an intermediary buffer while holding a global resource. Then, after
releasing it, send the output to ast_cli().
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@85647 65c4cc65-6c06-0410-ace0-fbb531ad65f3
and retrieve its output. The issue was that there was no way for the main Asterisk
process to know that the remote console was connecting in the -rx mode. The way that
James has fixed this is to have all remote consoles muted by default. Then, regular
remote consoles automatically execute a CLI command to unmute themselves when they
first start up.
(closes issue #10847)
Reported by: atis
Patches:
asterisk-consolemute.diff.txt uploaded by jamesgolovich (license 176)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@85533 65c4cc65-6c06-0410-ace0-fbb531ad65f3
CLI command at once for a remote console.
(closes issue #10888)
Reported by: jamesgolovich
Patches:
asterisk-climultiple.diff.txt uploaded by jamesgolovich (license 176)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@85532 65c4cc65-6c06-0410-ace0-fbb531ad65f3
that when events are appended to the master event queue, they use the number
of active sessions as a use count so it will know when all active sessions
at the time the event happened have consumed it. However, the handling of
the number of sessions was not properly synchronized, so the use count was
not always correct, causing an event to disappear early, or get stuck in
the event queue for forever.
(closes issue #9238, reported by bweschke, patch from Ivan, modified by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@82867 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: john
Patches:
dns.c.patch uploaded by john (license 218)
Tested by: mvanbaak
Don't return a match if no SRV record actually exists.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@81435 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: jmls
Patches:
pbx.diff uploaded by jmls (license 141)
Backport changes from 81372. Add REASON dialplan variable for when an originated call fails and the failed extension is executed.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@81375 65c4cc65-6c06-0410-ace0-fbb531ad65f3
issues. Previously, this code used a shift register of hits and non-hits.
However, if the start of the digit isn't clean, it is possible for the
leading edge detector to miss the digit. These changes replace the flawed
shift register logic and also does the debouncing on the trailing edge as well.
(closes issue #10535, many thanks to softins for the patch)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@80820 65c4cc65-6c06-0410-ace0-fbb531ad65f3
the peers and users are being stored in a linked list, that they go in the
list in the same order that the older code used. This is necessary to maintain
the behavior of which peers and users get matched when traversing the container.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@80497 65c4cc65-6c06-0410-ace0-fbb531ad65f3
added to the head of a bucket instead of the tail. However, while looking over
code with mmichelson, we noticed that the algorithm used in ao2_iterator_next
requires that items are added to the tail. This wouldn't have caused any huge
problem, but it wasn't correct. It meant that if an object was added to a
container while you were iterating it, and it was added to the same bucket that
the current element is in, then the new object would be returned by
ao2_iterator_next, and any other objects in the bucket would be bypassed in
the traversal.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@80424 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This set of changes fixes problems with the handling of iax2_user and iax2_peer
objects. It was very possible for a thread to still hold a reference to one of
these objects while a reload operation tries to delete them. The fix here is to
ensure that all references to these objects are tracked so that they can't go away
while still in use.
To accomplish this, I used the astobj2 reference counted object model. This
code has been in one of Luigi Rizzo's branches for a long time and was primarily
developed by one of his students, Marta Carbone. I wanted to go ahead and bring
this in to 1.4 because there are other problems similar to the ones fixed by these
changes, so we might as well go ahead and use the new astobj if we're going to go
through all of the work necessary to fix the problems.
As a nice side benefit of these changes, peer and user handling got more efficient.
Using astobj2 lets us not hold the container lock for peers or users nearly as long
while iterating. Also, by changing a define at the top of chan_iax2.c, the objects
will be distributed in a hash table, drastically increasing lookup speed in these
containers, which will have a very big impact on systems that have a large number of
users or peers.
The use of the hash table will be made the default in trunk. It is not the default
in 1.4 because it changes the behavior slightly. Previously, since peers and users
were stored in memory in the same order they were specified in the configuration file,
you could influence peer and user matching order based on the order they are specified
in the configuration. The hash table does not guarantee any order in the container,
so this behavior will be going away. It just means that you have to be a little
more careful ensuring that peers and users are matched explicitly and not forcing
chan_iax2 to have to guess which user is the right one based on secret, host, and
access list settings, instead of simply using the username.
If you have any questions, feel free to ask on the asterisk-dev list.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@80362 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Caused by fix for issue 9938.
I basically took the code that existed before 9938 was fixed, and
copied it into a new function - ast_unescape_semicolon
There should be very few places this will be needed (pbx_config
does NOT need this (see issue 9938 for details))
Issue 10430, patch by me, with help/ideas from murf (thanks murf).
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@79904 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: wdecarne
Now that we pass through RTP timestamp information we need to make the allowed timestamp skew considerably less. There are situations where a source may change and due to the timestamp difference the receiver will experience an audio gap since we did not indicate by setting the marker bit that the source changed.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@78172 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Now matches are made on both the IP address and port number, or if the insecure setting is set to "port" then just match on the
IP address.
In order to accomplish this, I also added a new API call, ast_category_root, which returns the first variable of an ast_category struct
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@78103 65c4cc65-6c06-0410-ace0-fbb531ad65f3
with DEBUG_THREADS enabled and provide the following:
* This will keep track of which locks are held by which thread as well as
which lock a thread is waiting for in a thread-local data structure. A
reference to this structure is available on the stack in the dummy_start()
function, which is the common entry point for all threads. This information
can be easily retrieved using gdb if you switch to the dummy_start() stack
frame of any thread and print the contents of the lock_info variable.
* All of the thread-local structures for keeping track of this lock information
are also stored in a list so that the information can be dumped to the CLI
using the "core show locks" CLI command. This introduces a little bit of a
performance hit as it requires additional underlying locking operations
inside of every lock/unlock on an ast_mutex. However, the benefits of
having this information available at the CLI is huge, especially considering
this is only done in DEBUG_THREADS mode. It means that in most cases where
we debug deadlocks, we no longer have to request access to the machine to
analyze the contents of ast_mutex_t structures. We can now just ask them
to get the output of "core show locks", which gives us all of the information
we needed in most cases.
I also had to make some additional changes to astmm.c to make this work when
both MALLOC_DEBUG and DEBUG_THREADS are enabled. I disabled tracking of one
of the locks in astmm.c because it gets used inside the replacement memory
allocation routines, and the lock tracking code allocates memory. This caused
infinite recursion.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@78095 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r77942 | murf | 2007-08-02 11:56:37 -0600 (Thu, 02 Aug 2007) | 1 line
This patch hopefully solves 10141; The user is running with it, and it doesn't appear to harm asterisk's operation, and may prevent a crash. I'll store it in 1.2, as we have shut down support on 1.2, but since I developed the patch before support finished, and it might affect 1.4 and trunk, I'm going ahead with it.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77945 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
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: 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: 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
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
DTMF digit in the ast_senddigit() function. The define is set to 100ms by
default, which is the same thing that this function was using. But, using
the define lets changes take effect in this case, as well as the others where
it was already used.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@76132 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Tilghman Lesher
Russell Bryant
Mark Michelson
Kevin P. Fleming
Jason Parker
Joshua Colp
Olle Johansson
Steve Murphy
Luigi Rizzo
Dwayne M. Hubbard
Doug Bailey
Jim Dixon