ACLs can now be configured to match IPv6 networks. This is only
relevant for ACLs in chan_sip for now since other channel drivers
do not support IPv6 addressing. However, once those channel drivers
are outfitted to support IPv6 addressing, the ACLs will already be
ready for IPv6 support.
https://reviewboard.asterisk.org/r/791
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@277814 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
This adds a generic API for accommodating IPv6 and IPv4 addresses
within Asterisk. While many files have been updated to make use of the
API, chan_sip and the RTP code are the files which actually support
IPv6 addresses at the time of this commit. The way has been paved for
easier upgrading for other files in the near future, though.
Big thanks go to Simon Perrault, Marc Blanchet, and Jean-Philippe Dionne
for their hard work on this.
(closes issue #17565)
Reported by: russell
Patches:
asteriskv6-test-report.pdf uploaded by russell (license 2)
Review: https://reviewboard.asterisk.org/r/743
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@274783 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The external test suite stops Asterisk using the "core stop gracefully" command.
The logs from the tests show that there are a number of problems with Asterisk
trying to cleanly shut down. This patch addresses the following type of error
that comes from chan_iax2:
[Jun 22 16:58:11] ERROR[29884]: lock.c:129 __ast_pthread_mutex_destroy:
chan_iax2.c line 11371 (iax2_process_thread_cleanup):
Error destroying mutex &thread->lock: Device or resource busy
For an example in the context of a build, see:
http://bamboo.asterisk.org/browse/AST-TRUNK-739/log
The primary purpose of this patch is to change the thread pool shutdown
procedure to be more explicit to ensure that the thread exits from a point
where it is not holding a lock. While testing that, I encountered various
crashes due to the order of operations in unload_module() being problematic.
I reordered some things there, as well.
Review: https://reviewboard.asterisk.org/r/736/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272370 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r270866 | dvossel | 2010-06-16 12:35:29 -0500 (Wed, 16 Jun 2010) | 22 lines
fixes chan_iax2 race condition
There is code in chan_iax2.c that attempts to guarantee that only a single
active thread will handle a call number at a time. This code works once
the thread is added to an active_list of threads, but we are not currently
guaranteed that a newly activated thread will enter the active_list immediately
because it is left up to the thread to add itself after frames have been
queued to it. This means that if two frames come in for the same call number
at the same time, it is possible for them to grab two separate threads because
the first thread did not add itself to the active_list fast enough. This
causes some pretty complex problems.
This patch resolves this race condition by immediately adding an activated
thread to the active_list within the network thread and only depending on
the thread to remove itself once it is done processing the frames queued to
it. By doing this we are guaranteed that if another frame for the same call
number comes in at the same time, that this thread will immediately be found
in the active_list of threads.
Review: https://reviewboard.asterisk.org/r/720/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@270867 65c4cc65-6c06-0410-ace0-fbb531ad65f3
After 5 years in mantis and over a year on reviewboard, SRTP support is finally
being comitted. This includes generic CHANNEL dialplan functions that work for
getting the status of whether a call has secure media or signaling as defined
by the underlying channel technology and for setting whether or not a new
channel being bridged to a calling channel should have secure signaling or
media. See doc/tex/secure-calls.tex for examples.
Original patch by mikma, updated for trunk and revised by me.
(closes issue #5413)
Reported by: mikma
Tested by: twilson, notthematrix, hemanshurpatel
Review: https://reviewboard.asterisk.org/r/191/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@268894 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Very unfortunate things happen if we add an iax_frame
to the frame queue and let go of the lock before scheduling
the frame's transmit... There is a race condition that
exists where the frame can be removed from the frame_queue
and freed before the transmit is scheduled if we do not
hold on to that lock. This results in a freed frame
being scheduled for transmit later.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263151 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r250394 | dvossel | 2010-03-03 12:02:27 -0600 (Wed, 03 Mar 2010) | 16 lines
fixes problem with duplicate TXREQ packets
When Asterisk receives an IAX2 TXREQ packet, try_transfer()
will call store_by_transfercallno() to link the chan_iax2_pvt
struct into iax_transfercallno_pvts. If a duplicate TXREQ
packet is received for the same call, the pvt struct will be
linked into iax_transfercallno_pvts multiple times. This patch
fixes this. Thanks rain for debugging this and providing a patch!
(closes issue #16904)
Reported by: rain
Patches:
iax2-double-txreq-fix.diff uploaded by rain (license 327)
Tested by: rain, dvossel
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@250395 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r245792 | dvossel | 2010-02-09 16:55:38 -0600 (Tue, 09 Feb 2010) | 12 lines
Fixes iaxs and iaxsl size off by one issue.
2^15 = 32768 which is the maximum allowed iax2 callnumber.
Creating the iaxs and iaxsl array of size 32768 means the maximum
callnumber is actually out of bounds. This causes a nasty crash.
(closes issue #15997)
Reported by: exarv
Patches:
iax_fix.diff uploaded by dvossel (license 671)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@245793 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When this patch was originally submitted, the code allowed for the token to be
set via a channel variable. I decided that a cleaner approach would be to
integrate it into the CHANNEL() function. Unfortunately, that is not a suitable
approach. It's not possible to get the value set on the channel soon enough
using that method. So, go back to the simple channel variable method.
(closes issue #16711)
Reported by: homesick
Patches:
iax-svn.diff uploaded by homesick (license 91)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@243482 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Fixes a crash on Solaris.
(closes issue #16572)
Reported by: crjw
Patches:
frame_changes.patch uploaded by crjw (license 963)
Plus several others found and fixed by me
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@239074 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r238411 | dvossel | 2010-01-07 14:14:25 -0600 (Thu, 07 Jan 2010) | 10 lines
fixes crash in "scheduled_destroy" in chan_iax
A signed short was used to represent a callnumber. This is makes
it possible to attempt to access the iaxs array with a negative
index.
(closes issue #16565)
Reported by: jensvb
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@238412 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r230246 | kpfleming | 2009-11-15 11:19:06 -0600 (Sun, 15 Nov 2009) | 6 lines
Correct mistaken option name in error message.
The configuration option for allowing hosts to make non-token-based calls
is 'calltokenoptional', not 'calltokenignore'. (reported on asterisk-users)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@230247 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r225243 | dvossel | 2009-10-21 15:58:08 -0500 (Wed, 21 Oct 2009) | 13 lines
IAX2: VNAK loop caused by signaling frames with no destination call number
It is possible for the PBX thread to queue up signaling frames before
a destination call number is received. This can result in signaling
frames being sent out with no destination call number. Since recent
versions of Asterisk require accurate destination callnumbers for all
Full Frames, this can cause a VNAK loop to occur. To resolve this
no signaling frames are sent until a destination callnumber is received,
and destination call numbers are now only required for iax_pvt matching
when the frame is an ACK.
Review: https://reviewboard.asterisk.org/r/413/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@225307 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r225032 | dvossel | 2009-10-21 09:37:04 -0500 (Wed, 21 Oct 2009) | 20 lines
IAX/SIP shrinkcallerid option
The shrinking of caller id removes '(', ' ', ')', non-trailing '.',
and '-' from the string. This means values such as 555.5555 and
test-test result in 555555 and testtest. There are instances,
such as Skype integration, where a specific value is passed via
caller id that must be preserved unmodified. This patch makes
the shrinking of caller id optional in chan_sip and chan_iax in
order to support such cases. By default this option is on to
preserve previous expected behavior.
(closes issue #15940)
Reported by: dimas
Patches:
v2-15940.patch uploaded by dimas (license 88)
15940_shrinkcallerid_trunk.c uploaded by dvossel (license 671)
Tested by: dvossel
Review: https://reviewboard.asterisk.org/r/408/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@225033 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r222152 | kpfleming | 2009-10-05 20:16:36 -0500 (Mon, 05 Oct 2009) | 20 lines
Fix ao2_iterator API to hold references to containers being iterated.
See Mantis issue for details of what prompted this change.
Additional notes:
This patch changes the ao2_iterator API in two ways: F_AO2I_DONTLOCK
has become an enum instead of a macro, with a name that fits our
naming policy; also, it is now necessary to call
ao2_iterator_destroy() on any iterator that has been
created. Currently this only releases the reference to the container
being iterated, but in the future this could also release other
resources used by the iterator, if the iterator implementation changes
to use additional resources.
(closes issue #15987)
Reported by: kpfleming
Review: https://reviewboard.asterisk.org/r/383/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@222176 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r219519 | dvossel | 2009-09-18 18:19:50 -0500 (Fri, 18 Sep 2009) | 9 lines
iax2 frame double free
The iax frame's retrans sched id was written over right
before iax2_frame_free was called. In iax2_frame_free that
retrans id is used to delete the sched item. By writing over
the retrans field before the sched item could be deleted, it was
possible for a retransmit to occur on a freed frame.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@219520 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In the course of this, I also found that the results of ast_gethostbyname
were being used incorrectly in both chan_iax2 and chan_sip, so both have
been fixed.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@217916 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Brett Bryant
Tilghman Lesher
David Vossel
Paul Belanger
Terry Wilson
Mark Michelson
Richard Mudgett
Eliel C. Sardanons
Tzafrir Cohen
Russell Bryant
Leif Madsen
Kevin P. Fleming