https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r119238 | russell | 2008-05-30 07:55:36 -0500 (Fri, 30 May 2008) | 15 lines
Merged revisions 119237 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r119237 | russell | 2008-05-30 07:49:39 -0500 (Fri, 30 May 2008) | 7 lines
- Instead of only enforcing destination call number checking on an ACK, check
all full frames except for PING and LAGRQ, which may be sent by older versions
too quickly to contain the destination call number.
(As suggested by Tim Panton on the asterisk-dev list)
- Merge changes from team/russell/iax2-frame-race, which prevents PING and LAGRQ
from being sent before the destination call number is known.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@119239 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
........
r116978 | russell | 2008-05-18 22:44:04 -0500 (Sun, 18 May 2008) | 4 lines
Avoid access of uninitialized memory. This caused a bunch of crashes for me
while doing load testing of development branch where I'm working on some
performance improvements.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@116979 65c4cc65-6c06-0410-ace0-fbb531ad65f3
marked "urgent" are considered to be higher priority than other messages
and so they will be played before any other messages in a user's mailbox.
There are two ways to leave an urgent message.
1. send the 'U' option to VoiceMail().
2. Set review=yes in voicemail.conf. This will give instructions for
a caller to mark a message as urgent after the message has been recorded.
I have tested that this works correctly with file and ODBC storage, and James
Rothenberger (who wrote initial support for this feature) has tested its use
with IMAP storage.
(closes issue #11817)
Reported by: jaroth
Based on branch http://svn.digium.com/svn/asterisk/team/jrothenberger/asterisk-urgent
Tested by: putnopvut, jaroth
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@115588 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r115565 | russell | 2008-05-08 14:15:25 -0500 (Thu, 08 May 2008) | 33 lines
Merged revisions 115564 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r115564 | russell | 2008-05-08 14:14:04 -0500 (Thu, 08 May 2008) | 25 lines
Fix a race condition that bbryant just found while doing some IAX2 testing.
He was running Asterisk trunk running IAX2 calls through a few Asterisk boxes,
however, the audio was extremely choppy. We looked at a packet trace and saw
a storm of INVAL and VNAK frames being sent from one box to another.
It turned out that what had happened was that one box tried to send a CONTROL
frame before the 3 way handshake had completed. So, that frame did not include
the destination call number, because it didn't have it yet. Part of our recent
work for security issues included an additional check to ensure that frames that
are supposed to include the destination call number have the correct one. This
caused the frame to be rejected with an INVAL. The frame would get retransmitted
for forever, rejected every time ...
This race condition exists in all versions that got the security changes,
in theory. However, it is really only likely that this would cause a problem in
Asterisk trunk. There was a control frame being sent (SRCUPDATE) at the _very_
beginning of the call, which does not exist in 1.2 or 1.4. However, I am fixing
all versions that could potentially be affected by the introduced race condition.
These changes are what bbryant and I came up with to fix the issue. Instead of
simply dropping control frames that get sent before the handshake is complete,
the code attempts to wait a little while, since in most cases, the handshake
will complete very quickly. If it doesn't complete after yielding for a little
while, then the frame gets dropped.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@115566 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r114891 | russell | 2008-04-30 11:30:01 -0500 (Wed, 30 Apr 2008) | 28 lines
Merge changes from team/russell/iax2_find_callno and iax2_find_callno_1.4
These changes address a critical performance issue introduced in the latest
release. The fix for the latest security issue included a change that made
Asterisk randomly choose call numbers to make them more difficult to guess by
attackers. However, due to some inefficient (this is by far, an understatement)
code, when Asterisk chose high call numbers, chan_iax2 became unusable after
just a small number of calls. On a small embedded platform, it would not be
able to handle a single call. On my Intel Core 2 Duo @ 2.33 GHz, I couldn't
run more than about 16 IAX2 channels. Ouch.
These changes address some performance issues of the find_callno() function
that have bothered me for a very long time. On every incoming media frame,
it iterated through every possible call number trying to find a matching
active call. This involved a mutex lock and unlock for each call number
checked. So, if the random call number chosen was 20000, then every media
frame would cause 20000 locks and unlocks. Previously, this problem was
not as obvious since Asterisk always chose the lowest call number it could.
A second container for IAX2 pvt structs has been added. It is an astobj2
hash table. When we know the remote side's call number, the pvt goes into
the hash table with a hash value of the remote side's call number. Then,
lookups for incoming media frames are a very fast hash lookup instead of an
absolutely insane array traversal.
In a quick test, I was able to get more than 3600% more IAX2 channels
on my machine with these changes.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@114892 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r114880 | kpfleming | 2008-04-30 09:46:57 -0500 (Wed, 30 Apr 2008) | 2 lines
use the ARRAY_LEN macro for indexing through the iaxs/iaxsl arrays so that the size of the arrays can be adjusted in one place, and change the size of the arrays from 32768 calls to 2048 calls when LOW_MEMORY is defined
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@114884 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r114537 | russell | 2008-04-22 13:03:33 -0500 (Tue, 22 Apr 2008) | 9 lines
If the dial string passed to the call channel callback does not indicate an
extension, then consider the extension on the channel before falling back
to the default.
(closes issue #12479)
Reported by: darren1713
Patches:
exten_dial_fix_chan_iax2.c.patch uploaded by darren1713 (license 116)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@114538 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: oej
Tested by: jpeeler
This patch implements multiple parking lots for parked calls. The default parkinglot is used by default, however setting the channel variable PARKINGLOT in the dialplan will allow use of any other configured parkinglot. See configs/features.conf.sample for more details on setting up another non-default parkinglot. Also, one can (currently) set the default parkinglot to use in the driver configuration file via the parkinglot option.
Patch initially written by oej, brought up to date and finalized by mvanbaak, and then stabilized and converted to astobj2 by me.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@114487 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r114083 | twilson | 2008-04-11 17:32:51 -0500 (Fri, 11 Apr 2008) | 7 lines
Several places in the code called find_callno() (which releases the lock on the pvt structure) and then immediately locked the call and did things with it. Unfortunately, the call can disappear between the find_callno and the lock, causing Bad Stuff(tm) to happen.
Added find_callno_locked() function to return the callno withtout unlocking for instances that it is needed.
(issue #12400)
Reported by: ztel
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@114084 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r113784 | file | 2008-04-09 13:50:45 -0300 (Wed, 09 Apr 2008) | 4 lines
If we receive an AUTHREQ from the remote server and we are unable to reply (for example they have a secret configured, but we do not) then queue a hangup frame on the Asterisk channel. This will cause the channel to hangup and a HANGUP to be sent via IAX2 to the remote side which is the proper thing to do in this scenario.
(closes issue #12385)
Reported by: viraptor
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@113785 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r110628 | file | 2008-03-25 11:37:35 -0300 (Tue, 25 Mar 2008) | 4 lines
Add an option (transmit_silence) which transmits silence during both Record() and DTMF generation. The reason this is an option is that in order to transmit silence we have to setup a translation path. This may not be needed/wanted in all cases.
(closes issue #10058)
Reported by: tracinet
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@111017 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r110336 | russell | 2008-03-20 16:54:58 -0500 (Thu, 20 Mar 2008) | 14 lines
Merged revisions 110335 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r110335 | russell | 2008-03-20 16:53:27 -0500 (Thu, 20 Mar 2008) | 6 lines
Fix some very broken code that was introduced in 1.2.26 as a part of the security
fix. The dnsmgr is not appropriate here. The dnsmgr takes a pointer to an address
structure that a background thread continuously updates. However, in these cases,
a stack variable was passed. That means that the dnsmgr thread would be continuously
writing to bogus memory.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@110337 65c4cc65-6c06-0410-ace0-fbb531ad65f3
actual problems, per se. I also added format attributes to any printf wrapper functions I found that didn't have them. -Wsecurity and -Wmissing-format-attribute added to --enable-dev-mode.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109447 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: rizzo
Tested by: murf
Proposal of the changes to be made, and then an announcement of how they were accomplished:
http://lists.digium.com/pipermail/asterisk-dev/2008-February/032065.html
and:
http://lists.digium.com/pipermail/asterisk-dev/2008-March/032124.html
Here is a recap, file by file, of what I have done:
pbx/pbx_config.c
pbx/pbx_ael.c
All funcs that were passed a ptr to the context list, now will ALSO be passed a hashtab ptr to the same set.
Why? because (for the time being), the dialplan is stored in both, to facilitate a quick, low-cost move to
hash-tables to speed up dialplan processing. If it was deemed necessary to pass the context LIST, well, it
is just as necessary to have the TABLE available. This is because the list/table in question might not be
the global one, but temporary ones we would use to stage the dialplan on, and then swap into the global
position when things are ready.
We now have one external function for apps to use, "ast_context_find_or_create()" instead of the pre-existing
"find" and "create", as all existing usages used both in tandem anyway.
pbx_config, and pbx_ael, will stage the reloaded dialplan into local lists and tables, and
then call merge_contexts_and_delete, which will merge (now) existing contexts and
priorities from other registrars into this local set by copying them. Then, merge_contexts_and_delete will
lock down the contexts, swap the lists and tables, and unlock (real quick), and then
destroy the old dialplan.
chan_sip.c
chan_iax.c
chan_skinny.c
All the channel drivers that would add regcontexts now use the ast_context_find_or_create now.
chan_sip also includes a small fix to get rid of warnings about removing priorities that never got entered.
apps/app_meetme.c
apps/app_dial.c
apps/app_queue.c
All the apps that added a context/exten/priority were also modified to use ast_context_find_or_create instead.
include/asterisk/pbx.h
ast_context_create() is removed. Find_or_create_ is the new method.
ast_context_find_or_create() interface gets the hashtab added.
ast_merge_contexts_and_delete() gets the local hashtab arg added.
ast_wrlock_contexts_version() is added so you can detect if someone else got a writelock between your readlocking and writelocking.
ast_hashtab_compare_contexts was made public for use in pbx_config/pbx_ael
ast_hashtab_hash_contexts was in like fashion make public.
include/asterisk/pval.h
ast_compile_ael2() interface changed to include the local hashtab table ptr.
main/features.c
For the sake of the parking context, we use ast_context_find_or_create().
main/pbx.c
I changed all the "tree" names to "table" instead. That's because the original
implementation was based on binary trees. (had a free library). Then I moved
to hashtabs. Now, the names move forward too.
refcount field added to contexts, so you can keep track of how many modules
wanted this context to exist.
Some log messages that are warnings were inflated from LOG_NOTICE to LOG_WARNING.
Added some calls to ast_verb(3,...) for debug messages
Lots of little mods to ast_context_remove_extension2, which is now excersized in ways
it was not previously; one definite bug fixed.
find_or_create was upgraded to handle both local lists/tables as well as the globals.
context_merge() was added to do the per-context merging of the old/present contexts/extens/prios into the new/proposed local list/tables
ast_merge_contexts_and_delete() was heavily modified.
ast_add_extension2() was also upgraded to handle changes.
the context_destroy() code was re-engineered to handle the new way of doing things,
by exten/prio instead of by context.
res/ael/pval.c
res/ael/ael.tab.c
res/ael/ael.tab.h
res/ael/ael.y
res/ael/ael_lex.c
res/ael/ael.flex
utils/ael_main.c
utils/extconf.c
utils/conf2ael.c
utils/Makefile
Had to change the interface to ast_compile_ael2(), to include the hashtab ptr.
This ended up involving several external apps. The main gotcha was I had to
include lock.h and hashtab.h in several places.
As a side note, I tested this stuff pretty thoroughly, I replicated the problems
originally reported by Luigi, and made triply sure that reloads worked, and everything
worked thru "stop gracefully". I found a and fixed a few bugs as I was merging into
trunk, that did not appear in my tests of bug6002.
How's this for verbose commit messages?
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@106757 65c4cc65-6c06-0410-ace0-fbb531ad65f3
(closes issue #8925)
About a year ago, as Leif Madsen and Jim van Meggelen were going over the CLI
commands in Asterisk 1.4 for the next version of their book, they documented
a lot of inconsistencies. This set of changes addresses all of these issues
and has been reviewed by Leif.
While this does introduce even more changes to the CLI command structure, it
makes everything consistent, which is the most important thing.
Thanks to all that helped with this one!
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103171 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r101693 | russell | 2008-01-31 18:32:49 -0600 (Thu, 31 Jan 2008) | 8 lines
Add some more sanity checking on IAX2 dial strings for the case that no peer
or hostname was provided, which is the one part of the dial string that is
absolutely required. If it's not there, bail out.
(closes issue #11897)
Reported by sokhapkin
Patch by me
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@101694 65c4cc65-6c06-0410-ace0-fbb531ad65f3
that was just merged from 1.4, so this is a changeover to those APIs to use the
macro versions, so that we properly detect errors from ast_sched_del, instead
of simply ignoring the return values.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@100497 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r100465 | tilghman | 2008-01-27 15:59:53 -0600 (Sun, 27 Jan 2008) | 11 lines
When deleting a task from the scheduler, ignoring the return value could
possibly cause memory to be accessed after it is freed, which causes all
sorts of random memory corruption. Instead, if a deletion fails, wait a
bit and try again (noting that another thread could change our taskid
value).
(closes issue #11386)
Reported by: flujan
Patches:
20080124__bug11386.diff.txt uploaded by Corydon76 (license 14)
Tested by: Corydon76, flujan, stuarth`
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@100488 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r99004 | russell | 2008-01-17 16:37:22 -0600 (Thu, 17 Jan 2008) | 10 lines
Have IAX2 optimize the codec translation path just like chan_sip does it. If
the caller's codec is in our codec list, move it to the top to avoid transcoding.
(closes issue #10500)
Reported by: stevedavies
Patches:
iax-prefer-current-codec.patch uploaded by stevedavies (license 184)
iax-prefer-current-codec.1.4.patch uploaded by stevedavies (license 184)
Tested by: stevedavies, pj, sheldonh
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@99006 65c4cc65-6c06-0410-ace0-fbb531ad65f3