| Age | Commit message (Collapse) | Author |
|---|
|
From reviewboard:
Digium has a commercial customer who has made extensive use of the connected party and
redirecting information present in later versions of Asterisk Business Edition and which
is to be in the upcoming 1.8 release. Through their use of the feature, new problems and solutions
have come about. This patch adds several enhancements to maximize usage of the connected party
and redirecting information functionality.
First, Asterisk trunk already had connected line interception macros. These macros allow you to
manipulate connected line information before it was sent out to its target. This patch adds the
same feature except for redirecting information instead.
Second, the ast_callerid and ast_party_id structures have been enhanced to provide a "tag." This
tag can be set with func_callerid, func_connectedline, func_redirecting, and in the case of DAHDI,
mISDN, and SIP channels, can be set in a configuration file. The idea behind the callerid tag is
that it can be set to whatever value the administrator likes. Later, when running connected line
and redirecting macros, the admin can read the tag off the appropriate structure to determine what
action to take. You can think of this sort of like a channel variable, except that instead of having
the variable associated with a channel, the variable is associated with a specific identity within
Asterisk.
Third, app_dial has two new options, s and u. The s option lets a dialplan writer force a specific
caller ID tag to be placed on the outgoing channel. The u option allows the dialplan writer to force
a specific calling presentation value on the outgoing channel.
Fourth, there is a new control frame subclass called AST_CONTROL_READ_ACTION added. This was added
to correct a very specific situation. In the case of SIP semi-attended (blond) transfers, the party
being transferred would not have the opportunity to run a connected line interception macro to
possibly alter the transfer target's connected line information. The issue here was that during a
blond transfer, the SIP transfer code has no bridged channel on which to queue the connected line
update. The way this was corrected was to add this new control frame subclass. Now, we queue an
AST_CONTROL_READ_ACTION frame on the channel on which the connected line interception macro should
be run. When ast_read is called to read the frame, ast_read responds by calling a callback function
associated with the specific read action the control frame describes. In this case, the action taken
is to run the connected line interception macro on the transferee's channel.
Review: https://reviewboard.asterisk.org/r/652/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263541 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r259858 | dvossel | 2010-04-28 16:16:03 -0500 (Wed, 28 Apr 2010) | 33 lines
resolves deadlocks in chan_local
Issue_1.
In the local_hangup() 3 locks must be held at the same time... pvt, pvt->chan,
and pvt->owner. Proper deadlock avoidance is done when the channel to hangup
is the outbound chan_local channel, but when it is not the outbound channel we
have an issue... We attempt to do deadlock avoidance only on the tech pvt, when
both the tech pvt and the pvt->owner are locked coming into that loop. By
never giving up the pvt->owner channel deadlock avoidance is not entirely possible.
This patch resolves that by doing deadlock avoidance on both the pvt->owner and the pvt
when trying to get the pvt->chan lock.
Issue_2.
ast_prod() is used in ast_activate_generator() to queue a frame on the channel
and make the channel's read function get called. This function is used in
ast_activate_generator() while the channel is locked, which mean's the channel
will have a lock both from the generator code and the frame_queue code by the
time it gets to chan_local.c's local_queue_frame code... local_queue_frame
contains some of the same crazy deadlock avoidance that local_hangup requires,
and this recursive lock prevents that deadlock avoidance from happening correctly.
This patch removes ast_prod() from the channel lock so only one lock is held during
the local_queue_frame function.
(closes issue #17185)
Reported by: schmoozecom
Patches:
issue_17185_v1.diff uploaded by dvossel (license 671)
issue_17185_v2.diff uploaded by dvossel (license 671)
Tested by: schmoozecom, GameGamer43
Review: https://reviewboard.asterisk.org/r/631/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@259870 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Call completion code tries to grab the call completion parameters
from the requesting channel during local_request. When originating
a call to a local channel, however, this channel is NULL. This
was causing an issue for me when trying to run a test script.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256646 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
From Reviewboard:
CCSS stands for Call Completion Supplementary Services. An admittedly out-of-date
overview of the architecture can be found in the file doc/CCSS_architecture.pdf
in the CCSS branch. Off the top of my head, the big differences between what is
implemented and what is in the document are as follows:
1. We did not end up modifying the Hangup application at all.
2. The document states that a single call completion monitor may be used across
multiple calls to the same device. This proved to not be such a good idea
when implementing protocol-specific monitors, and so we ended up using one
monitor per-device per-call.
3. There are some configuration options which were conceived after the document
was written. These are documented in the ccss.conf.sample that is on this
review request.
For some basic understanding of terminology used throughout this code, see the
ccss.tex document that is on this review.
This implements CCBS and CCNR in several flavors.
First up is a "generic" implementation, which can work over any channel technology
provided that the channel technology can accurately report device state. Call
completion is requested using the dialplan application CallCompletionRequest and can
be canceled using CallCompletionCancel. Device state subscriptions are used in order
to monitor the state of called parties.
Next, there is a SIP-specific implementation of call completion. This method uses the
methods outlined in draft-ietf-bliss-call-completion-06 to implement call completion
using SIP signaling. There are a few things to note here:
* The agent/monitor terminology used throughout Asterisk sometimes is the reverse of
what is defined in the referenced draft.
* Implementation of the draft required support for SIP PUBLISH. I attempted to write
this in a generic-enough fashion such that if someone were to want to write PUBLISH
support for other event packages, such as dialog-state or presence, most of the effort
would be in writing callbacks specific to the event package.
* A subportion of supporting PUBLISH reception was that we had to implement a PIDF
parser. The PIDF support added is a bit minimal. I first wrote a validation
routine to ensure that the PIDF document is formatted properly. The rest of the
PIDF reading is done in-line in the call-completion-specific PUBLISH-handling
code. In other words, while there is PIDF support here, it is not in any state
where it could easily be applied to other event packages as is.
Finally, there are a variety of ISDN-related call completion protocols supported. These
were written by Richard Mudgett, and as such I can't really say much about their
implementation. There are notes in the CHANGES file that indicate the ISDN protocols
over which call completion is supported.
Review: https://reviewboard.asterisk.org/r/523
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
SWP-1229
ABE-2161
* Ensure chan_local.c:local_call() will not leak cid.cid_dnid when
copying.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256104 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r256014 | russell | 2010-04-02 18:45:56 -0500 (Fri, 02 Apr 2010) | 9 lines
Resolve a deadlock that occurs due to a pointless call to ast_bridged_channel()
(closes issue #16840)
Reported by: bzing2
Patches:
patch.txt uploaded by bzing2 (license 902)
issue_16840.rev1.diff uploaded by russell (license 2)
Tested by: bzing2, russell
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256015 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Only chan_dahdi set a value in cdrflags. Everyone else just copied it
around the system. Noone cared about any value it may have contained.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@250565 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When configuring the adaptive jitterbuffer, the target_extra
value not only could not be set from the configuration, but was
not even being set to its proper default. This value is required
in order for the adaptive jitterbuffer to work correctly. To resolve
this a config option has been added to expose this value to the conf
files, and a default value is provided when no config specific value
is present.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@249893 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r249536 | jpeeler | 2010-03-01 11:02:03 -0600 (Mon, 01 Mar 2010) | 11 lines
Modify queued frames from local channels to not set the other side to up
In this case, attended transfers were broken due to ast_feature_request_and_dial
detecting the channel being set to up before the answer frame could be read and
therefore failing to mark the channel as ready. This fix is a regression fix for
244785, which should continue to work properly as well.
(closes issue #16816)
Reported by: jamhed
Tested by: jamhed, corruptor
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@249538 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Previously local channels channel state never changed. This became problematic
when the state of the other side of the local channel was lost, for example
during a masquerade. Changing the state of the local channel allows for the
scenario to be detected when the channel state is set to ringing, but the peer
isn't ringing. The specific problem scenario is described in 164201. Although
this was noted on one of the issues, here is the tested dialplan verified to
work:
exten => 9700,1,Dial(Local/*9700@default&Local/0009700@default)
exten => *9700,1,Set(GLOBAL(TESTCHAN)=${CHANNEL:0:${MATH(${LEN(${CHANNEL})}-1):0:2}}1)
exten => *9700,n,wait(3) ;3 works, 1 did not
exten => *9700,n,Dial(SIP/5001)
exten => 0009700,1,Wait(1) ;1 works, 3 did not
exten => 0009700,n,ChannelRedirect(${TESTCHAN},parkedcalls,701,1)
(closes issue #14992)
Reported by: davidw
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@246070 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r244070 | tilghman | 2010-02-01 11:46:31 -0600 (Mon, 01 Feb 2010) | 16 lines
Revert previous chan_local fix (r236981) and fix instead by destroying expired frames in the queue.
(closes issue #16525)
Reported by: kobaz
Patches:
20100126__issue16525.diff.txt uploaded by tilghman (license 14)
20100129__issue16525__1.6.0.diff.txt uploaded by tilghman (license 14)
Tested by: kobaz, atis
(closes issue #16581)
Reported by: ZX81
(closes issue #16681)
Reported by: alexr1
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@244071 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r237318 | tilghman | 2010-01-04 10:18:59 -0600 (Mon, 04 Jan 2010) | 3 lines
It's also possible for the Local channel to directly execute an Application.
Reviewboard: https://reviewboard.asterisk.org/r/452/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@237319 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r236981 | tilghman | 2009-12-30 15:57:10 -0600 (Wed, 30 Dec 2009) | 9 lines
Don't queue frames to channels that have no means to process them.
(closes issue #15609)
Reported by: aragon
Patches:
20091230__issue16521__1.4__chan_local_only.diff.txt uploaded by tilghman (license 14)
Tested by: aragon
Review: https://reviewboard.asterisk.org/r/452/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@236982 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r230038 | file | 2009-11-13 13:44:07 -0600 (Fri, 13 Nov 2009) | 9 lines
Fix a crash caused by two threads thinking they should both free the
chan_local private structure when only one should.
(closes issue #15314)
Reported by: sroberts
Patches:
Issue15314_Move_Nulling_owner.patch uploaded by davidw (license 780)
Tested by: davidw, lottc
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@230039 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This is a similar solution to what is in place for chan_agent
(closes issue #16003)
Reported by: atis
Tested by: twilson
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@229015 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Reviewboard: https://reviewboard.asterisk.org/r/416/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@227580 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r226531 | file | 2009-10-29 15:11:26 -0300 (Thu, 29 Oct 2009) | 6 lines
Add an option to enabling passing music on hold start and stop requests through instead of
acting on them in chan_local.
(closes issue #14709)
Reported by: dimas
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@226532 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@226490 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r214940 | tilghman | 2009-08-31 11:16:52 -0500 (Mon, 31 Aug 2009) | 7 lines
Also unlock the "other" channel, when returning, due to glare.
(closes issue #15787)
Reported by: tim_ringenbach
Patches:
chan_local.diff uploaded by tim ringenbach (license 540)
Tested by: tim_ringenbach
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@214945 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
CEL is the new system for logging channel events. This was inspired after
facing many problems trying to represent what is possible to happen to a call
in Asterisk using CDR records. For more information on CEL, see the built in
HTML or PDF documentation generated from the files in doc/tex/.
Many thanks to Steve Murphy (murf) and Brian Degenhardt (bmd) for their hard
work developing this code. Also, thanks to Matt Nicholson (mnicholson) and
Sean Bright (seanbright) for their assistance in the final push to get this
code ready for Asterisk trunk.
Review: https://reviewboard.asterisk.org/r/239/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@203638 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
extension from a queue.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@200326 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Oh, and this fixes a deadlock I was seeing.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@198529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@198511 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@197701 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r190286 | file | 2009-04-23 16:13:18 -0300 (Thu, 23 Apr 2009) | 6 lines
Fix a bug in chan_local glare hangup detection.
If both sides of a Local channel were hung up at around the same time it was
possible for one thread to destroy the local private structure and have the other thread
immediately try to remove the already freed structure from the local channel list.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190287 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
the local_pvt.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@187830 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@187714 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Asterisk.
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 provides a generic way for multiple RTP stacks to be
integrated into Asterisk. Right now there is only one present, res_rtp_asterisk,
which is the existing Asterisk RTP stack. Functionality wise this commit
performs the same as previously. API documentation can be viewed in the
rtp_engine.h header file.
Review: http://reviewboard.digium.com/r/209/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@186078 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r182208 | tilghman | 2009-03-16 10:39:15 -0500 (Mon, 16 Mar 2009) | 7 lines
Fixup glare detection, to fix a memory leak of a local pvt structure.
(closes issue #14656)
Reported by: caspy
Patches:
20090313__bug14656__2.diff.txt uploaded by tilghman (license 14)
Tested by: caspy
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@182211 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
masq, so that the group count lingers past the bridge.
(closes issue #14275)
Reported by: kowalma
Patches:
20090216__bug14275.diff.txt uploaded by Corydon76 (license 14)
Tested by: kowalma
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@176642 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172319 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Also, implement a private cause code (as suggested by Tilghman). This works with
chan_sip, but doesn't propagate through chan_local.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172318 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r169210 | mmichelson | 2009-01-19 09:52:15 -0600 (Mon, 19 Jan 2009) | 13 lines
Prevent a crash in chan_local due to a potential NULL pointer dereference
Move the check for if both channels on a local_pvt have generators to below
where p->chan is checked for NULLity (NULLness?). This prevents a crash from
occurring if p->chan is NULL.
(closes issue #14189)
Reported by: sascha
Patches:
14189.patch uploaded by putnopvut (license 60)
Tested by: sascha
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@169211 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r166953 | tilghman | 2008-12-31 13:20:35 -0600 (Wed, 31 Dec 2008) | 5 lines
Also inherit the musiconhold class.
(Closes #14153)
Reported by: Jerry Geis, via the users list.
Patch by: me (license 14)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@166954 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r157305 | mmichelson | 2008-11-18 12:25:55 -0600 (Tue, 18 Nov 2008) | 12 lines
Fix a crash in the end_bridge_callback of app_dial and
app_followme which would occur at the end of an attended
transfer. The error occurred because we initially stored
a pointer to an ast_channel which then was hung up due
to a masquerade.
This commit adds a "fixup" callback to the bridge_config
structure to allow for end_bridge_callback_data to be
changed in the case that a new channel pointer is needed
for the end_bridge_callback.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@157306 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r152922 | tilghman | 2008-10-30 14:43:38 -0500 (Thu, 30 Oct 2008) | 6 lines
Unlock before returning, when extension doesn't exist.
(closes issue #13807)
Reported by: eliel
Patches:
chan_local.c.patch uploaded by eliel (license 64)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@152923 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r152215 | tilghman | 2008-10-27 16:32:00 -0500 (Mon, 27 Oct 2008) | 6 lines
Inherit ALL elements of CallerID across a local channel.
(closes issue #13368)
Reported by: Peter Schlaile
Patches:
20080826__bug13368.diff.txt uploaded by Corydon76 (license 14)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@152216 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r148912 | mmichelson | 2008-10-14 12:33:38 -0500 (Tue, 14 Oct 2008) | 9 lines
Deadlock prevention in chan_local.
(closes issue #13676)
Reported by: tacvbo
Patches:
13676.patch uploaded by putnopvut (license 60)
Tested by: tacvbo
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@148913 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r146711 | tilghman | 2008-10-06 11:51:21 -0500 (Mon, 06 Oct 2008) | 9 lines
Check whether an extension exists in the _call method, rather than the _alloc
method, because we need to evaluate the callerid (since that data affects
whether an extension exists).
(closes issue #13343)
Reported by: efutch
Patches:
20080915__bug13343.diff.txt uploaded by Corydon76 (license 14)
Tested by: efutch
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@146713 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r142927 | jpeeler | 2008-09-12 17:22:28 -0500 (Fri, 12 Sep 2008) | 6 lines
(closes issue #12965)
Reported by: rlsutton2
Prevents local channels from playing MOH at each other which was causing ast_generic_bridge to loop much faster.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@142929 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
issue #12914)
Requested here: http://lists.digium.com/pipermail/asterisk-dev/2008-June/033658.html
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@125853 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r125740 | tilghman | 2008-06-27 07:19:39 -0500 (Fri, 27 Jun 2008) | 7 lines
Add proper deadlock avoidance.
(closes issue #12914)
Reported by: ozan
Patches:
20080625__bug12914.diff.txt uploaded by Corydon76 (license 14)
Tested by: ozan
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@125741 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
of the channel lock
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@125020 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r124315 | tilghman | 2008-06-20 15:16:02 -0500 (Fri, 20 Jun 2008) | 8 lines
When using a Local channel, started by a call file, with a destination of an
AGI script, the AGI script does not always get notified of a hangup if the
underlying channel hangs up early.
(closes issue #11833)
Reported by: IgorG
Patches:
local_hangup-v1.diff uploaded by IgorG (license 20)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@124316 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r121078 | russell | 2008-06-07 09:10:56 -0500 (Sat, 07 Jun 2008) | 7 lines
Don't run LIST_HEAD_DESTROY on a STATIC list
(closes issue #12807)
Reported by: ys
Patches:
chan_agent_local.diff uploaded by ys (license 281)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@121079 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
- make data member of the ast_frame struct a named union instead of a void
Recently the ast_queue_hangup function got a new parameter, the hangupcause
Feedback came in that this is no good and that instead a new function should be created.
This I did.
The hangupcause was stored in the seqno member of the ast_frame struct. This is not very
elegant, and since there's already a data member that one should be used.
Problem is, this member was a void *.
Now it's a named union so it can hold a pointer, an uint32 and there's a padding in case someone
wants to store another type in there in the future.
This commit is so massive, because all ast_frame.data uses have to be
altered to ast_frame.data.data
Thanks russellb and kpfleming for the feedback.
(closes issue #12674)
Reported by: mvanbaak
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@117802 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r116038 | russell | 2008-05-13 16:17:23 -0500 (Tue, 13 May 2008) | 24 lines
Fix a deadlock involving channel autoservice and chan_local that was debugged
and fixed by mmichelson and me.
We observed a system that had a bunch of threads stuck in ast_autoservice_stop().
The reason these threads were waiting around is because this function waits to
ensure that the channel list in the autoservice thread gets rebuilt before the
stop() function returns. However, the autoservice thread was also locked, so
the autoservice channel list was never getting rebuilt.
The autoservice thread was stuck waiting for the channel lock on a local channel.
However, the local channel was locked by a thread that was stuck in the autoservice
stop function.
It turned out that the issue came down to the local_queue_frame() function in
chan_local. This function assumed that one of the channels passed in as an
argument was locked when called. However, that was not always the case. There
were multiple cases in which this channel was not locked when the function was
called. We fixed up chan_local to indicate to this function whether this channel
was locked or not. The previous assumption had caused local_queue_frame() to
improperly return with the channel locked, where it would then never get unlocked.
(closes issue #12584)
(related to issue #12603)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@116039 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(closes issue #11328)
Reported by: rain
Patches:
20071207__pass_cause_in_hangup_control_frame.diff.txt uploaded by Corydon76 (license 14)
brought up-to-date to trunk by me
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@114637 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
