* BridgeEnter now contains the unique ID of the channel that is to be swapped out, if applicable.
* There is a ParkedCallSwap event that is sent when a parked channel has a new channel take its place.
(closes issue ASTERISK-22193)
reported by Mark Michelson
Review: https://reviewboard.asterisk.org/r/2712
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396107 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch does the following:
* It moves the pickup code out of features.c and into pickup.c
* It removes the vast majority of dead code out of features.c. In particular,
this includes the parking code.
(issue ASTERISK-22134)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396060 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In working with res_stasis, I discovered a significant limitation to
the current structure of stasis_caching_topics: you cannot subscribe
to cache updates for a single channel/bridge/endpoint/etc.
To address this, this patch splits the cache away from the
stasis_caching_topic, making it a first class object. The stasis_cache
object is shared amongst individual stasis_caching_topics that are
created per channel/endpoint/etc. These are still forwarded to global
whatever_all_cached topics, so their use from most of the code does
not change.
In making these changes, I noticed that we frequently used a similar
pattern for bridges, endpoints and channels:
single_topic ----------------> all_topic
^
|
single_topic_cached ----+----> all_topic_cached
|
+----> cache
This pattern was extracted as the 'Stasis Caching Pattern', defined in
stasis_caching_pattern.h. This avoids a lot of duplicate code between
the different domain objects.
Since the cache is now disassociated from its upstream caching topics,
this also necessitated a change to how the 'guaranteed' flag worked
for retrieving from a cache. The code for handling the caching
guarantee was extracted into a 'stasis_topic_wait' function, which
works for any stasis_topic.
(closes issue ASTERISK-22002)
Review: https://reviewboard.asterisk.org/r/2672/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395954 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch renames the bridging* files to bridge*. This may seem pedantic
and silly, but it fits better in line with current Asterisk naming conventions:
* channel is not "channeling"
* monitor is not "monitoring"
etc.
A bridge is an object. It is a first class citizen in Asterisk. "Bridging" is
the act of using a bridge on a set of channels - and the API that fulfills that
role is more than just the action.
(closes issue ASTERISK-22130)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395378 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This greatly modifies the operation of DTMF attended transfers so that
the full range of options from features.conf applies.
In addition, a new option has been added that allows for a transferer
to switch between bridges during a transfer before completing the
transfer.
(closes issue ASTERISK-21543)
reported by Matt Jordan
Review: https://reviewboard.asterisk.org/r/2654
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395151 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds a new CEL event type, AST_CEL_LOCAL_OPTIMIZE, to represent
local channel optimizations. Local channel optimizations were one of
several things conveyed by the now defunct BRIDGE_UPDATE event type.
This also adds a unit test to test generation of this new CEL event.
Review: https://reviewboard.asterisk.org/r/2676/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394870 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds CEL support for blind and attended transfers and call pickup.
During the course of adding this functionality I noticed that
CONF_ENTER, CONF_EXIT, and BRIDGE_TO_CONF events are particularly
useless without a bridge identifier, so I added that as well.
This adds tests for blind transfers, several types of attended
transfers, and call pickup.
The extra field in CEL records now consists of a JSON blob whose fields
are defined on a per-event basis.
Review: https://reviewboard.asterisk.org/r/2658/
(closes issue ASTERISK-21565)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394858 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds new flags to the channel tech properties that flag it as
different types of implementation detail used exclusively to provide a
feature. Examples of channels that would have these flags include the
announcement and recording channels used by confbridge which are the
only two marked as such by this patch.
Review: https://reviewboard.asterisk.org/r/2633/
(closes issue ASTERISK-21873)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394808 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a channel is hungup, both an APP_END event and a HANGUP event can be
fired. To ensure that HANGUP events occur after APP_END events, the method
callbacks for the APP_END event should be processed prior to the callbacks
for the HANGUP event.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394530 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch does the following:
* It adds a new soft hangup flag AST_SOFTHANGUP_HANGUP_EXEC that is set when a
channel is executing dialplan hangup logic, i.e., the 'h' extension or a
hangup handler. Stasis messages now also convey the soft hangup flag so
consumers of the messages can know when a channel is executing said
hangup logic.
* It adds a new channel flag, AST_FLAG_DEAD, which is set when a channel is
well and truly dead. Not just a zombie, but dead, Jim. Manager, CEL, CDRs,
and other consumers of Stasis have been updated to look for this flag to
know when the channel should by lying six feet under.
* The CDR engine has been updated to better handle a channel entering and
leaving a bridge. Previously, a new CDR was automatically created when a
channel left a bridge and put into the 'Pending' state; however, this
way of handling CDRs made it difficult for the 'endbeforehexten' logic to
work correctly - there was always a new CDR waiting in the hangup logic
and, even if 'ended', wouldn't be the CDR people wanted to inspect in the
hangup routine. This patch completely removes the Pending state and instead
defers creation of the new CDR until it gets a new message that requires
a new CDR.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393777 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This process also involved a large amount of rework regarding how to redial
the Parker when a channel leaves a parking lot due to timeout. An attended
transfer channel variable has been added to attended transfers to extensions
that will eventually park (but haven't at the time of transfer) as well.
This resolves one of the two BUGBUG comments remaining in res_parking.
(issues ASTERISK-21877)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2638/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393704 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds several unit tests for CEL functionality and provides the
requisite framework for creating additional unit tests.
This also cleans up some reference leaks that were occurring in
Stasis-Core message callback code.
Review: https://reviewboard.asterisk.org/r/2646/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393410 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change removes AST_CEL_BRIDGE_UPDATE since it should no longer be
used because masquerade situations are now accounted for in other ways.
This also refactors usage of AST_CEL_FORWARD to be produced by a Dial
message which has been extended with a "forward" field.
(closes issue ASTERISK-21566)
Review: https://reviewboard.asterisk.org/r/2635/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392829 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch addresses the following memory/ref counting leaks:
* main/devicestate.c - unsubscribe and join our devicestate message
subscription
* main/cel.c - clean up the datastore and config objects on exist
* main/parking.c - cleanup memory leak of retriever snapshot on message
payload destruction
* res/parking/parking_bridge.c - cleanup memory leak of retrieve snapshot
on message payload destruction
* main/presencestate.c - unsubscribe and join the caching topic on exit
* manager.c - properly unregister the manager action "BlindTransfer"
* sorcery.c - shutdown the threadpool on exit and dispose of any wizards
(issue ASTERISK-21906)
Reported by: John Hardin
patches:
cel.patch uploaded by jhardin (license #6512)
devicestate.patch uploaded by jhardin (license #6512)
manager.patch uploaded by jardin (license #6512)
presencestate.patch uploaded by jhardin (license #6512)
retriever-channel-snapshot.patch uploaded by jhardin (license #6512)
sorcery.patch uploaded by jhardin (license #6512)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392797 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This finishes moving all CEL linkedid tracking entirely within cel.c
since that is now possible with channel snapshots.
This also removes another CEL linkedid manipulation function from cel.h
that has already been internalized and is neither called nor available
to link against.
Review: https://reviewboard.asterisk.org/r/2632/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392241 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch is the initial push to update Asterisk's CDR engine for the new
bridging framework. This patch guts the existing CDR engine and builds the new
on top of messages coming across Stasis. As changes in channel state and bridge
state are detected, CDRs are built and dispatched accordingly. This
fundamentally changes CDRs in a few ways.
(1) CDRs are now *very* reflective of the actual state of channels and bridges.
This means CDRs track well with what an actual channel is doing - which
is useful in transfer scenarios (which were previously difficult to pin
down). It does, however, mean that CDRs cannot be 'fooled'. Previous
behavior in Asterisk allowed for CDR applications, channels, and other
properties to be spoofed in parts of the code - this no longer works.
(2) CDRs have defined behavior in multi-party scenarios. This behavior will not
be what everyone wants, but it is a defined behavior and as such, it is
predictable.
(3) The CDR manipulation functions and applications have been overhauled. Major
changes have been made to ResetCDR and ForkCDR in particular. Many of the
options for these two applications no longer made any sense with the new
framework and the (slightly) more immutable nature of CDRs.
There are a plethora of other changes. For a full description of CDR behavior,
see the CDR specification on the Asterisk wiki.
(closes issue ASTERISK-21196)
Review: https://reviewboard.asterisk.org/r/2486/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391947 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Properly search for bridge association structures so that they are
found when expected and handle cases where they don't exist.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391777 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This pulls bridge-related CEL event triggers out of the code in which
they were residing and pulls them into cel.c where they are now
triggered by changes in bridge snapshots. To get access to the
Stasis-Core parking topic in cel.c, the Stasis-Core portions of parking
init have been pulled into core Asterisk init.
This also adds a new CEL event (AST_CEL_BRIDGE_TO_CONF) that indicates
a two-party bridge has transitioned to a multi-party conference. The
reverse cannot occur in CEL terms even though it may occur in actuality
and two party bridges which receive a AST_CEL_BRIDGE_TO_CONF will be
treated as multi-party conferences for the duration of the bridge.
Review: https://reviewboard.asterisk.org/r/2563/
(closes issue ASTERISK-21564)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391643 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This uses the channel state change events from Stasis-Core to determine
when channel-related CEL events should be raised. Those refactored in
this patch are:
* AST_CEL_CHANNEL_START
* AST_CEL_ANSWER
* AST_CEL_APP_START
* AST_CEL_APP_END
* AST_CEL_HANGUP
* AST_CEL_CHANNEL_END
Retirement of Linked IDs is also refactored.
CEL configuration has been refactored to use the config framework.
Note: Some HANGUP events are not generated correctly because the bridge
layer does not propagate hangupcause/hangupsource information yet.
Review: https://reviewboard.asterisk.org/r/2544/
(closes issue ASTERISK-21563)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391622 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Update and extend the configuration_file group and enable linking. Commit other cleanups from multi-version Doxygen testing. Update title that was left behind many years ago.
(issue ASTERISK-20259)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@375182 65c4cc65-6c06-0410-ace0-fbb531ad65f3
To fix a memory leak in CEL, a channel datastore was introduced whose
destruction function pointer was pointed to the ast_free macro. Without
MALLOC_DEBUG enabled this compiles as fine, as ast_free is defined as free.
With MALLOC_DEBUG enabled, however, ast_free takes on a definition from a
different place then utils.h, and became undefined. This patch resolves this
by using a reference to ast_free_ptr. When MALLOC_DEBUG is enabled, this
calls ast_free; when MALLOC_DEBUG is not enabled, this is defined to be
ast_free, which is defined to be free.
(issue AST-916)
Reported by: Thomas Arimont
........
Merged revisions 370273 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 370274 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370276 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A customer reported a significant memory leak using Asterisk 1.8. They
have tracked it down to ast_cel_fabricate_channel_from_event() in
main/cel.c, which is called by both in-tree CEL logging modules
(cel_custom.c and cel_sqlite3_custom.c) for each and every CEL event
that they log.
The cause was an incorrect assumption about how data attached to an
ast_channel would be handled when the channel is destroyed; the data
is now stored in a datastore attached to the channel, which is
destroyed along with the channel at the proper time.
(closes issue AST-916)
Reported by: Thomas Arimont
Review: https://reviewboard.asterisk.org/r/2053/
........
Merged revisions 370205 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 370206 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370211 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r369001 | kpfleming | 2012-06-15 10:56:08 -0500 (Fri, 15 Jun 2012) | 11 lines
Add support-level indications to many more source files.
Since we now have tools that scan through the source tree looking for files
with specific support levels, we need to ensure that every file that is
a component of a 'core' or 'extended' module (or the main Asterisk binary)
is explicitly marked with its support level. This patch adds support-level
indications to many more source files in tree, but avoids adding them to
third-party libraries that are included in the tree and to source files
that don't end up involved in Asterisk itself.
........
r369002 | kpfleming | 2012-06-15 10:57:14 -0500 (Fri, 15 Jun 2012) | 3 lines
Add a script to enable finding source files without support-levels defined.
........
Merged revisions 369001-369002 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 369005 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369013 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes to situations that could cause the CEL LINKEDID_END event to
be missed.
1) During a core stop gracefully, modules are unloaded when ast_active_channels
== 0. The LINKDEDID_END event fires during the channel destructor. This means
that occasionally, the cel_* module will be unloaded before the channel is
destroyed. It seemed generally useful to wait until the refcount of all
channels == 0 before unloading, so I added a channel counter and used it in the
shutdown code.
2) During a masquerade, ast_channel_change_linkedid is called. It calls
ast_cel_check_retire_linkedid which unrefs the linkedid in the linkedids
container in cel.c. It didn't ref the new linkedid. Now it does.
Review: https://reviewboard.asterisk.org/r/1900/
........
Merged revisions 367292 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 367299 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@367309 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
Everything still compiled after making these changes, so I assume these
whitespace-only changes didn't break anything (and shouldn't have).
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@360190 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The CEL eventtype field for ODBC and PGSQL backends should be USER_DEFINED
instead of the user defined event name supplied by the CELGenUserEvent
application. If the field is output as a number, the user defined name
does not have a value and is always output as 21 for USER_DEFINED and the
userdeftype field would be required to supply the user defined name.
The following CEL backends (cel_odbc, cel_pgsql, cel_custom, cel_manager,
and cel_sqlite3_custom) can be independently configured to remove this
inconsistency.
* Allows cel_manager, cel_custom, and cel_sqlite3_custom to behave the
same way.
(closes issue ASTERISK-17189)
Reported by: Bryant Zimmerman
Review: https://reviewboard.asterisk.org/r/1669/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@353648 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
Multiple revisions 350555,350571
........
r350555 | rmudgett | 2012-01-13 11:12:51 -0600 (Fri, 13 Jan 2012) | 12 lines
Add missing CEL logging fields to various CEL backends.
* Add missing eventextra to cel_psql.c and cel_odbc.c.
* Add missing PeerAccount and EventExtra to cel_manager.c.
* Add missing userdeftype support for cel_custom.conf.sample and
cel_sqlite3_custom.conf.sample.
(closes issue ASTERISK-17190)
Reported by: Bryant Zimmerman
........
r350571 | rmudgett | 2012-01-13 11:23:57 -0600 (Fri, 13 Jan 2012) | 8 lines
Use compatible names for event extra data for various CEL backends.
* Change eventextra to extra in cel_psql.c and cel_odbc.c.
* Change EventExtra to Extra in cel_manager.c.
(issue ASTERISK-17190)
........
Merged revisions 350555,350571 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 350585 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@350605 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/10
................
r337974 | rmudgett | 2011-09-26 14:35:23 -0500 (Mon, 26 Sep 2011) | 37 lines
Merged revisions 337973 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r337973 | rmudgett | 2011-09-26 14:30:39 -0500 (Mon, 26 Sep 2011) | 30 lines
Fix deadlock when using dummy channels.
Dummy channels created by ast_dummy_channel_alloc() should be destoyed by
ast_channel_unref(). Using ast_channel_release() needlessly grabs the
channel container lock and can cause a deadlock as a result.
* Analyzed use of ast_dummy_channel_alloc() and made use
ast_channel_unref() when done with the dummy channel. (Primary reason for
the reported deadlock.)
* Made app_dial.c:dial_exec_full() not call ast_call() holding any channel
locks. Chan_local could not perform deadlock avoidance correctly.
(Potential deadlock exposed by this issue. Secondary reason for the
reported deadlock since the held lock was part of the deadlock chain.)
* Fixed some uses of ast_dummy_channel_alloc() not checking the returned
channel pointer for failure.
* Fixed some potential chan=NULL pointer usage in func_odbc.c. Protected
by testing the bogus_chan value.
* Fixed needlessly clearing a 1024 char auto array when setting the first
char to zero is enough in manager.c:action_getvar().
(closes issue ASTERISK-18613)
Reported by: Thomas Arimont
Patches:
jira_asterisk_18613_v1.8.patch (license #5621) patch uploaded by rmudgett
Tested by: Thomas Arimont
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@337975 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r283230 | russell | 2010-08-23 08:23:12 -0500 (Mon, 23 Aug 2010) | 7 lines
Make the AST_CEL_AMA enum match up with the AST_CDR_ ama flag values.
Really, having 2 enums for this is silly and error prone, demonstrated by
the crash that I hit because there was an assumption in the code that the
values in each matched up. However, this is a quick fix to get them to
match up so it will work.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@283232 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The purpose of this patch is to eliminate struct ast_callerid since it has
turned into a miscellaneous collection of various party information.
Eliminate struct ast_callerid and replace it with the following struct
organization:
struct ast_party_name {
char *str;
int char_set;
int presentation;
unsigned char valid;
};
struct ast_party_number {
char *str;
int plan;
int presentation;
unsigned char valid;
};
struct ast_party_subaddress {
char *str;
int type;
unsigned char odd_even_indicator;
unsigned char valid;
};
struct ast_party_id {
struct ast_party_name name;
struct ast_party_number number;
struct ast_party_subaddress subaddress;
char *tag;
};
struct ast_party_dialed {
struct {
char *str;
int plan;
} number;
struct ast_party_subaddress subaddress;
int transit_network_select;
};
struct ast_party_caller {
struct ast_party_id id;
char *ani;
int ani2;
};
The new organization adds some new information as well.
* The party name and number now have their own presentation value that can
be manipulated independently. ISDN supplies the presentation value for
the name and number at different times with the possibility that they
could be different.
* The party name and number now have a valid flag. Before this change the
name or number string could be empty if the presentation were restricted.
Most channel drivers assume that the name or number is then simply not
available instead of indicating that the name or number was restricted.
* The party name now has a character set value. SIP and Q.SIG have the
ability to indicate what character set a name string is using so it could
be presented properly.
* The dialed party now has a numbering plan value that could be useful to
have available.
The various channel drivers will need to be updated to support the new
core features as needed. They have simply been converted to supply
current functionality at this time.
The following items of note were either corrected or enhanced:
* The CONNECTEDLINE() and REDIRECTING() dialplan functions were
consolidated into func_callerid.c to share party id handling code.
* CALLERPRES() is now deprecated because the name and number have their
own presentation values.
* Fixed app_alarmreceiver.c write_metadata(). The workstring[] could
contain garbage. It also can only contain the caller id number so using
ast_callerid_parse() on it is silly. There was also a typo in the
CALLERNAME if test.
* Fixed app_rpt.c using ast_callerid_parse() on the channel's caller id
number string. ast_callerid_parse() alters the given buffer which in this
case is the channel's caller id number string. Then using
ast_shrink_phone_number() could alter it even more.
* Fixed caller ID name and number memory leak in chan_usbradio.c.
* Fixed uninitialized char arrays cid_num[] and cid_name[] in
sig_analog.c.
* Protected access to a caller channel with lock in chan_sip.c.
* Clarified intent of code in app_meetme.c sla_ring_station() and
dial_trunk(). Also made save all caller ID data instead of just the name
and number strings.
* Simplified cdr.c set_one_cid(). It hand coded the ast_callerid_merge()
function.
* Corrected some weirdness with app_privacy.c's use of caller
presentation.
Review: https://reviewboard.asterisk.org/r/702/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276347 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ast_cel_report_event would geet a reference to the
bridged channel. However, certain return paths, such
as if CEL was not enabled, would result in a reference
leak. All return paths now properly unref the channel.
(closes issue #15991)
Reported by: mmichelson
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@220995 65c4cc65-6c06-0410-ace0-fbb531ad65f3
David M. Lee
Mark Michelson
Matthew Jordan
Kinsey Moore
Jonathan Rose
Richard Mudgett
Andrew Latham
Kevin P. Fleming
Terry Wilson
Russell Bryant
Michiel van Baak