Asterisk maintains an internal cache for devices in the event subsystem. The
device state cache holds the state of each device known to Asterisk, such that
consumers of device state information can query for the last known state for
a particular device, even if it is not part of an active call. The concept of
a device in Asterisk can include entities that do not have a physical
representation. One way that this occurred was when anonymous calls are allowed
in Asterisk. A device was automatically created and stored in the cache for
each anonymous call that occurred; this was possible in the SIP and IAX2
channel drivers and through channel drivers that utilized the
res_jabber/res_xmpp resource modules (Gtalk, Jingle, and Motif). These devices
are never removed from the system, allowing anonymous calls to potentially
exhaust a system's resources.
This patch changes the event cache subsystem and device state management to
no longer cache devices that are not associated with a physical entity.
(issue ASTERISK-20175)
Reported by: Russell Bryant, Leif Madsen, Joshua Colp
Tested by: kmoore
patches:
event-cachability-3.diff uploaded by jcolp (license 5000)
........
Merged revisions 378303 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 378320 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@378321 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Users of the T.38 API can indicate AST_T38_REQUEST_PARMS on a channel to request that the
channel indicate a T.38 negotiation with the parameters present on the channel. The return
value of this indication is expected to be AST_T38_REQUEST_PARMS upon success but with
chan_local involved this could never occur.
This fix changes chan_local to always return AST_T38_REQUEST_PARMS for this situation. If
the underlying channel technology on the other side does not support T.38 this would have
been determined ahead of time using ast_channel_get_t38_state and an indication would
not occur.
(closes issue ASTERISK-20229)
Reported by: wdoekes
Patches:
ASTERISK-20229.patch uploaded by wdoekes (license 5674)
Review: https://reviewboard.asterisk.org/r/2070/
........
Merged revisions 373705 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 373706 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@373707 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds some basic documentation for a number of modules. This
includes core source files in Asterisk (those in main), as well as
chan_agent, chan_dahdi, chan_local, sig_analog, and sig_pri. The DTD
has also been updated to allow referencing of AMI commands.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369905 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Hangup handlers are an alternative to the h extension. They can be used
in addition to the h extension. The idea is to attach a Gosub routine to
a channel that will execute when the call hangs up. Whereas which h
extension gets executed depends on the location of dialplan execution when
the call hangs up, hangup handlers are attached to the call channel. You
can attach multiple handlers that will execute in the order of most
recently added first.
(closes issue ASTERISK-19549)
Reported by: Mark Murawski
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/2002/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369493 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Adds call ID logging changes to specific channel drivers that weren't handled
handled in phase II of Call ID Logging. Also covers logging for threads for
threads created by systems that may be involved with many different calls.
Extra special thanks to Richard for rigorous review of chan_dahdi and its
various signalling modules.
review: https://reviewboard.asterisk.org/r/1927/
review: https://reviewboard.asterisk.org/r/1950/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369414 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This was essentially duplicated functionality where normal channels used
AST_CAUSE_ANSWERED_ELSEWHERE while local channels and queues used
AST_FLAG_ANSWERED_ELSEWHERE. This removes the flag and converts that usage
into AST_CAUSE_ANSWERED_ELSEWHER usage.
Review: https://reviewboard.asterisk.org/r/1944
(closes issue ASTERISK-19865)
Patch-by: Birger Harzenetter
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368519 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When ast_call() operates on a local channel, it copies a lot of things
from the local;1 channel to the local;2 channel. This includes among
other things, channel variables and party id information.
Other reasons it was a bad idea to run predial on the local;2 channel:
1) The channel has not been completely setup. The ast_call() completes
the setup.
2) The local;2 caller and connected line party information is opposite to
any other channels predial runs on. (And it hasn't been setup yet.)
* Partially back out -r366183 by removing the chan_local implementation of
the struct ast_channel_tech.pre_call callback.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@366546 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Before this patch, the predial routine executes on the ;1 channel of a
local channel pair. Executing predial on the ;1 channel of a local
channel pair is of limited utility. Any channel variables set by the
predial routine executing on the ;1 channel will not be available when the
local channel executes dialplan on the ;2 channel.
* Create ast_pre_call() and an associated pre_call() technology callback
to handle running the predial routine. If a channel technology does not
provide the callback, the predial routine is simply run on the channel.
Review: https://reviewboard.asterisk.org/r/1903/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@366183 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Made chan_local.c:check_bridge() check the return value of
ast_channel_masquerade(). In long chains of local channels, the
masquerade occasionally fails to get setup because there is another
masquerade already setup on an adjacent local channel in the chain.
* Made the outgoing local channel (the ;2 channel) flush one voice or
video frame per optimization attempt.
* Made sure that the outgoing local channel also does not have any frames
in its queue before the masquerade.
* Made do the masquerade immediately to minimize the chance that the
outgoing channel queue does not get any new frames added and thus
unconditionally flushed.
* Made block indication -1 (Stop tones) event when the local channel is
going to optimize itself out. When the call is answered, a chain of local
channels pass down a -1 indication for each bridge. This blizzard of -1
events really slows down the optimization process.
(closes issue ASTERISK-16711)
Reported by: Alec Davis
Tested by: rmudgett, Alec Davis
Review: https://reviewboard.asterisk.org/r/1894/
........
Merged revisions 365313 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 365320 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@365356 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r365006 | twilson | 2012-05-02 10:49:03 -0500 (Wed, 02 May 2012) | 12 lines
Fix a CEL LINKEDID_END race and local channel linkedids
This patch has the ;2 channel inherit the linkedid of the ;1 channel and fixes
the race condition by no longer scanning the channel list for "other" channels
with the same linkedid. Instead, cel.c has an ao2 container of linkedid strings
and uses the refcount of the string as a counter of how many channels with the
linkedid exist. Not only does this eliminate the race condition, but it also
allows us to look up the linkedid by the hashed key instead of traversing the
entire channel list.
Review: https://reviewboard.asterisk.org/r/1895/
........
r365068 | twilson | 2012-05-02 12:02:39 -0500 (Wed, 02 May 2012) | 11 lines
Don't leak a ref if out of memory and can't link the linkedid
If the ao2_link fails, we are most likely out of memory and bad things
are going to happen. Before those bad things happen, make sure to clean
up the linkedid references.
This patch also adds a comment explaining why linkedid can't be passed
to both local channel allocations and combines two ao2_ref calls into 1.
Review: https://reviewboard.asterisk.org/r/1895/
........
Merged revisions 365006,365068 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 365083 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@365084 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The CHANNEL_DEADLOCK_AVOIDANCE() feature of preserving where the channel
lock was originally obtained is overkill where ast_channel_lock_both() was
inlined.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@362888 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Continue channel opaque-ification by wrapping all of the stringfields.
Eventually, we will restrict what can actually set these variables, but
the purpose for now is to hide the implementation and keep people from
adding code that directly accesses the channel structure. Semantic
changes will follow afterward.
Review: https://reviewboard.asterisk.org/r/1661/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@352348 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There are many benefits to making the ast_channel an opaque handle, from
increasing maintainability to presenting ways to kill masquerades. This patch
kicks things off by taking things a field at a time, renaming the field to
'__do_not_use_${fieldname}' and then writing setters/getters and converting the
existing code to using them. When all fields are done, we can move ast_channel
to a C file from channel.h and lop off the '__do_not_use_'.
This patch sets up main/channel_interal_api.c to be the only file that actually
accesses the ast_channel's fields directly. The intent would be for any API
functions in channel.c to use the accessor functions. No more monkeying around
with channel internals. We should use our own APIs.
The interesting changes in this patch are the addition of
channel_internal_api.c, the moving of the AST_DATA stuff from channel.c to
channel_internal_api.c (note: the AST_DATA stuff will have to be reworked to
use accessor functions when ast_channel is really opaque), and some re-working
of the way channel iterators/callbacks are handled so as to avoid creating fake
ast_channels on the stack to pass in matching data by directly accessing fields
(since "name" is a stringfield and the fake channel doesn't init the
stringfields, you can't use the ast_channel_name_set() function). I went with
ast_channel_name(chan) for a getter, and ast_channel_name_set(chan, name) for a
setter.
The majority of the grunt-work for this change was done by writing a semantic
patch using Coccinelle ( http://coccinelle.lip6.fr/ ).
Review: https://reviewboard.asterisk.org/r/1655/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@350223 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r315446 | russell | 2011-04-26 12:40:23 -0500 (Tue, 26 Apr 2011) | 14 lines
chan_local: resolve a deadlock.
This patch resolves a fairly complex deadlock that can occur with the
combination of chan_local and a dialplan switch, such as dynamic realtime
extensions, which pulls autoservice into the picture when doing a dialplan
lookup.
(closes issue #18818)
Reported by: nic
Patches:
issue18818.patch uploaded by jthurman (license 614)
18818.v1.txt uploaded by russell (license 2)
Tested by: nic, jthurman, kterzi, steve-howes, sysreq, IshMalik
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@315447 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r306127 | twilson | 2011-02-03 13:03:26 -0800 (Thu, 03 Feb 2011) | 23 lines
Merged revisions 306126 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r306126 | twilson | 2011-02-03 12:56:00 -0800 (Thu, 03 Feb 2011) | 16 lines
Merged revisions 306119 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r306119 | twilson | 2011-02-03 12:36:34 -0800 (Thu, 03 Feb 2011) | 9 lines
Set hangup cause in local_hangup
When a call involves a local channel (like SIP -> Local -> SIP), the hangup
cause was not being set. This resulted in SIP channels sometimes getting a
503 error instead of a 486 when the far side sent a busy. In Asterisk 1.8+
this also can cause issues with CCSS that involve a local channel. This patch
sets the hangupcause for one side of the local channel to the other in
local_hangup for outbound calls.
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@306128 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch is the foundation of an entire new way of looking at media in Asterisk.
The code present in this patch is everything required to complete phase1 of my
Media Architecture proposal. For more information about this project visit the link below.
https://wiki.asterisk.org/wiki/display/AST/Media+Architecture+Proposal
The primary function of this patch is to convert all the usages of format
bitfields in Asterisk to use the new format and format_cap APIs. Functionally
no change in behavior should be present in this patch. Thanks to twilson
and russell for all the time they spent reviewing these changes.
Review: https://reviewboard.asterisk.org/r/1083/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@306010 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r302412 | seanbright | 2011-01-19 10:31:39 -0500 (Wed, 19 Jan 2011) | 10 lines
Use appropriate type for requested format in chan_local.
We were passing and storing the requested format as an int instead of format_t
resulting in truncation.
(closes issue #18238)
Reported by: whizemen
Patches:
0018238_speex16.patch uploaded by whizemen (license 1143)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302413 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r292868 | dvossel | 2010-10-25 14:07:50 -0500 (Mon, 25 Oct 2010) | 39 lines
Merged revisions 292867 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r292867 | dvossel | 2010-10-25 14:06:21 -0500 (Mon, 25 Oct 2010) | 32 lines
Merged revisions 292866 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r292866 | dvossel | 2010-10-25 14:05:07 -0500 (Mon, 25 Oct 2010) | 27 lines
This patch turns chan_local pvts into astobj2 objects.
chan_local does some dangerous things involving deadlock avoidance.
tech_pvt functions like hangup and queue_frame are provided with a
locked channel upon entry. Those functions are completely safe as
long as you don't attempt to give up that channel lock, but that is
impossible to guarantee due to the required deadlock avoidance necessary
to lock both the tech_pvt and both channels involved.
In the past, we have tried to account for this by doing things like
setting a "glare" flag that indicates what function should destroy the
pvt. This was used in local_hangup and local_queue_frame to decided
who should destroy the pvt if they collided in separate threads. I
have removed the need to do this by converting all chan_local tech_pvts
to astobj2. This means we can ref a pvt before deadlock avoidance
and not have to worry about that pvt possibly getting destroyed under
us. It also cleans up where we destroy the tech_pvt. The only unlink
from the tech_pvt container occurs in local_hangup now, which is where
it should occur.
Since there still may be thread collisions on some functions like
local_hangup after deadlock avoidance, I have added some checks to detect
those collisions and exit appropriately. I think this patch is going to
solve quite a bit of weirdness we have had with local channels in the past.
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@292869 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r286189 | twilson | 2010-09-10 17:04:53 -0500 (Fri, 10 Sep 2010) | 30 lines
Merged revisions 286115 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r286115 | twilson | 2010-09-10 15:35:25 -0500 (Fri, 10 Sep 2010) | 23 lines
Merged revisions 286059 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r286059 | twilson | 2010-09-10 14:25:08 -0500 (Fri, 10 Sep 2010) | 16 lines
Inherit CHANNEL() writes to both sides of a Local channel
Having Local (/n) channels as queue members and setting the language in the
extension with Set(CHANNEL(language)=fr) sets the language on the Local/...,2
channel. Hold time report playbacks happen on the Local/...,1 channel and
therefor do not play in the specified language.
This patch modifies func_channel_write to call the setoption callback and pass
the CHANNEL() write info to the callback. chan_local uses this information to
look up the other side of the channel and apply the same changes to it.
(closes issue #17673)
Reported by: Guggemand
Review: https://reviewboard.asterisk.org/r/903/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@286190 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r281429 | jpeeler | 2010-08-09 15:43:54 -0500 (Mon, 09 Aug 2010) | 27 lines
Merged revisions 281391 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r281391 | jpeeler | 2010-08-09 15:07:29 -0500 (Mon, 09 Aug 2010) | 20 lines
Merged revisions 281390 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r281390 | jpeeler | 2010-08-09 15:04:30 -0500 (Mon, 09 Aug 2010) | 13 lines
Prevent loss of Caller ID information set on local channel after masquerade.
Caller ID set on the channel before a masquerade occurs when using a local
channel would cause the information to be lost. The problem was that the
information was set on a channel destined to be hung up. The somewhat confusing
fix is to detect if any Caller ID has been set on the channel and if so
preswap the Caller ID data so that basically the masquerade puts the data back.
(closes issue #17138)
Reported by: kobaz
Review: https://reviewboard.asterisk.org/r/847/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@281431 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r280307 | mnicholson | 2010-07-29 08:56:35 -0500 (Thu, 29 Jul 2010) | 11 lines
Merged revisions 280306 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r280306 | mnicholson | 2010-07-29 08:45:11 -0500 (Thu, 29 Jul 2010) | 2 lines
Implement support for ast_channel_queryoption on local channels. Currently only AST_OPTION_T38_STATE is supported.
ABE-2229
Review: https://reviewboard.asterisk.org/r/813/
........
Additionally, pass AST_CONTROL_T38_PARAMETERS control frames through generic bridges. This change appears to have been unintentionally left out of rev 203699.
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@280308 65c4cc65-6c06-0410-ace0-fbb531ad65f3
