https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r189277 | mmichelson | 2009-04-20 09:04:41 -0500 (Mon, 20 Apr 2009) | 12 lines
Move the check for chan->fdno == -1 to after the zombie/hangup check.
Many users were finding that their hung up channels were staying up and
causing 100% CPU usage.
(issue #14723)
Reported by: seadweller
Patches:
14723_1-4-tip.patch uploaded by mmichelson (license 60)
Tested by: falves11, bamby
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@189278 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This was accomplished using a set of options and the setoption channel callback.
The core calls into the channel driver using these options and the channel driver
either returns success or failure.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@187360 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The biggest change done here was elimination of the backup_config for use with
features. Previously, the bridging code upon detecting a feature would set the
start time of the bridge to the start time of the feature. Then after the
feature had either expired or timed out the start time would be reset to the
true bridge start time from the backup_config. Now, the time differences are
calculated with respect to the newly added feature_start_time timeval instead.
There should be no behavior changes from the previous functionality aside from
the bridge timing being unaffected by either valid or partial feature matches.
Previously the timing would be increased by the length of time configured for
featuredigittimeout, which was probably never noticed.
(closes issue #14503)
Reported by: KNK
Tested by: jpeeler
Review: http://reviewboard.digium.com/r/179/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@187211 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r186984 | mmichelson | 2009-04-08 10:26:46 -0500 (Wed, 08 Apr 2009) | 24 lines
Make a couple of changes with regards to a new message printed in ast_read().
"ast_read() called with no recorded file descriptor" is a new message added
after a bug was discovered. Unfortunately, it seems there are a bunch of places
that potentially make such calls to ast_read() and trigger this error message
to be displayed. This commit does two things to help to make this message appear
less.
First, the message has been downgraded to a debug level message if dev mode is
not enabled. The message means a lot more to developers than it does to end users,
and so developers should take an effort to be sure to call ast_read only when
a channel is ready to be read from. However, since this doesn't actually cause an
error in operation and is not something a user can easily fix, we should not spam
their console with these messages.
Second, the message has been moved to after the check for any pending masquerades.
ast_read() being called with no recorded file descriptor should not interfere with
a masquerade taking place.
This could be seen as a simple way of resolving issue #14723. However, I still want
to try to clear out the existing ways of triggering this message, since I feel that
would be a better resolution for the issue.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@186985 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r186832 | mmichelson | 2009-04-07 18:49:49 -0500 (Tue, 07 Apr 2009) | 8 lines
Set the AST_FEATURE_WARNING_ACTIVE flag when a p2p bridge returns AST_BRIDGE_RETRY.
Without this flag set, warning sounds will not be properly played to either party
of the bridge.
(closes issue #14845)
Reported by: adomjan
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@186833 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The channel drivers which have been most heavily tested with these enhancements are
chan_sip and chan_misdn. Further work is being done to add Q.SIG support and will be
introduced in a later commit. chan_skinny has code added to it here, but according
to user pj, the support on chan_skinny is not working as of now. This will be fixed in
a later commit.
A special thanks goes out to bugtracker user gareth for getting the ball rolling and
providing the initial support for this work. Without his initial work on this, this would
not have been nearly as painless as it was.
This functionality has been tested by Digium's product quality department, as well as a
customer site running thousands of calls every day. In addition, many many many many bugtracker
users have tested this, too.
(closes issue #8824)
Reported by: gareth
Review: http://reviewboard.digium.com/r/201
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@186525 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This API call now waits for a special frame from the underlying channel driver to
indicate success or failure. This allows the return value to truly convey whether
the transfer worked or not. In the case of the Transfer() dialplan application this
means the value of the TRANSFERSTATUS dialplan variable is actually true.
(closes issue #12713)
Reported by: davidw
Tested by: file
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@186382 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r185771 | russell | 2009-04-01 08:47:30 -0500 (Wed, 01 Apr 2009) | 6 lines
Fix a case where DTMF could bypass audiohooks.
This change fixes a situation where an audiohook that wants DTMF would not
actually get it. This is in the code path where we end DTMF digit length
emulation while handling a NULL frame.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@185772 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The ability to load/unload timing interfaces is nice, but it means that when a timer is allocated, it may come from provider A, but later provider B becomes the 'preferred' provider. If this happens, all timer API calls on the timer that was provided by provider A will actually be handed to provider B, which will say WTF and return an error.
This patch changes the timer API to include a pointer to the provider of the timer handle so that future operations on the timer will be forwarded to the proper provider.
(closes issue #14697)
Reported by: moy
Review: http://reviewboard.digium.com/r/211/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@184762 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If two channels were bridged together using a generic bridge the T38
control frame would get passed up instead of being indicated on the
other channel.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@183057 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r182810 | russell | 2009-03-17 21:09:13 -0500 (Tue, 17 Mar 2009) | 44 lines
Fix cases where the internal poll() was not being used when it needed to be.
We have seen a number of problems caused by poll() not working properly on
Mac OSX. If you search around, you'll find a number of references to using
select() instead of poll() to work around these issues. In Asterisk, we've
had poll.c which implements poll() using select() internally. However, we
were still getting reports of problems.
vadim investigated a bit and realized that at least on his system, even
though we were compiling in poll.o, the system poll() was still being used.
So, the primary purpose of this patch is to ensure that we're using the
internal poll() when we want it to be used.
The changes are:
1) Remove logic for when internal poll should be used from the Makefile.
Instead, put it in the configure script. The logic in the configure
script is the same as it was in the Makefile. Ideally, we would have
a functionality test for the problem, but that's not actually possible,
since we would have to be able to run an application on the _target_
system to test poll() behavior.
2) Always include poll.o in the build, but it will be empty if AST_POLL_COMPAT
is not defined.
3) Change uses of poll() throughout the source tree to ast_poll(). I feel
that it is good practice to give the API call a new name when we are
changing its behavior and not using the system version directly in all cases.
So, normally, ast_poll() is just redefined to poll(). On systems where
AST_POLL_COMPAT is defined, ast_poll() is redefined to ast_internal_poll().
4) Change poll() in main/poll.c to be ast_internal_poll().
It's worth noting that any code that still uses poll() directly will work fine
(if they worked fine before). So, for example, out of tree modules that are
using poll() will not stop working or anything. However, for modules to work
properly on Mac OSX, ast_poll() needs to be used.
(closes issue #13404)
Reported by: agalbraith
Tested by: russell, vadim
http://reviewboard.digium.com/r/198/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@182847 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This does not change any behavior, but moves the frames from the local frame
list back to the channel read queue using an O(n) algorithm instead of O(n^2).
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@182553 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ast_answer(), when supplied a delay before returning to the caller, use ast_safe_sleep() to implement the delay. Unfortunately during this time any incoming frames are discarded, which is problematic for T.38 re-INVITES and other sorts of channel operations.
When a delay is not passed to ast_answer(), it still delays for up to 500 milliseconds, waiting for media to arrive. Again, though, it discards any control frames, or non-voice media frames.
This patch rectifies this situation, by storing all incoming frames during the delay period on a list, and then requeuing them onto the channel before returning to the caller.
http://reviewboard.digium.com/r/196/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@182525 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For a channel that is not yet answered this API call will wait
until a voice frame is received on the channel before returning.
It does this by waiting for frames on the channel and reading them
in. The frames read in were not freed when they should have been.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@182171 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r181423 | russell | 2009-03-11 16:42:58 -0500 (Wed, 11 Mar 2009) | 9 lines
Make code that updates BRIDGEPEER variable thread-safe.
It is not safe to read the name field of an ast_channel without the channel
locked. This patch fixes some places in channel.c where this was being done,
and lead to crashes related to masquerades.
(closes issue #14623)
Reported by: guillecabeza
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@181424 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In app.c, ast_app_getdata is called to stream the prompts and receive DTMF input. If ast_app_getdata() receives an empty string caused by the user inputing the end of string character, in this case '#', it should break from the prompt loop and return to app_read, but instead it cycles through all the prompts. I've added a return value for this special case in ast_readstring() which uses an enum I've delcared in apps.h. This enum is now used as a return value for ast_app_getdata().
(closes issue #14279)
Reported by: Marquis
Patches:
fix_app_read.patch uploaded by Marquis (license 32)
read-ampersanmd.patch2 uploaded by dvossel (license 671)
Tested by: Marquis, dvossel
Review: http://reviewboard.digium.com/r/177/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@180032 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r179741 | russell | 2009-03-03 10:45:46 -0600 (Tue, 03 Mar 2009) | 6 lines
Ensure chan->fdno always gets reset to -1 after handling a channel fd event.
Since setting fdno to -1 had to be moved, a couple of other code paths that
do process an fd event return early and do not pass through the code path
where it was moved to. So, set it to -1 in a few other places, too.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@179742 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r179671 | file | 2009-03-03 10:38:09 -0400 (Tue, 03 Mar 2009) | 3 lines
Move where fdno is set to the default value to *after* the read callback of the channel driver is called.
We have to do this as the underlying channel driver may need the fdno value to determine what to read.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@179672 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r179608 | russell | 2009-03-03 07:53:52 -0600 (Tue, 03 Mar 2009) | 9 lines
Make it easier to detect an improper call to ast_read().
When you call ast_waitfor() on a channel, the index into the channel fds array
that holds the file descriptor that poll() determines has input available is
stored in fdno. This patch clears out this value after a call to ast_read()
and also reports errors if ast_read() is called without an fdno set.
From a discussion on the asterisk-dev list.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@179609 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r179536 | jpeeler | 2009-03-02 17:54:39 -0600 (Mon, 02 Mar 2009) | 15 lines
Fix bridging regression from commit 176701
This fixes a bad regression where the bridge would exit after an attended
transfer was made. The problem was due to nexteventts getting set after the
masquerade which caused the bridge to return AST_BRIDGE_COMPLETE.
(closes issue #14315)
Reported by: tim_ringenbach
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@179537 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r179461 | russell | 2009-03-02 16:58:18 -0600 (Mon, 02 Mar 2009) | 8 lines
Ensure that only one thread is calling ast_settimeout() on a channel at a time.
For example, with an IAX2 channel, you can have both the channel thread and the
chan_iax2 processing threads calling this function, and doing so twice at the
same time is a bad thing.
(Found in a debugging session with dvossel and mmichelson)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@179462 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r176701 | jpeeler | 2009-02-17 15:54:34 -0600 (Tue, 17 Feb 2009) | 17 lines
Modify bridging to properly evaluate DTMF after first warning is played
The main problem is currently if the Dial flag L is used with a warning sound,
DTMF is not evaluated after the first warning sound. To fix this, a flag has
been added in ast_generic_bridge for playing the warning which ensures that if
a scheduled warning is missed, multiple warrnings are not played back (due to a
feature evaluation or waiting for digits). ast_channel_bridge was modified to
store the nexteventts in the ast_bridge_config structure as that information
was lost every time ast_channel_bridge was reentered, causing a hangup due to
incorrect time calculations.
(closes issue #14315)
Reported by: tim_ringenbach
Reviewed on reviewboard:
http://reviewboard.digium.com/r/163/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@176708 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1) Add module use count handling so that timing modules can be unloaded.
2) Implement unload_module() functions for the timing interface modules.
3) Allow multiple timing modules to be loaded, and use the one with the
highest priority value.
4) Report which timing module is being use in the "timing test" CLI command.
(closes issue #14489)
Reported by: russell
Review: http://reviewboard.digium.com/r/162/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@176666 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch includes a number of changes to the indications API. The primary
motivation for this work was to improve stability. The object management
in this API was significantly flawed, and a number of trivial situations could
cause crashes.
The changes included are:
1) Remove the module res_indications. This included the critical functionality
that actually loaded the indications configuration. I have seen many people
have Asterisk problems because they accidentally did not have an
indications.conf present and loaded. Now, this code is in the core,
and Asterisk will fail to start without indications configuration.
There was one part of res_indications, the dialplan applications, which did
belong in a module, and have been moved to a new module, app_playtones.
2) Object management has been significantly changed. Tone zones are now
managed using astobj2, and it is no longer possible to crash Asterisk by
issuing a reload that destroys tone zones while they are in use.
3) The API documentation has been filled out.
4) The API has been updated to follow our naming conventions.
5) Various bits of code throughout the tree have been updated to account
for the API update.
6) Configuration parsing has been mostly re-written.
7) "Code cleanup"
The code is from svn/asterisk/team/russell/indications/.
Review: http://reviewboard.digium.com/r/149/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@176627 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The 'd' option would not work for channel types which use RTP to transport
DTMF digits. The only way to allow for this to work was to answer the channel
if we saw that this option was enabled.
I realized that this may cause issues with CDRs, specifically with giving false
dispositions and answer times. I therefore modified ast_answer to take another
parameter which would tell if the CDR should be marked answered.
I also extended this to the Answer application so that the channel may be answered
but not CDRified if desired.
I also modified app_dictate and app_waitforsilence to only answer the channel if it
is not already up, to help not allow for faulty CDR answer times.
All of these changes are going into Asterisk trunk. For 1.6.0 and 1.6.1, however, all
the changes except for the change to the Answer application will go in since we do
not introduce new features into stable branches
(closes issue #14164)
Reported by: DennisD
Patches:
14164.patch uploaded by putnopvut (license 60)
Tested by: putnopvut
Review: http://reviewboard.digium.com/r/145
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@174945 65c4cc65-6c06-0410-ace0-fbb531ad65f3
We need to do this because while we know that the freeing of the channel may cause something to become
not in use we do not know this for sure. There may be another channel that is still up which would cause
it to be in use.
(closes issue #13238)
Reported by: kowalma
Patches:
20090121__bug13238.diff.txt uploaded by Corydon76 (license 14)
Tested by: alecdavis
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@174844 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r170648 | file | 2009-01-23 16:16:39 -0400 (Fri, 23 Jan 2009) | 4 lines
When a channel is answered make sure any indications currently playing stop. Usually the phone would do this but if the channel was already answered then they are being generated by Asterisk and we darn well need to stop them.
(closes issue #14249)
Reported by: RadicAlish
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@170652 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r170392 | mmichelson | 2009-01-23 09:40:39 -0600 (Fri, 23 Jan 2009) | 28 lines
Fix broken call pickup
There was a subtle change in ast_do_masquerade which
resulted in failed attempts to pickup calls. The problem
was that the value of the AST_FLAG_OUTGOING flag was
copied from the clone to the original channel. In the case
of call pickup, this meant that the AST_FLAG_OUTGOING flag
ended up being cleared on the channel that was attempting
to execute the pickup.
Because this flag was not set, when ast_read came across
an answer frame, it ignored it. The result of this was that
the calling channel was never properly answered.
This fix changes the behavior in ast_do_masquerade to set
the flags on the original channel to the union of the flags
on the clone channel. This way, if the AST_FLAG_OUTGOING
flag is set on either of the two channels involved in the
masquerade, the resulting channel will have the flag set
as well.
(closes issue #14206)
Reported by: francesco_r
Patches:
14206.patch uploaded by putnopvut (license 60)
Tested by: francesco_r, aragon, putnopvut
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@170393 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r166568 | mmichelson | 2008-12-23 09:16:26 -0600 (Tue, 23 Dec 2008) | 12 lines
Fix a crash resulting from a datastore with inheritance but no duplicate callback
The fix for this is to simply set the newly created datastore's data pointer
to NULL if it is inherited but has no duplicate callback.
(closes issue #14113)
Reported by: francesco_r
Patches:
14113.patch uploaded by putnopvut (license 60)
Tested by: francesco_r
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@166569 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This function is being added as a method to allow for
an audiohook to move to a new channel during a channel
masquerade. The most obvious use for such a facility is
for MixMonitor when a transfer is performed. Prior to
the addition of this functionality, if a channel
running MixMonitor was transferred by another party, then
the recording would stop once the transfer had completed.
By using AUDIOHOOK_INHERIT, you can make MixMonitor
continue recording the call even after the transfer
has completed.
It has also been determined that since this is seen
by most as a bug fix and is not an invasive change,
this functionality will also be backported to 1.4 and
merged into the 1.6.0 branches, even though they are
feature-frozen.
(closes issue #13538)
Reported by: mbit
Patches:
13538.patch uploaded by putnopvut (license 60)
Tested by: putnopvut
Review: http://reviewboard.digium.com/r/102/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@166092 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r164201 | russell | 2008-12-15 08:31:37 -0600 (Mon, 15 Dec 2008) | 31 lines
Handle a case where a call can be bridged to a channel that is still ringing.
The issue that was reported was about a case where a RINGING channel got
redirected to an extension to pick up a call from parking. Once the parked
call got taken out of parking, it heard silence until the other side answered.
Ideally, the caller that was parked would get a ringing indication. This patch
fixes this case so that the caller receives ringback once it comes out of
parking until the other side answers.
The fixes are:
- Make sure we remember that a channel was an outgoing channel when doing
a masquerade. This prevents an erroneous ast_answer() call on the channel,
which causes a bogus 200 OK to be sent in the case of SIP.
- Add some additional comments to explain related parts of code.
- Update the handling of the ast_channel visible_indication field. Storing
values that are not stateful is pointless. Control frames that are events
or commands should be ignored.
- When a bridge first starts, check to see if the peer channel needs to be
given ringing indication because the calling side is still ringing.
- Rework ast_indicate_data() a bit for the sake of readability.
(closes issue #13747)
Reported by: davidw
Tested by: russell
Review: http://reviewboard.digium.com/r/90/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@164203 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r163448 | russell | 2008-12-12 07:44:08 -0600 (Fri, 12 Dec 2008) | 26 lines
Resolve issues that could cause DTMF to be processed out of order.
These changes come from team/russell/issue_12658
1) Change autoservice to put digits on the head of the channel's frame readq
instead of the tail. If there were frames on the readq that autoservice
had not yet read, the previous code would have resulted in out of order
processing. This required a new API call to queue a frame to the head
of the queue instead of the tail.
2) Change up the processing of DTMF in ast_read(). Some of the problems
were the result of having two sources of pending DTMF frames. There
was the dtmfq and the more generic readq. Both were used for pending
DTMF in various scenarios. Simplifying things to only use the frame
readq avoids some of the problems.
3) Fix a bug where a DTMF END frame could get passed through when it
shouldn't have. If code set END_DTMF_ONLY in the middle of digit emulation,
and a digit arrived before emulation was complete, digits would get
processed out of order.
(closes issue #12658)
Reported by: dimas
Tested by: russell, file
Review: http://reviewboard.digium.com/r/85/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@163449 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The conversion to use ast_check_hangup() everywhere instead of checking the softhangup
flag directly introduced this problem. The issue is that ast_check_hangup() checked
for tech_pvt to be NULL. Unfortunately, this will be NULL is some valid circumstances,
such as with a dummy channel.
The fix is simple. Don't check tech_pvt. It's pointless, because the code path that
sets this to NULL is when the channel hangup callback gets called. This happens inside
of ast_hangup(), which is the same function responsible for freeing the channel. Any
code calling ast_check_hangup() better not be calling it after that point, and if so,
we have a bigger problem at hand.
(closes issue #14035)
Reported by: erogoza
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@163171 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ast_channel_search_locked need to be made. Specifically, the caller needs to be able to
pass arbitrary data which in turn is passed to the callback. This patch addresses all
of the nested functions currently in asterisk trunk.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@155590 65c4cc65-6c06-0410-ace0-fbb531ad65f3
channel list calling a caller-defined callback. The callback returns non-zero
if a match is found. This should speed up some of the code that I committed
earlier today in chan_sip (which is also updated by this commit).
Reviewed by russellb and kpfleming via ReviewBoard:
http://reviewboard.digium.com/r/28/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@154429 65c4cc65-6c06-0410-ace0-fbb531ad65f3
or when calling ast_waitfor(). These are inappropriate times to hold the channel
lock. This is what has caused "could not get the channel lock" messages from
chan_sip and has likely caused a negative impact on performance results of SIP
in Asterisk 1.6. Thanks to file for pointing out this section of code.
(closes issue #13287)
(closes issue #13115)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141949 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Mark Michelson
Tilghman Lesher
Joshua Colp
Jeff Peeler
Russell Bryant
Kevin P. Fleming
David Vossel
Olle Johansson
Sean Bright
Steve Murphy