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
Otherwise, it goes to all manager sessions and may exclude the current session,
if the Events mask excludes it.
(closes issue #17504)
Reported by: rrb3942
Patches:
showdialplan_patch.diff uploaded by rrb3942 (license 1003)
Tested by: rrb3942
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@273054 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Here is a cut and paste of my review request for this change:
This past weekend, Russell ran our current suite of unit tests for Asterisk
under valgrind. The PBX pattern match test caused valgrind to spew forth two
invalid read errors. This patch contains two changes that shut valgrind up and
do not cause any new memory leaks.
Change 1: In ast_context_remove_extension_callerid2, valgrind reported an
invalid read in the for loop close to the function's end. Specifically, one of
the the strcmp calls in the loop control was reading invalid memory. This was
because the caller of ast_context_remove_extension_callerid2 (__ast_context
destroy in this case) passed as a parameter a shallow copy of an ast_exten's
exten field. This same ast_exten was what was destroyed inside the for loop,
thus any iterations of the for loop beyond the destruction of the ast_exten
would result in invalid reads. My fix for this is to make a copy of the
ast_exten's exten field and pass the copy to
ast_context_remove_extension_callerid2. In addition, I have also acted
similarly with the ast_exten's matchcid field. Since in this case a NULL is
handled quite differently than an empty string, I needed to be a bit more
careful with its handling.
Change 2: In __ast_context_destroy, we iterated over a hashtab and called
ast_context_remove_extension_callerid2 on each item. Specifically, the hashtab
over which we were iterating was an ast_exten's peer_table. Inside of
ast_context_remove_extension_callerid2, we could possibly destroy this
ast_exten, which also caused the hashtab to be freed. Attempting to call
ast_hashtab_end_traversal on the hashtab iterator caused an invalid read to
occur when trying to read the iterator->tab->do_locking field since
iterator->tab had already been freed. My handling of this problem is a bit less
straightforward. With each iteration over the hashtab's contents, we set a
variable called "end_traversal" based on the return of
ast_context_remove_extension_callerid2. If 0 is ever returned, then we know
that the extension was found and destroyed. Because of this, we cannot call
ast_hashtab_end_traversal because we will be guaranteeing a read of invalid
memory. In such a case, we forego calling ast_hashtab_end_traversal and instead
call ast_free on the hashtab iterator.
Review: https://reviewboard.asterisk.org/r/585
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254362 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch removes code that was duplicated from pbx.c to manager.c
in order to prevent API change in released versions of Asterisk.
There are propably also other places that would benefit from reading the
return code and react if a function returns error codes on writing a value into it.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@242919 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Allows CDR variables added in cdr.c:set_one_cid to become visable during the call,
by executing ast_cdr_update() early in __ast_pbx run.
Reverts sig_pri changes in trunk that are specific to isdn technology only.
(closes issue #16638)
Reported by: alecdavis
Patches:
cdr_update.diff3.txt uploaded by alecdavis (license 585)
Tested by: alecdavis
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@241416 65c4cc65-6c06-0410-ace0-fbb531ad65f3
passdata was only being set in pbx_substitue_variables when arguments were
passed.
(closes issue #16406)
(closes issue #16586)
Reported by: DLNoah
Patches:
bug16586v2.patch uploaded by jpeeler (license 325)
Tested by: DLNoah
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@241366 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Specifically, by setting TESTTIME() to a particular date and time, you
can test whether a dialplan correctly branches as was intended. This was
developed after recent questions on the -users list on how to test their
holiday dialplan logic.
(closes issue #16464)
Reported by: tilghman
Patches:
20100112__issue16464.diff.txt uploaded by tilghman (license 14)
Review: https://reviewboard.asterisk.org/r/458/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@239957 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The second is the default state for matching CID in the dialplan (no matching)
while the first matches one particular CallerID. This is a regression.
(fixes AST-314, SWP-611)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@239571 65c4cc65-6c06-0410-ace0-fbb531ad65f3
During a module reload if multiple extension configs are present,
such as both extensions.conf and extensions.ael, watchers for one
config's hints will be lost during the merging of the other config.
This happens because hint watchers are only preserved for the
current config being merged. The old context list is destroyed
after the merging takes place, meaning any watchers that were not
perserved will be removed.
Now all hints are preserved during merging regardless of what config
file is being merged. These hints are only restored if they
are present within the new context list.
(closes issue #16093)
Reported by: jlaroff
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@237839 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r237405 | tilghman | 2010-01-04 12:19:00 -0600 (Mon, 04 Jan 2010) | 16 lines
Add a flag to disable the Background behavior, for AGI users.
This is in a section of code that relates to two other issues, namely
issue #14011 and issue #14940), one of which was the behavior of
Background when called with a context argument that matched the current
context. This fix broke FreePBX, however, in a post-Dial situation.
Needless to say, this is an extremely difficult collision of several
different issues. While the use of an exception flag is ugly, fixing all
of the issues linked is rather difficult (although if someone would like
to propose a better solution, we're happy to entertain that suggestion).
(closes issue #16434)
Reported by: rickead2000
Patches:
20091217__issue16434.diff.txt uploaded by tilghman (license 14)
20091222__issue16434__1.6.1.diff.txt uploaded by tilghman (license 14)
Tested by: rickead2000
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@237406 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r235421 | tilghman | 2009-12-17 11:17:51 -0600 (Thu, 17 Dec 2009) | 8 lines
Use context from which Macro is executed, not macro context, if applicable.
Also, ensure that the extension COULD match, not just that it won't match more.
(closes issue #16113)
Reported by: OrNix
Patches:
20091216__issue16113.diff.txt uploaded by tilghman (license 14)
Tested by: OrNix
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@235422 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r229360 | tilghman | 2009-11-10 16:09:16 -0600 (Tue, 10 Nov 2009) | 12 lines
If two pattern classes start with the same digit and have the same number of characters, they will compare equal.
The example given in the issue report is that of [234] and [246], which have
these characteristics, yet they are clearly not equivalent. The code still
uses these two characteristics, yet when the two scores compare equal, an
additional check will be done to compare all characters within the class to
verify equality.
(closes issue #15421)
Reported by: jsmith
Patches:
20091109__issue15421__2.diff.txt uploaded by tilghman (license 14)
Tested by: jsmith, thedavidfactor
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@229361 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Two examples of its use are included, and the usage could be expanded in some
cases into certain configuration options where time periods are specified.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@224225 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Channels are stored in an ao2_container. When accessing an item within
an ao2_container the proper locking order is to first lock the container,
and then the items within it.
In ast_do_masquerade both the clone and original channel must be locked
for the entire duration of the function. The problem with this is that
it attemptes to unlink and link these channels back into the ao2_container
when one of the channel's name changes. This is invalid locking order as
the process of unlinking and linking will lock the ao2_container while
the channels are locked!!! Now, both the channels in do_masquerade are
unlinked from the ao2_container and then locked for the entire function.
At the end of the function both channels are unlocked and linked back
into the container with their new names as hash values.
This new method of requiring all channels and tech pvts to be unlocked
before ast_do_masquerade() or ast_change_name() required several
changes throughout the code base.
(closes issue #15911)
Reported by: russell
Patches:
masq_deadlock_trunk.diff uploaded by dvossel (license 671)
Tested by: dvossel, atis
(closes issue #15618)
Reported by: lmsteffan
Patches:
deadlock_local_attended_transfers_trunk.diff uploaded by dvossel (license 671)
Tested by: lmsteffan, dvossel
Review: https://reviewboard.asterisk.org/r/387/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@222761 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r218867 | dbrooks | 2009-09-16 13:00:45 -0500 (Wed, 16 Sep 2009) | 13 lines
Fixes CID pattern matching behavior to mirror that of extension pattern matching.
Pattern matching for extensions uses a type of scoring system, giving values for
specificity to each character in the pattern. Unfortunately, this is done character
by character, in order. This does lead to some less specific patterns being first
in line for matching, but it will usually get the job done.
This patch merely brings CID matching to the same level as extension matching.
This patch does not attempt to tackle the problem shared by extension matching.
(closes issue #14708)
Reported by: klaus3000
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@218868 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r216430 | oej | 2009-09-04 15:45:48 +0200 (Fre, 04 Sep 2009) | 27 lines
Make apps send PROGRESS control frame for early media and fix too early media issue in SIP
The issue at hand is that some legacy (dying) PBX systems send empty media frames on PRI
links *before* any call progress. The SIP channel receives these frames and by default
signals 183 Session progress and starts sending media. This will cause phones to
play silence and ignore the later 180 ringing message. A bad user experience.
The fix is twofold:
- We discovered that asterisk apps that support early media ("noanswer") did not send
any PROGRESS frame to indicate early media. Fixed.
- We introduce a setting in chan_sip so that users can disable any relay of media frames
before the outbound channel actually indicates any sort of call progress.
In 1.4, 1.6.0 and 1.6.1, this will be disabled for backward compatibility. In later versions
of Asterisk, this will be enabled. We don't assume that it will change your Asterisk
phone experience - only for the better.
We encourage third-party application developers to make sure that if they have applications
that wants to send early media, add a PROGRESS control frame transmission to make sure that
all channel drivers actually will start sending early media. This has not been the default
in Asterisk previous to this patch, so if you got inspiration from our code, you need to
update accordingly. Sorry for the trouble and thanks for your support.
This code has been running for a few months in a large scale installation (over 250
servers with PRI and/or BRI links to old PBX systems).
That's no proof that this is an excellent patch, but, well, it's tested :-)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@216438 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r204681 | dvossel | 2009-07-02 10:05:57 -0500 (Thu, 02 Jul 2009) | 14 lines
Improved mapping of extension states from combined device states.
This fixes a few issues with incorrect extension states and adds
a cli command, core show device2extenstate, to display all possible
state mappings.
(closes issue #15413)
Reported by: legart
Patches:
exten_helper.diff uploaded by dvossel (license 671)
Tested by: dvossel, legart, amilcar
Review: https://reviewboard.asterisk.org/r/301/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@204710 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
In the definition of new_find_extension(), the arguments 'callerid' and
'label' were swapped. The prototype declaration and all calls to the
function are ordered 'callerid' then 'label', but the function itself
was ordered 'label' then 'callerid'.
(closes issue #15303)
Reported by: JimDickenson
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@199957 65c4cc65-6c06-0410-ace0-fbb531ad65f3
'channel originate ... application <app>' CLI command.
(And yeah, I cleaned up some whitespace in res_clioriginate.c... big whoop,
wanna fight about it!?)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@196758 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A new xml element was created to manage the AMI actions documentation,
using AstXML.
To register a manager action using XML documentation it is now possible
using ast_manager_register_xml().
The CLI command 'manager show command' can be used to show the parsed
documentation.
Example manager xml documentation:
<manager name="ami action name" language="en_US">
<synopsis>
AMI action synopsis.
</synopsis>
<syntax>
<xi:include xpointer="xpointer(...)" /> <-- for ActionID
<parameter name="header1" required="true">
<para>Description</para>
</parameter>
...
</syntax>
<description>
<para>AMI action description</para>
</description>
<see-also>
...
</see-also>
</manager>
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@196308 65c4cc65-6c06-0410-ace0-fbb531ad65f3
