channel list calling a caller-defined callback. The callback returns non-zero
if a match is found. This should speed up some of the code that I committed
earlier today in chan_sip (which is also updated by this commit).
Reviewed by russellb and kpfleming via ReviewBoard:
http://reviewboard.digium.com/r/28/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@154429 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit introduces the first phase of an effort to manage documentation of the
interfaces in Asterisk in an XML format. Currently, a new format is available for
applications and dialplan functions. A good number of conversions to the new format
are also included.
For more information, see the following message to asterisk-dev:
http://lists.digium.com/pipermail/asterisk-dev/2008-October/034968.html
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@153365 65c4cc65-6c06-0410-ace0-fbb531ad65f3
had no effect
* Updated dialing API documentation to indicate that timeouts
are specified in milliseconds
* Added a new timeout argument to the Page application. If time
expires, any endpoints which have not answered will be hung up.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@153223 65c4cc65-6c06-0410-ace0-fbb531ad65f3
the low default value of featuredigittimeout, I decided it
was high time to change it. I have changed the default to
2000 ms based on a suggestion from Leif Madsen.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@152807 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r152535 | murf | 2008-10-28 22:36:32 -0600 (Tue, 28 Oct 2008) | 46 lines
The magic trick to avoid this crash is not to
try to find the channel by name in the list,
which is slow and resource consuming, but rather
to pay attention to the result codes from the
ast_bridge_call, to which I added the
AST_PBX_NO_HANGUP_PEER_PARKED value, which
now are returned when a channel is parked.
Why? because CDR's aren't generated via parking,
so nothing is needed, but if a transfer occurred,
there are critical things I need.
If you get AST_PBX_KEEPALIVE,
then don't touch the channel pointer.
If you get AST_PBX_NO_HANGUP_PEER, or
AST_PBX_NO_HANGUP_PEER_PARKED, then don't
touch the peer pointer.
Updated the several places where the results
from a bridge were not being properly obeyed,
and fixed some code I had introduced so that
the results of the bridge were not overridden
(in trunk).
All the places that previously tested for
AST_PBX_NO_HANGUP_PEER now have to check for
both AST_PBX_NO_HANGUP_PEER and AST_PBX_NO_HANGUP_PEER_PARKED.
I tested this against the 4 common parking
scenarios:
1. A calls B; B answers; A parks B; B hangs up while A is getting the parking
slot announcement, immediately after being put on hold.
2. A calls B; B answers; A parks B; B hangs up after A has been hung up, but
before the park times out.
3. A calls B; B answers; B parks A; A hangs up while B is getting the parking slot announcement, immediately after being put on hold.
4. A calls B; B answers; B parks A; A hangs up after B has been hung up, but before the park times out.
No crash.
I also ran the scenarios above against valgrind, and accesses looked good.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@152536 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r151905 | russell | 2008-10-25 05:59:02 -0500 (Sat, 25 Oct 2008) | 8 lines
Move AMI initialization to occur after loading modules. This prevents a
deadlock when someone tries to initiate a module reload from the AMI just
as Asterisk is starting.
(closes issue #13778)
Reported by: hotsblanc
Fix suggested by hotsblanc
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@151906 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1) rename 'struct server_args' to 'struct ast_tcptls_session_args', to follow coding guidelines
2) make ast_make_file_from_fd() static and rename it to something that indicates what it really is for (again coding guidelines)
3) rename address variables inside 'struct ast_tcptls_session_args' to be more descriptive (dare i say it... coding guidelines)
4) change ast_tcptls_client_start() to use the new 'remote_address' field of the session args for the destination of the connection, and use the 'local_address' field to bind() the socket to the proper source address, if one is supplied
5) in chan_sip, ensure that we pass in the PP address we are bound to when creating outbound (client) connections, so that our connections will appear from the correct address
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@151101 65c4cc65-6c06-0410-ace0-fbb531ad65f3
We'll create a bogus channel for the function call and destroy it when we're done. If we have trouble allocating the bogus channel then we're not going to try executing the function call at all and run the risk of crashing.
(closes issue #13715)
reported by: makoto
patch by: bweschke
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@150817 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prodded on IRC by Russell and fixed by eliel
(closes issue #13730)
Reported by: eliel
Patches:
main_cli.patch uploaded by eliel (license 64)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@150664 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r150304 | mmichelson | 2008-10-16 18:40:54 -0500 (Thu, 16 Oct 2008) | 6 lines
Reverting changes from commits 150298 and 150301 since
I was mistakenly under the assumption that dialplan functions
*always* required that a channel be present. I need to go
home earlier, I think :)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@150305 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r150298 | mmichelson | 2008-10-16 18:34:37 -0500 (Thu, 16 Oct 2008) | 10 lines
Don't try to call a dialplan function's read callback from
the manager's GetVar handler if an invalid channel has
been specified. Several dialplan functions, including
CHANNEL and SIP_HEADER, do not check for NULL-ness of
the channel being passed in.
(closes issue #13715)
Reported by: makoto
........
r150301 | mmichelson | 2008-10-16 18:35:07 -0500 (Thu, 16 Oct 2008) | 3 lines
And don't forget to return on the error condition
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@150302 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r149204 | mmichelson | 2008-10-14 18:00:01 -0500 (Tue, 14 Oct 2008) | 12 lines
Add a tolerance period for sync-triggered audiohooks
so that if packetization of audio is close (but not equal)
we don't end up flushing the audiohooks over small
inconsistencies in synchronization.
Related to issue #13005, and solves the issue
for most people who were experiencing the problem.
However, a small number of people are still experiencing
the problem on long calls, so I am not closing
the issue yet
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@149205 65c4cc65-6c06-0410-ace0-fbb531ad65f3
'update2', which permits updates which match across multiple columns, instead
of requiring all tables to have a single unique identifier. All of the other
API calls with the exception of 'update' already had the ability to match on
multiple fields, so it was a missing and very desireable feature that an API
call implementing an update should have this, too.
This does not change any outward performance of Asterisk, but it should make
life easier for application developers who use the RealTime framework.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@148570 65c4cc65-6c06-0410-ace0-fbb531ad65f3
the trie info when they do 'dialplan show ...'
(even with debug set to non-zero); so I set up a
'dialplan debug [context]' cli command instead,
to explicitly show just the trie info. I even
added an extension_exists() call to make sure the
trie info is built. I moved the explanatory header
to above the extension loop to ensure it only prints
once. And it will do this now, whether debug is set
or not.
I removed the trie printing from the 'dialplan show'
command entirely.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@148519 65c4cc65-6c06-0410-ace0-fbb531ad65f3
app_voicemail. Instead, include it where it is needed. This turned out to be a
relatively minor issue because other headers include logger.h as well.
Need to test -addons before merging this back to 1.6.0.
(closes issue #13605)
Reported by: tomo1657
Patches:
13605_seanbright.diff uploaded by seanbright (license 71)
Tested by: mmichelson
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@148200 65c4cc65-6c06-0410-ace0-fbb531ad65f3
been removed. Furthermore, now we actually use the Context argument
passed to set the transfer context and don't error out if no
context is specified.
This addresses the actual problems outlined in issue 12158. Regarding
the other points brought up, regarding the inability to not transfer
to extensions which cannot be represented by DTMF, it is not enough of
a constraint that it is worth attempting to rework the feature.
(closes issue #12158)
Reported by: davidw
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@148160 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r146026 | murf | 2008-10-03 12:12:54 -0500 (Fri, 03 Oct 2008) | 18 lines
(closes issue #13579)
Reported by: dwagner
(closes issue #13584)
Reported by: dwagner
Tested by: murf, putnopvut
The thought occurred to me that the res= from the extension spawn
was ending up being returned from the bridge.
"Thou shalt not poison the return value". Made the change
and it appears to allow blind xfers to work as normal.
If I'm wrong, reopen the bugs. But it looks good to me!
Many thanks to putnopvut for helping me reproduce this!
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@148112 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: krisk84
Tested by: krisk84
This change prevents a call that is placed in the parkinglot to be picked up before the PBX is finished. If another extension dials the parking extension before the PBX thread has completed at minimum warnings will occur about the PBX not properly being terminated. At worst, a crash could occur.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@147952 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: nickpeirson
Patches:
pbx.c.patch uploaded by nickpeirson (license 579)
replace_bzero+bcopy.patch uploaded by nickpeirson (license 579)
Tested by: nickpeirson, murf
1. replaced all refs to bzero and bcopy to memset and memmove instead.
2. added a note to the CODING-GUIDELINES
3. add two macros to asterisk.h to prevent bzero, bcopy from creeping
back into the source
4. removed bzero from configure, configure.ac, autoconfig.h.in
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@147807 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1) r143204:
The main change here was to masquerade the channel if the channel that was to be parked was running a PBX on it. The PBX thread can then maintain full control of the channel (the zombie) as it expects to while allowing the parking thread full control of the real (parked) channel.
2) r143270:
Changed park_call_full to hold the parkinglot lock a little longer, which protects the parkeduser struct from being freed out from underneath. Made sure that the parking extension is added to the parking context while holding the lock thereby ensuring that there are no spurious warnings from removal attempts when a hangup occurs while the parking lot is being announced.
3) r143475: (the one liner)
compare peer and chan instead of looking at the parked user (pu), which could have possibly already have been freed by the parking thread
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@146883 65c4cc65-6c06-0410-ace0-fbb531ad65f3
is no garbage attempted to be used. Also, do not set args to unknown value again if there are
no options passed in.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@146875 65c4cc65-6c06-0410-ace0-fbb531ad65f3
read from the .asterisk_history file (and subsequently being duplicated
when written). We weren't checking the result of fgets() which meant
that we read the same line twice before feof() actually returned non-
zero.
Also, stop writing out an extra blank line between each item in the
history file, fix a minor off-by-one error, and use symbolic constants
rather than a hardcoded integer.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@146359 65c4cc65-6c06-0410-ace0-fbb531ad65f3
the first item in the CLI entry list. This was preventing '!' from
showing up in either 'help' or in tab completion.
(closes issue #13578)
Reported by: mvanbaak
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@146198 65c4cc65-6c06-0410-ace0-fbb531ad65f3
problem within strptime(3), which we are correcting here with ast_strptime().
(closes issue #11040)
Reported by: DEA
Patches:
20080910__bug11040.diff.txt uploaded by Corydon76 (license 14)
Tested by: DEA
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@145649 65c4cc65-6c06-0410-ace0-fbb531ad65f3
to fix blind transfers with my last commit here, I also
caused an unwanted side-effect. That is, only the first
priority of the 'h' extension would be executed when
a blind transfer occurred instead of all priorities.
Essentially, my last commit corrected the return value
of ast_bridge_call. However, the implementation still
was not 100% correct. Now it is.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@145606 65c4cc65-6c06-0410-ace0-fbb531ad65f3
within ast_bridge_call was reversed.
This problem was observed when a blind transfer placed from
the callee channel of a test call failed.
While the problem I am solving here is exactly the same
as what was reported in issue #13584, the difference is
that this fix I am applying is trunk-only. Issue #13584
was reported against the 1.4 branch, and my tests
of 1.4's blind transfers appear to work fine.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@145553 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This work is done by lmadsen, junky and mvanbaak
during AstriDevCon.
This is the second audit the CLI got, and
this time lmadsen made sure he had _ALL_ modules
loaded that have CLI commands in them.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@145121 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r144924 | kpfleming | 2008-09-27 10:00:48 -0500 (Sat, 27 Sep 2008) | 6 lines
improve header inclusion process in a few small ways:
- it is no longer necessary to forcibly include asterisk/autoconfig.h; every module already includes asterisk.h as its first header (even before system headers), which serves the same purpose
- astmm.h is now included by asterisk.h when needed, instead of being forced by the Makefile; this means external modules will build properly against installed headers with MALLOC_DEBUG enabled
- simplify the usage of some of these headers in the AEL-related stuff in the utils directory
........
r144925 | kpfleming | 2008-09-27 10:13:30 -0500 (Sat, 27 Sep 2008) | 2 lines
fix some minor issues with rev 144924
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@144949 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r144677 | murf | 2008-09-26 11:47:13 -0600 (Fri, 26 Sep 2008) | 12 lines
(closes issue #13563)
Reported by: mnicholson
Patches:
found1.diff uploaded by mnicholson (license 96)
This patch was mainly meant to apply to trunk and 1.6.x,
but I'm applying it to 1.4 also, which should be a perfectly
harmless fix to the vast majority of users who are not using
external switches, but the few who might be affected
will not have to go to the pain of filing a bug report.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@144678 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: nickpeirson
The user attached a patch, but the license is not yet
recorded. I took the liberty of finding and replacing
ALL index() calls with strchr() calls, and that
involves more than just main/pbx.c;
chan_oss, app_playback, func_cut also had calls
to index(), and I changed them out. 1.4 had no
references to index() at all.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@144569 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r144066 | murf | 2008-09-23 10:41:49 -0600 (Tue, 23 Sep 2008) | 29 lines
(closes issue #13489)
Reported by: DougUDI
Tested by: murf
(closes issue #13490)
Reported by: seanbright
Tested by: murf
(closes issue #13467)
Reported by: edantie
Tested by: murf, edantie, DougUDI
This crash happens because we are unsafely handling old pointers.
The channel whose cdr is being handled, has been hung up and
destroyed already. I reorganized the code a bit, and tried not
to lose the fork-cdr-chain concepts of the previous code.
I now verify that the 'previous' channel (the channel we
had when the bridge was started), still exists, by looking it up
by name in the channel list. I also do not try to reset the
CDR's of channels involved in bridges.
Testing shows it solves the crash problem, and should not
negatively impact previous fixes involving CDR's generated
during/after blind transfers. (The reason we need to reset
the CDR's on the "beginning" channels in the first place).
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@144067 65c4cc65-6c06-0410-ace0-fbb531ad65f3
is set, don't bother searching for a region to free, just
immediately exit.
This has the dual benefit of suppressing a warning message
about freeing memory at (nil) and of optimizing the free()
replacement by not having to do any futile searching for
the proper region to free.
(closes issue #13498)
Reported by: pj
Patches:
13498.patch uploaded by putnopvut (license 60)
Tested by: pj
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@143400 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r143337 | mmichelson | 2008-09-17 13:24:15 -0500 (Wed, 17 Sep 2008) | 6 lines
Allow for "G.729" if offered in an SDP even though
it is not RFC 3551 compliant. Some Cisco switches
will send this in an SDP, and it doesn't hurt to
be able to accept this.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@143340 65c4cc65-6c06-0410-ace0-fbb531ad65f3
when a file is invalid from when a file is missing. This is most important when
we have two configuration files. Consider the following example:
Old system:
sip.conf users.conf Old result New result
======== ========== ========== ==========
Missing Missing SIP doesn't load SIP doesn't load
Missing OK SIP doesn't load SIP doesn't load
Missing Invalid SIP doesn't load SIP doesn't load
OK Missing SIP loads SIP loads
OK OK SIP loads SIP loads
OK Invalid SIP loads incompletely SIP doesn't load
Invalid Missing SIP doesn't load SIP doesn't load
Invalid OK SIP doesn't load SIP doesn't load
Invalid Invalid SIP doesn't load SIP doesn't load
So in the case when users.conf doesn't load because there's a typo that
disrupts the syntax, we may only partially load users, instead of failing with
an error, which may cause some calls not to get processed. Worse yet, the old
system would do this with no indication that anything was even wrong.
(closes issue #10690)
Reported by: dtyoo
Patches:
20080716__bug10690.diff.txt uploaded by Corydon76 (license 14)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@142992 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r142675 | murf | 2008-09-11 22:29:34 -0600 (Thu, 11 Sep 2008) | 29 lines
Tested by: sergee, murf, chris-mac, andrew, KNK
This is a "second attempt" to restore the previous "endbeforeh" behavior
in 1.4 and up. In order to capture information concerning all the
legs of transfers in all their infinite combinations, I was forced
to this particular solution by a chain of logical necessities, the
first being that I was not allowed to rewrite the CDR mechanism from
the ground up!
This change basically leaves the original machinery alone, which allows
IVR and local channel type situations to generate CDR's as normal, but
a channel flag can be set to suppress the normal running of the h exten.
That flag would be set by the code that runs the h exten from the
ast_bridge_call routine, to prevent the h exten from being run twice.
Also, a flag in the ast_bridge_config struct passed into ast_bridge_call
can be used to suppress the running of the h exten in that routine. This
would happen, for instance, if you use the 'g' option in the Dial app.
Running this routine 'early' allows not only the CDR() func to be used
in the h extension for reading CDR variables, but also allows them to
be modified before the CDR is posted to the backends.
While I dearly hope that this patch overcomes all problems, and
introduces no new problems, reality suggests that surely someone
will have problems. In this case, please re-open 13251 (or 13289),
and we'll see if we can't fix any remaining issues.
** trunk note: some code to suppress the h exten being run
from app_queue was added; for the 'continue' option available
only in trunk/1.6.x.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@142676 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r142575 | murf | 2008-09-11 16:55:49 -0600 (Thu, 11 Sep 2008) | 20 lines
(closes issue #13364)
Reported by: mdu113
Well, fundamentally, the problems revealed in 13364 are
because of the ForkCDR call that is done before the dial.
When the bridge is in place, it's dealing with the first
(and wrong) cdr in the list.
So, I wrote a little func to zip down to the first non-locked
cdr in the chain, and thru-out the ast_bridge_call, these
results are used instead of raw chan->cdr and peer->cdr pointers.
This shouldn't affect anyone who isn't forking cdrs before a
dial, and should correct the cdr's of those that do.
So, this change ends up correcting the dstchannel
and userfield; the disposition was fixed by a previous
patch, it was OK coming into this problem.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@142576 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r142474 | murf | 2008-09-10 15:58:17 -0600 (Wed, 10 Sep 2008) | 30 lines
(closes issue #12318)
Reported by: krtorio
I made a small change to the code that handles local channel situations.
In that code, I copy the answer time from the peer cdr, to the bridge_cdr,
but I wasn't also copying the disposition from the peer cdr.
So, Now I copy the disposition, and I've tested against
these cases:
1. phone 1 never answers the phone; no cdr is generated at all.
this should show up as a manager command failure or something.
2. phone 2 never answers. CDR is generated, says NO ANSWER
3. phone 2 is busy. CDR is generated, says BUSY
4. phone 2 answers: CDR is generated, times are correct; disposition
is ANSWERED, which is correct. The start time is the time that
the manager dialed the first phone. The answer time is the time
the second phone picks up.
I purposely left the cid and src fields blank; since this call really
originates from the manager, there is no 'easy' data to put in these
fields. If you feel strongly that these fields should be filled in,
re-open this bug and I'll dig further.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@142475 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r142354 | russell | 2008-09-10 11:39:53 -0500 (Wed, 10 Sep 2008) | 7 lines
It is a normal situation that a task gets put in the scheduler that should run
as soon as possible. Accept "0" as an acceptable time to run, and also treat
negative as "run now", and don't print a debug message about it.
(inspired by a message asking about the "request to schedule in the past"
debug message on the -dev list)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@142355 65c4cc65-6c06-0410-ace0-fbb531ad65f3
or when calling ast_waitfor(). These are inappropriate times to hold the channel
lock. This is what has caused "could not get the channel lock" messages from
chan_sip and has likely caused a negative impact on performance results of SIP
in Asterisk 1.6. Thanks to file for pointing out this section of code.
(closes issue #13287)
(closes issue #13115)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141949 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r141806 | russell | 2008-09-08 16:02:36 -0500 (Mon, 08 Sep 2008) | 7 lines
When doing an async goto, detect if the channel is already in the middle of a
masquerade. This can happen when chan_local is trying to optimize itself out.
If this happens, fail the async goto instead of bursting into flames.
(closes issue #13435)
Reported by: geoff2010
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141807 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Changes applied by this patch:
- Fix autocompletion in 'sip prune realtime', sip peers where never auto completed. Now we complete this command with:
'sip prune realtime peer' -> all | like | sip peers
Also I have modified the syntax in the usage, was wrong...
- Pass ast_cli_args->argv and ast_cli_args->argc while running autocompletion on CLI commands (CLI_GENERATE).
With this we avoid comparisons on ast_cli_args->line like this:
strcasestr(a->line, " description")
strcasestr(a->line, "descriptions ")
strcasestr(a->line, "realtime peer"), and so on..
Making the code more confusing (check the spaces in description!).
The only thing we must be sure is to first check a->pos or a->argc.
- Fix 'iax2 prune realtime' autocompletion, now we autocomplete this command with 'all' & 'iax2 peers', check a look that iax2 peers where all the peers, now only the ones in the cache..
(closes issue #13133)
Reported by: eliel
Patches:
clichanges.patch uploaded by eliel (license 64)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r141028 | jpeeler | 2008-09-04 12:00:29 -0500 (Thu, 04 Sep 2008) | 7 lines
(closes issue #11979)
Fixes multiple parking problems:
Crash when executing a park on an extension dialed by AGI due to not returning the proper return code.
Crash when using a builtin feature that was a subset of a enabled dynamic feature.
Crash due to always hanging up the peer despite the fact that the peer was supposed to be parked.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141039 65c4cc65-6c06-0410-ace0-fbb531ad65f3
of changes to the Set and MSet apps, so people aren't
so shocked and surprised when they upgrade from
1.4 to 1.6.
Also, for the sake of those upgrading from 1.4 to
1.6 with AEL, I provide automatic support for the
"old" way of using Set(), that still does the
exact same old thing with quotes and backslashes
and so on as 1.4 did, by having AEL compile in the
use of MSet() instead of Set(), everywhere it inserts
this code.
But, if the app_set var is set to 1.6 or higher,
it uses the "new", non-evaluative Set().
This only usually happens if the user manually
inserts this into the asterisk.conf file, or runs
the "make samples" command.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@140824 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r140747 | murf | 2008-09-02 17:36:56 -0600 (Tue, 02 Sep 2008) | 1 line
I am turning the warnings generated in ast_cdr_free and post_cdr into verbose level 2 messages. Really, they matter little to end users. You either get the CDR's you wanted, or you don't, and it is a bug.
For trunk, I am going one step further. These messages were pretty worthless even for debug, so I'm completely removing them.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@140749 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r140690 | murf | 2008-09-02 16:40:13 -0600 (Tue, 02 Sep 2008) | 1 line
After reconsidering, with respect to 13409, ast_cdr_detach should be OK, better in fact, than ast_cdr_free, which generates lots of useless warnings that will undoubtably generate complaints.
Hmmm. It doesn't hush the useless warnings, but it does allow control of posting via the detach and post routines, for those possible situations,
where you'd want to post single-channel cdrs.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@140692 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r140670 | murf | 2008-09-02 16:15:57 -0600 (Tue, 02 Sep 2008) | 14 lines
(closes issue #13409)
Reported by: tomaso
Patches:
asterisk-1.6.0-rc2-cdrmemleak.patch uploaded by tomaso (license 564)
I basically spent the day, verifying that this patch
solves the problem, and doesn't hurt in non-problem
cases. Why valgrind did not plainly reveal this leak
absolutely mystifies and stuns me.
Many, many thanks to tomaso for finding and providing the fix.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@140691 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r140488 | mmichelson | 2008-08-29 12:34:17 -0500 (Fri, 29 Aug 2008) | 22 lines
After working on the ao2_containers branch, I noticed
something a bit strange. In all cases where we provide
a callback function to ao2_container_alloc, the callback
function would only return 0 or CMP_MATCH. After inspecting
the ao2_callback() code carefully, I found that if you're
only looking for one specific item, then you should return
CMP_MATCH | CMP_STOP. Otherwise, astobj2 will continue
traversing the current bucket until the end searching for
more matches.
In cases like chan_iax2 where in 1.4, all the peers are
shoved into a single bucket, this makes for potentially
terrible performance since the entire bucket will be
traversed even if the peer is one of the first ones come
across in the bucket.
All the changes I have made were for cases where the
callback function defined was passed to ao2_container_alloc
so that calls to ao2_find could find a unique instance
of whatever object was being stored in the container.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@140489 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: erousseau
This was a reasonable enhancement request, which was
easy to implement. Since it's an enhancement, it
could only be applied to trunk.
Basically, for accounting where "initiated" seconds
are billed for, if the microseconds field on the end
time is greater than the microseconds field for the
answer time, add one second to the billsec field.
The implementation was requested by erousseau, and
I've implemented it as requested. I've updated the
CHANGES, the cdr.conf.sample, and the .h files
accordingly, to accept and set a flag for the
corresponding new option. cdr.c adds in the extra
second based on the usec fields if the option is
set. Tested, seems to be working fine.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@140057 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r139764 | murf | 2008-08-25 09:33:14 -0600 (Mon, 25 Aug 2008) | 9 lines
This patch reverts the changes made via 139347, and 139635, as users
are seeing adverse difference.
I will un-close 13251.
Back to the drawing board/ concept/ beginning/ whatever!
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@139770 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r139635 | murf | 2008-08-22 16:24:02 -0600 (Fri, 22 Aug 2008) | 6 lines
I found some problems with the code I committed earlier, when
I merged them into trunk, so I'm coming back to clean up.
And, in the process, I found an error in the code I added
to trunk and 1.6.x, that I'll fix using this patch also.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@139662 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r139347 | murf | 2008-08-21 17:03:50 -0600 (Thu, 21 Aug 2008) | 47 lines
(closes issue #13251)
Reported by: sergee
Tested by: murf
THis is a bold move for a static release fix, but I wouldn't have
made it if I didn't feel confident (at least a *bit* confident)
that it wouldn't mess everyone up.
The reasoning goes something like this:
1. We simply cannot do anything with CDR's at the current point
(in pbx.c, after the __ast_pbx_run loop). It's way too late to
have any affect on the CDRs. The CDR is already posted and gone,
and the remnants have been cleared.
2. I was very much afraid that moving the running of the 'h'
extension down into the bridge code (where it would be now
practical to do it), would result in a lot more calls to the
'h' exten, so I implemented it as another exten under another
name, but found, to my pleasant surprise, that there was a
1:1 correspondence to the running of the 'h' exten in the
pbx_run loop, and the new spot at the end of the bridge.
So, I ifdef'd out the current 'h' loop, and moved it into
the bridge code. The only difference I can see is the stuff
about the AST_PBX_KEEPALIVE, and hopefully, if this
is still an important decision point, I can replicate it
if there are complaints. To be perfectly honest,
the KEEPALIVE situation is not totally clear to me,
and how it relates to a post-bridge situation is less
clear. I suspect the users will point out everything
in total clarity if this steps on anyone's toes!
3. I temporarily swap the bridge_cdr into the channel
before running the 'h' exten, which makes it possible
for users to edit the cdr before it goes out the door.
And, of course, with the endbeforehexten config var set,
the users can also get at the billsec/duration vals.
After the h exten finishes, the cdr is swapped back
and processing continues as normal.
Please, all who deal with CDR's, please test this version
of Asterisk, and file bug reports as appropriate!
........
I also made a little fix to the app_dial's 'e' option,
that is related to my updates.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@139627 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r139074 | murf | 2008-08-20 11:14:55 -0600 (Wed, 20 Aug 2008) | 12 lines
(closes issue #13263)
Reported by: brainy
Tested by: murf
The specialized reset routine is tromping on the
flags field of the CDR. I made a change to not
reset the DISABLED bit. This should get rid of this
problem.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@139083 65c4cc65-6c06-0410-ace0-fbb531ad65f3
to the Set app in trunk/1.6.x, as they come from the 1.4 world. They are only bitten if
they write their AEL dialplan in the 1.4 world, and then carry it over to a trunk/1.6.x
installation where a "make samples" was executed, or where they hand-edited the
asterisk.conf file and added the [compat] category with app_set = 1.6 (or higher).
(this commit does not totally solve 13249, at least not yet)
The change involves issueing a single warning while the AEL file is loading, if:
1. app_set is present in the config file, and set to 1.6 or higher.
2. there are double quotes in an assignment statement (eg x = "hi there";)
3. the warning was not already issued.
The standalone app, aelparse, does not (yet) issue this warning. I'd have to
have it read in the asterisk.conf file, and that's a bit of hassle. I'll add
it if users request it, tho.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@138815 65c4cc65-6c06-0410-ace0-fbb531ad65f3
of the name/value pairs, pointed out by snuffy-home on #asterisk-commits.
For those of you who rely on the position of name/value pairs in manager
events... stop... that is why associative arrays were invented.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@138482 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r138027 | russell | 2008-08-15 10:07:16 -0500 (Fri, 15 Aug 2008) | 9 lines
Ensure that when a hangup occurs in autoservice, that a hangup frame gets
properly deferred to be read from the channel owner when it gets taken out
of autoservice.
(closes issue #12874)
Reported by: dimas
Patches:
v1-12874.patch uploaded by dimas (license 88)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@138028 65c4cc65-6c06-0410-ace0-fbb531ad65f3
would reset to 500 ms every time a non-voice frame
was received. The total time we poll should be 500 ms, so
now we save the amount of time left after the poll returned
and use that as our argument for the next call to poll
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@136633 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Instead, poll the channel until receiving a voice frame. The
cap on this poll is 500 ms.
The optional delay is still allowable in the Answer() application,
but the delay has been moved back to its original position, after
the call to the channel's answer callback. The poll for the voice
frame will not happen if a delay is specified when calling Answer().
(closes issue #12708)
Reported by: kactus
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@136631 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r136062 | mmichelson | 2008-08-06 10:58:40 -0500 (Wed, 06 Aug 2008) | 16 lines
Since adding the AST_CONTROL_SRCUPDATE frame type,
there are places where ast_rtp_new_source may be called
where the tech_pvt of a channel may not yet have an
rtp structure allocated. This caused a crash in chan_skinny,
which was fixed earlier, but now the same crash has been
reported against chan_h323 as well. It seems that the best
solution is to modify ast_rtp_new_source to not attempt to
set the marker bit if the rtp structure passed in is NULL.
This change to ast_rtp_new_source also allows the removal
of what is now a redundant pointer check from chan_skinny.
(closes issue #13247)
Reported by: pj
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@136063 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r135841 | mmichelson | 2008-08-05 19:25:10 -0500 (Tue, 05 Aug 2008) | 27 lines
Merging the issue11259 branch.
The purpose of this branch was to take into account
"burps" which could cause jitterbuffers to misbehave.
One such example is if the L option to Dial() were used
to inject audio into a bridged conversation at regular
intervals. Since the audio here was not passed through
the jitterbuffer, it would cause a gap in the jitterbuffer's
timestamps which would cause a frames to be dropped for a
brief period.
Now ast_generic_bridge will empty and reset the jitterbuffer
each time it is called. This causes injected audio to be handled
properly.
ast_generic_bridge also will empty and reset the jitterbuffer
if it receives an AST_CONTROL_SRCUPDATE frame since the change
in audio source could negatively affect the jitterbuffer.
All of this was made possible by adding a new public API call
to the abstract_jb called ast_jb_empty_and_reset.
(closes issue #11259)
Reported by: plack
Tested by: putnopvut
........
r135847 | mmichelson | 2008-08-05 19:27:54 -0500 (Tue, 05 Aug 2008) | 4 lines
Revert inadvertent changes to app_skel that occurred when
I was testing for a memory leak
........
r135850 | mmichelson | 2008-08-05 19:29:54 -0500 (Tue, 05 Aug 2008) | 3 lines
Remove properties that should not be here
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@135851 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r135799 | murf | 2008-08-05 17:13:20 -0600 (Tue, 05 Aug 2008) | 34 lines
(closes issue #12982)
Reported by: bcnit
Tested by: murf
I discovered that also, in the previous bug fixes and changes,
the cdr.conf 'unanswered' option is not being obeyed, so
I fixed this.
And, yes, there are two 'answer' times involved in this
scenario, and I would agree with you, that the first
answer time is the time that should appear in the CDR.
(the second 'answer' time is the time that the bridge
was begun).
I made the necessary adjustments, recording the first
answer time into the peer cdr, and then using that to
override the bridge cdr's value.
To get the 'unanswered' CDRs to appear, I purposely
output them, using the dial cmd to mark them as
DIALED (with a new flag), and outputting them if
they bear that flag, and you are in the right mode.
I also corrected one small mention of the Zap device
to equally consider the dahdi device.
I heavily tested 10-sec-wait macros in dial, and
without the macro call; I tested hangups while the
macro was running vs. letting the macro complete
and the bridge form. Looks OK. Removed all the
instrumentation and debug.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@135821 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: falves11
Tested by: murf
falves11 ==
The changes I introduce here seem to clear up the problem
for me. However, if they do not for you, please reopen this
bug, and we'll keep digging.
The root of this problem seems to be a subtle memory corruption
introduced when creating an extension with an empty extension
name. While valgrind cannot detect it outside of DEBUG_MALLOC
mode, when compiled with DEBUG_MALLOC, this is certain death.
The code in main/features.c is a puzzle to me. On the initial
module load, the code is attempting to add the parking extension
before the features.conf file has even been opened!
I just wrapped the offending call with an if() that will not
try to add the extension if the extension name is empty. THis
seems to solve the corruption, and let the "memory show allocations"
work as one would expect.
But, really, adding an extension with an empty name is a seriously
bad thing to allow, as it will mess up all the pattern matching
algorithms, etc. So, I added a statement to the add_extension2 code to return
a -1 if this is attempted.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@135265 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r134883 | murf | 2008-07-31 13:23:42 -0600 (Thu, 31 Jul 2008) | 51 lines
(closes issue #11849)
Reported by: greyvoip
Tested by: murf
OK, a few days of debugging, a bunch of instrumentation
in chan_sip, main/channel.c, main/pbx.c, etc. and 5 solid
notebook pages of notes later, I have made the small
tweek necc. to get the start time right on the second
CDR when:
A Calls B
B answ.
A hits Xfer button on sip phone,
A dials C and hits the OK button,
A hangs up
C answers ringing phone
B and C converse
B and/or C hangs up
But does not harm the scenario where:
A Calls B
B answ.
B hits xfer button on sip phone,
B dials C and hits the OK button,
B hangs up
C answers ringing phone
A and C converse
A and/or C hangs up
The difference in start times on the second CDR is because
of a Masquerade on the B channel when the xfer number is
sent. It ends up replacing the CDR on the B channel with
a duplicate, which ends up getting tossed out. We keep
a pointer to the first CDR, and update *that* after the
bridge closes. But, only if the CDR has changed.
I hope this change is specific enough not to muck
up any current CDR-based apps. In my defence, I
assert that the previous information was wrong,
and this change fixes it, and possibly other
similar scenarios.
I wonder if I should be doing the same thing
for the channel, as I did for the peer, but
I can't think of a scenario this might affect.
I leave it, then, as an exersize for the users,
to find the scenario where the chan's CDR
changes and loses the proper start time.
........
and as to 1.4 to trunk; have I expressed my
feelings about code shifting from one file
to another? Good.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@134922 65c4cc65-6c06-0410-ace0-fbb531ad65f3
driver into a common place for multiple channel drivers.
(closes issue #13152)
Reported by: caio1982
Patches:
atxfer_complete_sound3.diff uploaded by caio1982 (license 22)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@134401 65c4cc65-6c06-0410-ace0-fbb531ad65f3
respectively. Also, take the opportunity to clean up the CLI prompt
generation code.
(closes issue #13175)
Reported by: eliel
Patches:
cliprompt.patch uploaded by eliel (license 64)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@134353 65c4cc65-6c06-0410-ace0-fbb531ad65f3
implementations. Asterisk has, for a long time,
had its own implementation of poll(2) which
just used the input arguments to call select(2).
In 1.4, this internal implementation was used
for Darwin systems. This was removed in Asterisk
trunk at some point, but it seems as though this
was not the right move to make.
On Mac OS X, it appears as though the poll used
to gather CLI input does not respond properly
when connecting via a remote Asterisk console.
Reverting to the use of Asterisk's poll fixed
the issue.
Also, there is now an option for the configure
script, --enable-internal-poll, which will allow
for anyone to use Asterisk's internal poll
implementation in case they suspect that their
system's poll implementation is buggy.
closes issue #11928)
Reported by: adriavidal
Patches:
1.6.0-configurev2.patch uploaded by putnopvut (license 60)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@134125 65c4cc65-6c06-0410-ace0-fbb531ad65f3
called from elsewhere in Asterisk to find the current state of a device. In
that case, we want to use the cached value if it exists. The other way is when
processing a device state change. In that case, we do not want to check the
cache because returning the last known state is counter productive.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@133945 65c4cc65-6c06-0410-ace0-fbb531ad65f3
we do NOT need to uri_decode in manager.
(if I sent core%20show%20channels from a telnet
session, it should be interpreted literally, however,
if I send that from an http session, it should be
decoded, which is the behaivor now)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@133770 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r133649 | tilghman | 2008-07-25 12:19:39 -0500 (Fri, 25 Jul 2008) | 8 lines
Fix some errant device states by making the devicestate API more strict in
terms of the device argument (only without the unique identifier appended).
(closes issue #12771)
Reported by: davidw
Patches:
20080717__bug12771.diff.txt uploaded by Corydon76 (license 14)
Tested by: davidw, jvandal, murf
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@133665 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ago (does not affect 1.4), where you would pass
a pointer to the end of a character array, and
ast_uri_decode would do no good.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@133651 65c4cc65-6c06-0410-ace0-fbb531ad65f3
to Asterisk licensing information. The licensing page includes the Asterisk license,
as well as a (not yet complete) list of 3rd party libraries that may be used, as well
as what license we receive them under.
Help filling out this list in the format that I have started in doxyref.h would be
much appreciated. :)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@133575 65c4cc65-6c06-0410-ace0-fbb531ad65f3
the code checks to see if there is a cached state available, use the aggregate
cached state across all servers, and not just the local state.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@133566 65c4cc65-6c06-0410-ace0-fbb531ad65f3
this commit, only the logger thread's PID would
be printed.
(closes issue #13150)
Reported by: atis
Patches:
log_pid.diff uploaded by putnopvut (license 60)
Tested by: eliel
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@133448 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: murf
Tested by: murf
For: J. Geis
The 'data' field in the ast_exten struct was being
'moved' from the current dialplan to the replacement
dialplan. This was not good, as the current dialplan
could have problems in the time between the change
and when the new dialplan is swapped in.
So, I modified the merge_and_delete code to strdup
the 'data' field (the args to the app call), and
then it's freed as normal.
I improved a few messages; I added code to limit
the number of calls to the context_merge_incls_swits_igps_other_registrars()
to one per context. I don't think having it called
multiple times per context was doing anything bad,
but it was inefficient.
I hope this fixes the problems Mr. Geiss was noting in
asterisk-users, see
http://lists.digium.com/pipermail/asterisk-users/2008-July/215634.html
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@133299 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r133169 | mmichelson | 2008-07-23 14:39:47 -0500 (Wed, 23 Jul 2008) | 12 lines
As suggested by seanbright, the PSEUDO_CHAN_LEN in
app_chanspy should be set at load time, not at compile
time, since dahdi_chan_name is determined at load time.
Also changed the next_unique_id_to_use to have the
static qualifier.
Also added the dahdi_chan_name_len variable so that
strlen(dahdi_chan_name) isn't necessary. Thanks to
seanbright for the suggestion.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@133171 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r132872 | kpfleming | 2008-07-23 06:52:18 -0500 (Wed, 23 Jul 2008) | 2 lines
minor optimization for stringfields: when a field is being set to a larger value than it currently contains and it happens to be the most recent field allocated from the currentl pool, it is possible to 'grow' it without having to waste the space it is currently using (or potentially even allocate a new pool)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@132964 65c4cc65-6c06-0410-ace0-fbb531ad65f3
own repository, and must be installed like any other library for Asterisk to
use. The two modules that require it are codec_resample and app_jack.
To install libresample:
$ svn co http://svn.digium.com/svn/libresample/trunk libresample
$ cd libresample
$ ./configure
$ make
$ sudo make install
This code is currently in our own repository because the build system did not
include the appropriate targets for building a dynamic library or for installing
the library.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@132390 65c4cc65-6c06-0410-ace0-fbb531ad65f3
removed early (before the routine to load the configuration was
finished) because a variable wasn't initialized.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@132242 65c4cc65-6c06-0410-ace0-fbb531ad65f3
probably not a good idea, as we might run out of stack space. Therefore,
changing this over to use the ast_str infrastructure for buffers is
probably a good idea.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@132206 65c4cc65-6c06-0410-ace0-fbb531ad65f3
the same keyword as the other files (patch by eliel).
(closes issue #13104)
Reported by: eliel
Patches:
revision.patch uploaded by eliel (license 64)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@132050 65c4cc65-6c06-0410-ace0-fbb531ad65f3
a feature without specifying a group or feature to register.
(closes issue #13101)
Reported by: eliel
Patches:
features.c.patch uploaded by eliel (license 64)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@131717 65c4cc65-6c06-0410-ace0-fbb531ad65f3
calculate the number of bytes from a sysinfo structure.
unsigned long.
(closes issue #13057)
Reported by: eliel
Patches:
asterisk.c.patch uploaded by eliel (license 64)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@131445 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r130959 | tilghman | 2008-07-15 12:19:13 -0500 (Tue, 15 Jul 2008) | 8 lines
astman_send_error does not need a newline appended -- the API takes care of
that for us.
(closes issue #13068)
Reported by: gknispel_proformatique
Patches:
asterisk_1_4_astman_send.patch uploaded by gknispel (license 261)
asterisk_trunk_astman_send.patch uploaded by gknispel (license 261)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@131044 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r130735 | mvanbaak | 2008-07-14 19:10:21 +0200 (Mon, 14 Jul 2008) | 10 lines
notify the user that dnsmgr refresh wont work when dnsmgr is not enabled.
Previously this command would automagically appear and disappear.
This was confusing.
(closes issue #12796)
Reported by: chappell
Patches:
dnsmgr_refresh_3.diff uploaded by chappell (license 8)
Tested by: russell, chappell, mvanbaak
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@130744 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: eliel
OK, now the context registrar slot is strdup'd. It is freed
on destruction. I don't see the need to do this with all
the structs' registrar fields, but if some wild case proves
they should also be handled this way, then we can
put in the extra work at that time.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@130297 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@130145 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r129966 | kpfleming | 2008-07-11 09:03:52 -0500 (Fri, 11 Jul 2008) | 5 lines
fix a flaw found while experimenting with structure alignment and padding; low-fence checking would not work properly on 64-bit platforms, because the compiler was putting 4 bytes of padding between the fence field and the allocation memory block
added a very obvious runtime warning if this condition reoccurs, so the developer who broke it can be chastised into fixing it :-)
........
r129967 | kpfleming | 2008-07-11 09:03:52 -0500 (Fri, 11 Jul 2008) | 5 lines
simplify calculation
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@129968 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r129436 | mmichelson | 2008-07-09 14:32:20 -0500 (Wed, 09 Jul 2008) | 13 lines
Fix a problem where inbound rfc2833 audio would be sent to the
core instead of being P2P bridged. When the core regenerated
the rfc2833 packet for the outbound leg, the SSRC would be different
than the RTP audio on the call leg causing DTMF detection issues on
the far end.
(closes issue #12955)
Reported by: tonyredstone
Patches:
dynamic_rtp.patch uploaded by tsearle (license 373)
Tested by: tonyredstone
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@129437 65c4cc65-6c06-0410-ace0-fbb531ad65f3
first SRV result from DNS before processing weights and priorities and
dns_parse_answer wouldn't report that there were no records in DNS
unless a failure occured. Also fixed a bug where dnsmgr_refresh would
report that a entry was being changed when ast_gethostbyname had failed.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@129156 65c4cc65-6c06-0410-ace0-fbb531ad65f3
AMI commands can display that a channel is under control of an AGI.
Work inspired by work at customer site, but paid for by Edvina AB
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@128240 65c4cc65-6c06-0410-ace0-fbb531ad65f3
and not use the p2p rtp bridge). I could not find a way to detect us using the p2p bridge, which
would be nice.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@128197 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r127973 | tilghman | 2008-07-03 22:30:30 -0500 (Thu, 03 Jul 2008) | 8 lines
Fix the 'dialplan remove extension' logic, so that it a) works with cidmatch,
and b) completes contexts correctly when the extension is ambiguous.
(closes issue #12980)
Reported by: licedey
Patches:
20080703__bug12980.diff.txt uploaded by Corydon76 (license 14)
Tested by: Corydon76
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@128027 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r127663 | murf | 2008-07-02 18:16:25 -0600 (Wed, 02 Jul 2008) | 30 lines
The CDRfix4/5/6 omnibus cdr fixes.
(closes issue #10927)
Reported by: murf
Tested by: murf, deeperror
(closes issue #12907)
Reported by: falves11
Tested by: murf, falves11
(closes issue #11849)
Reported by: greyvoip
As to 11849, I think these changes fix the core problems
brought up in that bug, but perhaps not the more global
problems created by the limitations of CDR's themselves
not being oriented around transfers.
Reopen if necc, but bug reports are not the best
medium for enhancement discussions. We need to start
a second-generation CDR standardization effort to cover
transfers.
(closes issue #11093)
Reported by: rossbeer
Tested by: greyvoip, murf
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@127793 65c4cc65-6c06-0410-ace0-fbb531ad65f3
to document arguments seems logical, and does work, but is not the best
thing to use.
\arg in doxygen is simply for creating non-nested unordered lists. \param is
the correct tag to use to document function parameters, and will come out
better in the generated documentation.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@127401 65c4cc65-6c06-0410-ace0-fbb531ad65f3
callback. This change differs from commit 127113 in that now the
channel is not set to AST_STATE_UP until after the answer callback.
(closes issue #12924)
Reported by: snyfer
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@127157 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- change ast_settimeout() to honor max rate in edge cases of file playback
(this will make some warning messages go away at the end of playing back
a file)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@125332 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r125132 | kpfleming | 2008-06-25 17:21:30 -0500 (Wed, 25 Jun 2008) | 10 lines
allow tonezone to live in a different place than DAHDI/Zaptel, since dahdi-tools and dahdi-linux are now separate packages and can be installed in different places
don't include tonezone.h in dahdi_compat.h, because only a couple of modules need it
get app_rpt building again after the DAHDI changes
(closes issue #12911)
Reported by: tzafrir
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@125138 65c4cc65-6c06-0410-ace0-fbb531ad65f3
They want (char *)NULL as sentinel.
An example is OpenBSD (confirmed on 4.3) that ships with gcc 3.3.4
This commit introduces a contstant SENTINEL which is declared as:
#define SENTINEL ((char *)NULL)
All places I could test compile on my openbsd system are converted.
Update CODING-GUIDELINES to tell about this constant.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@124127 65c4cc65-6c06-0410-ace0-fbb531ad65f3
them, and memory does not get free'd causing strange issues with SIP.
This code was originally written by russellb in the team/group/issue_11972/ branch.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@123546 65c4cc65-6c06-0410-ace0-fbb531ad65f3
a memory leak when running the astobj2 test CLI command. After
searching, it appears the leak was in the command handler itself.
Each object was allocated (recount = 1) and then linked into
a container (refounct = 2). Then at the end of the function,
the container was unreffed, causing all the objects to have
their refcount decremented by one, leaving the refcount for
all objects allocated in that function at 1. I've now added
an extra unref to the mix so that the refcount equals zero
when the container is unreffed.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@123526 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r123271 | russell | 2008-06-17 10:48:31 -0500 (Tue, 17 Jun 2008) | 4 lines
Fix a memory leak in astobj2 that was pointed out by seanbright. When a container
got destroyed, the underlying bucket list entry for each object that was in the
container at that time did not get free'd.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@123272 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: ys
Many thanks to ys for doing the research on this problem.
I didn't think it would be best to unlock the contexts
and then relock them after the remove_extension2() call,
so I added an extra arg to remove_extension2() and set it
appropriately in each call. There were not that many.
I considered forcing the code to lock the contexts before
the call to remove_extension2(), but that would require
a slightly greater degree of changes, especially since
the find_context_locked is local to pbx.c
I did a simple sanity test to make sure the code doesn't
mess things up in general.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@123165 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- Convert the last part of channel.c over to use the timing API. This would
not have made a difference when using the dahdi timing module. I noticed
it when trying to use another timing source. Oops. :)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@122923 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r122713 | mmichelson | 2008-06-13 16:44:53 -0500 (Fri, 13 Jun 2008) | 9 lines
Short circuit the loop in autoservice_run if there are no channels to poll.
If we continued, then the result would be calling poll() with a NULL
pollfd array. While this is fine with POSIX's poll(2) system call, those
who use Asterisk's internal poll mechanism (Darwin systems) would have
a failed assertion occur when poll is called.
(related to issue #10342)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@122714 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- Convert chan_iax2 to use the timing API
- Convert usage of timing in the core to use the timing API instead of
using DAHDI directly
- Make a change to the timing API to add the set_rate() function
- change the timing core to use a rwlock
- merge a timing implementation, res_timing_dahdi
Basic testing was successful using res_timing_dahdi
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@122523 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r122130 | tilghman | 2008-06-12 10:11:30 -0500 (Thu, 12 Jun 2008) | 4 lines
Occasionally, the alertpipe loses its nonblocking status, so detect and correct
that situation before it causes a deadlock. (Reported and tested by ctooley
via #asterisk-dev)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@122131 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r122127 | murf | 2008-06-12 08:51:44 -0600 (Thu, 12 Jun 2008) | 1 line
Arkadia tried to warn me, but the code added to ast_cdr_busy, _failed, and _noanswer was redundant. Didn't spot it until I was resolving conflicts in trunk. Ugh. Redundant code removed. It wasn't harmful. Just dumb.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@122128 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r122046 | murf | 2008-06-12 07:47:34 -0600 (Thu, 12 Jun 2008) | 37 lines
(closes issue #10668)
Reported by: arkadia
Tested by: murf, arkadia
Options added to forkCDR() app and the CDR() func to
remove some roadblocks for CDR applications.
The "show application ForkCDR" output was upgraded
to more fully explain the inner workings of forkCDR.
The A option was added to forkCDR to force the
CDR system to NOT change the disposition on the
original CDR, after the fork. This involves
ast_cdr_answer, _busy, _failed, and so on.
The T option was added to forkCDR to force
obedience of the cdr LOCKED flag in the
ast_cdr_end, all the disposition changing
funcs (ast_cdr_answer, etc), and in the
ast_cdr_setvar func.
The CHANGES file was updated to explain ALL
the new options added to satisfy this bug report
(and some requests made verbally and via
email, irc, etc, over the past months/year)
The 's' option was added to the CDR() func,
to force it to skip LOCKED cdr's in the
chain.
Again, the new options should be totally transparent
to existing apps! Current behavior of CDR,
forkCDR, and the rest of the CDR system should
not change one little bit. Until you add the
new options, at least!
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@122091 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit merges in the rest of the code needed to support distributed device
state. There are two main parts to this commit.
Core changes:
- The device state handling in the core has been updated to understand device
state across a cluster of Asterisk servers. Every time the state of a device
changes, it looks at all of the device states on each node, and determines the
aggregate device state. That resulting device state is what is provided to
modules in Asterisk that take actions based on the state of a device.
New module, res_ais:
- A module has been written to facilitate the communication of events between
nodes in a cluster of Asterisk servers. This module uses the SAForum AIS
(Service Availability Forum Application Interface Specification) CLM and EVT
services (Cluster Management and Event) to handle this task. This module
currently supports sharing Voicemail MWI (Message Waiting Indication) and
device state events between servers. It has been tested with openais, though
other implementations of the spec do exist.
For more information on testing distributed device state, see the following doc:
- doc/distributed_devstate.txt
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@121559 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit pulls in a batch of improvements and additions to the event API.
Changes include:
- the ability to dynamically build a subscription. This is useful if you're
building a subscription based on something you receive from the network,
or from options in a configuration file.
- Add tables of event types and IE types and the corresponding string
representation for implementing text based protocols that use these
events, for showing events on the CLI, reading configuration that
references event information, among other things.
- Add a table that maps IE types and the corresponding payload type.
- an API call to get the total size of an event
- an API call to get all events from the cache that match a subscription
- a new IE payload type, raw, which I used for transporting the Entity ID in
my code for handling distributed device state.
- Code improvements to reduce code duplication
- Include the Entity ID of the server that originated the event in every event
- an additional event type, DEVICE_STATE_CHANGE, to help facilitate distributed
device state. DEVICE_STATE is a state change on one server, DEVICE_STATE_CHANGE
is the aggregate device state change across all servers.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@121555 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit breaks out some logic from pbx.c into a simple API. The hint
processing code had logic for taking the state from multiple devices and
turning that into the state for a single extension. So, I broke this out
and made an API that lets you take multiple device states and determine
the aggregate device state. I needed this for some core device state changes
to support distributed device state.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@121501 65c4cc65-6c06-0410-ace0-fbb531ad65f3
DUNDi uses a concept called the Entity ID for unique server identifiers. I have
pulled out the handling of EIDs and made it something available to all of Asterisk.
There is now a global Entity ID that can be used for other purposes as well, such
as code providing distributed device state, which is why I did this. The global
Entity ID is set automatically, just like it was done in DUNDi, but it can also be
set in asterisk.conf. DUNDi will now use this global EID unless one is specified
in dundi.conf.
The current EID for the system can be seen in the "core show settings" CLI command.
It is also available in the dialplan via the ENTITYID variable.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@121439 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r121280 | russell | 2008-06-09 11:35:40 -0500 (Mon, 09 Jun 2008) | 10 lines
Do not attempt to do emulation if an END digit is received and the length is
less than the defined minimum digit length, and the other end only wants END
digits (SIP INFO, for example).
(closes issue #12778)
Reported by: tsearle
Patches:
12778.rev1.txt uploaded by russell (license 2)
Tested by: tsearle
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@121282 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r120863 | jpeeler | 2008-06-06 10:33:15 -0500 (Fri, 06 Jun 2008) | 3 lines
This fixes a crash when LOW_MEMORY is turned on. Two allocations of the ast_rtp struct that were previously allocated on the stack have been modified to use thread local storage instead.
........
r120885 | jpeeler | 2008-06-06 11:39:20 -0500 (Fri, 06 Jun 2008) | 2 lines
Correction to commmit 120863, make sure proper destructor function is called as well define two thread storage local variables.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@120906 65c4cc65-6c06-0410-ace0-fbb531ad65f3
and normal deviations. Currently this is implemented for chan_sip, but could be added to the func_channel_read callbacks for the CHANNEL function
for any channel that uses RTP.
(closes issue #10590)
Reported by: gasparz
Patches:
chan_sip_c.diff uploaded by gasparz (license 219)
rtp_c.diff uploaded by gasparz (license 219)
rtp_h.diff uploaded by gasparz (license 219)
audioqos-trunk.diff uploaded by snuffy (license 35)
rtpqos-trunk-r119891.diff uploaded by sergee (license 138)
Tested by: jsmith, gasparz, snuffy, marsosa, chappell, sergee
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@120635 65c4cc65-6c06-0410-ace0-fbb531ad65f3
has been loaded, fix a return value in the loader, and ensure that the help
workhorse header does not print on load.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@120602 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r120173 | jpeeler | 2008-06-03 17:15:33 -0500 (Tue, 03 Jun 2008) | 6 lines
(closes issue #11594)
Reported by: yem
Tested by: yem
This change decreases the buffer size allocated on the stack substantially in config_text_file_load when LOW_MEMORY is turned on. This change combined with the fix from revision 117462 (making mkintf not copy the zt_chan_conf structure) was enough to prevent the crash.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@120174 65c4cc65-6c06-0410-ace0-fbb531ad65f3
and off for new installations. This includes the translation from pipes to commas
for pbx_realtime and the EXEC command for AGI, as well as the change to the Set
application not to support multiple variables at once.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@120171 65c4cc65-6c06-0410-ace0-fbb531ad65f3
hold tracking information for mutexes. Now, the "core show locks" output
will output information about who is holding a rwlock when a thread is
waiting on it.
(closes issue #11279)
Reported by: ys
Patches:
trunk_lock_utils.v8.diff uploaded by ys (license 281)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@120064 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r119742 | russell | 2008-06-02 09:39:45 -0500 (Mon, 02 Jun 2008) | 5 lines
Improve CLI command blacklist checking for the command manager action. Previously,
it did not handle case or whitespace properly. This made it possible for blacklisted
commands to get executed anyway.
(closes issue #12765)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@119744 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r119156 | russell | 2008-05-29 17:24:29 -0500 (Thu, 29 May 2008) | 10 lines
Fix a race condition in channel autoservice. There was still a small window of opportunity
for a DTMF frame, or some other deferred frame type, to come in and get dropped.
(closes issue #12656)
(closes issue #12656)
Reported by: dimas
Patches:
v3-12656.patch uploaded by dimas (license 88)
-- with some modifications by me
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@119157 65c4cc65-6c06-0410-ace0-fbb531ad65f3
before we enter manage_parkinglot.
This will get rid of CLI warnings like:
__ast_read: Exception flag set on 'SIP/<NUMBER>-<ID>', but no exception handler
(closes issue #12748)
Reported by: nreinartz
Patches:
asterisk-multiparking_initialize_filedescr_sets-0.0.1.patch uploaded by nreinartz (license 452)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@119015 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r118858 | murf | 2008-05-28 18:25:28 -0600 (Wed, 28 May 2008) | 46 lines
(closes issue #10668)
(closes issue #11721)
(closes issue #12726)
Reported by: arkadia
Tested by: murf
These changes:
1. revert the changes made via bug 10668;
I should have known that such changes,
even tho they made sense at the time,
seemed like an omission, etc, were actually
integral to the CDR system via forkCDR.
It makes sense to me now that forkCDR didn't
natively end any CDR's, but rather depended
on natively closing them all at hangup time
via traversing and closing them all, whether
locked or not. I still don't completely
understand the benefits of setvar and answer
operating on locked cdrs, but I've seen
enough to revert those changes also, and
stop messing up users who depended on that
behavior. bug 12726 found reverting the changes
fixed his changes, and after a long review
and working on forkCDR, I can see why.
2. Apply the suggested enhancements proposed
in 10668, but in a completely compatible
way. ForkCDR will behave exactly as before,
but now has new options that will allow some
actions to be taken that will slightly
modify the outcome and side-effects of
forkCDR. Based on conversations I've had
with various people, these small tweaks
will allow some users to get the behavior
they need. For instance, users executing
forkCDR in an AGI script will find the
answer time set, and DISPOSITION set,
a situation not covered when the routines
were first written.
3. A small problem in the cdr serializer
would output answer and end times even
when they were not set. This is now
fixed.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@118880 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r118551 | tilghman | 2008-05-27 14:15:27 -0500 (Tue, 27 May 2008) | 6 lines
When showing an error message for a command, don't shorten the command output,
as it tends to confuse the user (it's fine for suggesting other commands,
however).
Reported by: seanbright (on #asterisk-dev)
Fixed by: me
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@118554 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r118465 | tilghman | 2008-05-27 13:58:09 -0500 (Tue, 27 May 2008) | 8 lines
NULL character should terminate only commands back to the core, not log
messages to the console.
(closes issue #12731)
Reported by: seanbright
Patches:
20080527__bug12731.diff.txt uploaded by Corydon76 (license 14)
Tested by: seanbright
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@118466 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a deadlock is detected, then the typical lock information will be
printed along with a backtrace of the stack for the offending threads.
Use of this requires compiling with DETECT_DEADLOCKS and having glibc
installed.
Furthermore, issuing the "core show locks" CLI command will print the
normal lock information as well as a backtraces for each lock. This
requires that DEBUG_THREADS is enabled and that glibc is installed.
All the backtrace features may be disabled by running the configure
script with --without-execinfo as an argument
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@118173 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
display this information in the "core show settings" CLI command. This is
useful if you want to verify that you're running a build with DONT_OPTIMIZE,
DEBUG_THREADS, etc.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@117756 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Until this change, all verbose messages in Asterisk's log files reported logger.c
as the source of the message.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@117693 65c4cc65-6c06-0410-ace0-fbb531ad65f3
a configuration file. As it was, only the first did so. This led to
a problem if the included file was changed (but not the configuration
file which includes it) and the second source file attempted to reload
the configuration. It would not see that the included file had changed.
In this particular example, res_phoneprov and chan_sip both loaded
sip.conf, which included a file call sip.peers.conf. Since res_phoneprov
was the first to load sip.conf, only it cached the fact that sip.conf
included sip.peers.conf. If sip.peers.conf were changed and sip.conf were
not and a sip reload were issued (meaning that chan_sip attempts to
reload sip.conf only if it and its included files have changed) the changes
made to sip.peers.conf would not be seen and therefore no action would be
taken.
(closes issue #12693)
Reported by: marsosa
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@117367 65c4cc65-6c06-0410-ace0-fbb531ad65f3
last match, and possibly skip empty fields. The function is useful
(and used here) when a form submits multiple 'Action' fields to the
Manager.
This change slightly modifies the current behaviour, but only in the
case the user supplies multiple 'Action: ' lines and the first
ones are empty, so the change is totally harmless.
+ Fix style on a couple of "if (displayconnects)" statements;
+ Expand a bit the 'Manager Test' interface, to make it slightly
more user friendly. But also comment that the HTML should not
be embedded in the C source.
None of this stuff needs to be applied to 1.4.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@117297 65c4cc65-6c06-0410-ace0-fbb531ad65f3
same name in http queries, which might confuse the manager.
Replace calls to ast_uri_decode() with a local function that also
replaces '+' with ' ', as this is the normal encoding for
spaces in http requests.
This allows passing cli commands to the manager through the
http interface.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@117295 65c4cc65-6c06-0410-ace0-fbb531ad65f3
of platform/compiler-dependent warnings when handing
struct timeval fields, both reading and printing them.
It is a lost battle to handle the different ways struct timeval
is handled on the various platforms and compilers, so try
to be pragmatic and go through int/long which are universally
supported.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@116557 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r116088 | mmichelson | 2008-05-13 18:47:49 -0500 (Tue, 13 May 2008) | 12 lines
A change to the way channel locks are handled when DEBUG_CHANNEL_LOCKS is defined.
After debugging a deadlock, it was noticed that when DEBUG_CHANNEL_LOCKS
is enabled in menuselect, the actual origin of channel locks is obscured
by the fact that all channel locks appear to happen in the function
ast_channel_lock(). This code change redefines ast_channel_lock to be a
macro which maps to __ast_channel_lock(), which then relays the proper
file name, line number, and function name information to the core lock
functions so that this information will be displayed in the case that
there is some sort of locking error or core show locks is issued.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@116089 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r115990 | russell | 2008-05-13 16:05:57 -0500 (Tue, 13 May 2008) | 5 lines
Fix an issue that I noticed in autoservice while mmichelson and I were debugging
a different problem. I noticed that it was theoretically possible for two threads
to attempt to start the autoservice thread at the same time. This change makes the
process of starting the autoservice thread, thread-safe.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@116001 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r115735 | mmichelson | 2008-05-12 12:51:14 -0500 (Mon, 12 May 2008) | 7 lines
If a thread holds no locks, do not print any information on the thread when issuing
a core show locks command. This will help to de-clutter output somewhat.
Russell said it would be fine to place this improvement in the 1.4 branch, so that's
why it's going here too.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@115737 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
new paramater. The new options for ENUM* functions include 'u', 's', 'i', and 'd' which return the full uri, trigger isn specific rewriting, look
for branches into an infrastructure enum tree, or do a direct dns lookup of a number respectively. The new paramater for TXCIDNAME adds a
zone-suffix argument for looking up caller id's in DNS that aren't e164.arpa.
This patch is based on the original code from otmar, modified by snuffy, and tested by jtodd, me, and others.
(closes issue #8089)
Reported by: otmar
Patches:
20080508_bug8089-1.diff
- original code by otmar (license 480),
- revised by snuffy (license 35)
Tested by: oej, otmar, jtodd, Corydon76, snuffy, alexnikolov, bbryant
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@115584 65c4cc65-6c06-0410-ace0-fbb531ad65f3
to use doubly linked lists. The schedule() function had an optimization that
had it try to guess which direction would be better for the traversal to insert
the task into the scheduler queue. However, if the code chose the path where
it traversed the queue in reverse, and the result was that the task should be
at the head of the queue, then the code would actually put it at the tail,
instead.
(Problem found by bbryant, debugged and fixed by bbryant and me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@115537 65c4cc65-6c06-0410-ace0-fbb531ad65f3
being #included twice. This was due to the fact that #exec created a temporary file which
was then #included. The name of the temporary file was the name of the #exec'd file, with
the Unix timestamp and thread ID concatenated. The issue was that if multiple #exec statements
of the same file were reached in the same second, then the result was that the temporary files
would have duplicate names. To resolve this, the temporary file now has microsecond resolution
for the timestamp portion.
(closes issue #12574)
Reported by: jmls
Patches:
12574.patch uploaded by putnopvut (license 60)
Tested by: jmls, putnopvut
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@115329 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A task wraps a callback function pointer and a data pointer and is managed internal to the taskprocessor subsystem. The callback function is responsible for releasing task data.
Taskprocessor API
* ast_taskprocessor_get(..) - returns a reference to a taskprocessor
* ast_taskprocessor_unreference(..) - releases reference to a taskprocessor
* ast_taskprocessor_push(..) - push a task into a taskprocessor queue
Check doxygen for more details
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@115268 65c4cc65-6c06-0410-ace0-fbb531ad65f3
and denoising to a channel, AGC() and DENOISE(). Also included, is a change
to the audiohook API to add a new function (ast_audiohook_remove) that can
remove an audiohook from a channel before it is detached.
This code is based on a contribution from Switchvox.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@114926 65c4cc65-6c06-0410-ace0-fbb531ad65f3
party to be spoken instead of the channel name or number.
This was accomplished by adding a new function pointer to point to a function in app_voicemail
which retrieves the name file and plays it. This makes for an easy way that applications may play
a user's name should it be necessary. app_directory, in particular, can be simplified greatly by
this change.
This change comes as a suggestion from Switchvox, which already has this feature. AST-23
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@114813 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Add some additional features to the core park_call_full() function, and expose
them as options to the Park() application. The functionality being added is the
ability to specify a custom return extension/context/priority, a custom timeout,
and a couple of options. The options are to play ringing instead of MOH to the
parked caller, and to randomize parking spot selection.
(code inspired by the patch in AST-17, code from switchvox)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@114655 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r114600 | russell | 2008-04-23 17:18:12 -0500 (Wed, 23 Apr 2008) | 6 lines
Improve some broken cookie parsing code. Previously, manager login over HTTP
would only work if the mansession_id cookie was first. Now, the code builds
a list of all of the cookies in the Cookie header. This fixes a problem
observed by users of the Asterisk GUI.
(closes AST-20)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@114601 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r114591 | russell | 2008-04-23 12:55:31 -0500 (Wed, 23 Apr 2008) | 5 lines
Store the manager session ID explicitly as 4 byte ID instead of a ulong. The
mansession_id cookie is coded to be limited to 8 characters of hex, and this
could break logins from 64-bit machines in some cases.
(inspired by AST-20)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@114592 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r114579 | file | 2008-04-23 11:54:11 -0300 (Wed, 23 Apr 2008) | 4 lines
Instead of stopping dialplan execution when SayNumber attempts to say a large number that it can not print out a message informing the user and continue on.
(closes issue #12502)
Reported by: bcnit
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@114580 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
Reported by: atis
Tested by: murf
This upgrade adds the ~~ (concatenation) string operator to expr2.
While not needed in normal runtime pbx operation, it is needed when
raw exprs are being syntax checked. This plays into future syntax-
unification plans. By permission of atis, this addition in trunk
and the reason of why things are as they are will suffice to close
this bug.
I also added a short note about the previous addition of "sip show sched"
to the CLI in CHANGES, which I discovered I forgot in a previous commit.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@114423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r114207 | mmichelson | 2008-04-17 11:28:03 -0500 (Thu, 17 Apr 2008) | 12 lines
It was possible for a reference to a frame which was part of a freed DSP to still be
referenced, leading to memory corruption and eventual crashes. This code change ensures
that the dsp is freed when we are finished with the frame. This change is very similar
to a change Russell made with translators back a month or so ago.
(closes issue #11999)
Reported by: destiny6628
Patches:
11999.patch uploaded by putnopvut (license 60)
Tested by: destiny6628, victoryure
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@114208 65c4cc65-6c06-0410-ace0-fbb531ad65f3
a. fix a self-found problem with SPAWN-ing an extension,
where matches were not being found
b. correct some wording in a comment
c. Add some debug for future debugging.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@114146 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r114117 | mmichelson | 2008-04-14 12:41:03 -0500 (Mon, 14 Apr 2008) | 11 lines
Increase the retry count when attempting to show channels. This apparently
cleared an issue someone was seeing when attempting to show channels when
the load was high.
(closes issue #11667)
Reported by: falves11
Patches:
11677.txt uploaded by russell (license 2)
Tested by: falves11
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@114118 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r114106 | mmichelson | 2008-04-14 09:58:02 -0500 (Mon, 14 Apr 2008) | 5 lines
Save a local copy of the generate callback prior to unlocking the channel in
case the generate callback goes NULL on us after the channel is unlocked. Thanks
to Russell for pointing this need out to me.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@114107 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r114035 | qwell | 2008-04-10 12:26:10 -0500 (Thu, 10 Apr 2008) | 10 lines
Only try to prefix language if we are not using an absolute path (suffix it otherwise).
en/var/lib/asterisk/sounds/blah.gsm is a very silly path.
(closes issue #12379)
Reported by: kuj
Patches:
12379-absolutepath.diff uploaded by qwell (license 4)
Tested by: kuj, qwell
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@114036 65c4cc65-6c06-0410-ace0-fbb531ad65f3
were handled. In 1.4, if the absolute timeout were reached on a call, no matter what
the return value of ast_spawn_extension was, the pbx would attempt to go to the 'T'
extension or hangup otherwise. The rearrangement of this function in trunk made this check
only happen in the case that ast_spawn_extension returned 0. If ast_spawn_extension returned
1, then the fact that the timeout expired resulted in a no-op, and would cause an infinite
loop to occur in __ast_pbx_run. This change fixes this problem. Now timeouts will
behave as they did in 1.4
(closes issue #11550)
Reported by: pj
Tested by: putnopvut
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@113836 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r113296 | file | 2008-04-08 12:03:43 -0300 (Tue, 08 Apr 2008) | 4 lines
If audio suddenly gets fed into one side of a channel after a lapse of frames flush the other factory so that old audio does not remain in the factory causing the sync code to not execute.
(closes issue #12296)
Reported by: jvandal
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@113297 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r113065 | mmichelson | 2008-04-07 11:08:45 -0500 (Mon, 07 Apr 2008) | 13 lines
This fix prevents a deadlock that was experienced in chan_local. There was
deadlock prevention in place in chan_local, but it would not work in a specific
case because the channel was recursively locked. By unlocking the channel prior
to calling the generator's generate callback in ast_read_generator_actions(), we
prevent the recursive locking, and therefore the deadlock.
(closes issue #12307)
Reported by: callguy
Patches:
12307.patch uploaded by putnopvut (license 60)
Tested by: callguy
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@113066 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r112468 | mmichelson | 2008-04-02 12:36:04 -0500 (Wed, 02 Apr 2008) | 13 lines
Fix a race condition in the manager. It is possible that a new manager event
could be appended during a brief time when the manager is not waiting for input.
If an event comes during this period, we need to set an indicator that there is an
event pending so that the manager doesn't attempt to wait forever for an event that
already happened.
(closes issue #12354)
Reported by: bamby
Patches:
manager_race_condition.diff uploaded by bamby (license 430)
(comments added by me)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@112469 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: falves11
Patches:
12298.patch1 uploaded by murf (license 17)
Tested by: murf
I have hopes that the changes made over the last few days will
finalize and solidify this code. While there are bound to be
small tweaks still needed, I feel that the job (at last) is
somewhat completed. Finally, I had a chance to comprehend how
the scoring of extension patterns was done in the previous
version, and I've come very close to using the exact same
criteria in the new pattern matching code. The left-right
sorting is now replicated in the trie structure itself, such
that the first match found will the 'best' match. Compared
the results against 1.4 for several extensions. Replicated
falves11's setup and it works. Used some devious patterns
provided by jsmith, supplemented with a few of my own.
Looks good.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@112289 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r111391 | murf | 2008-03-27 07:03:28 -0600 (Thu, 27 Mar 2008) | 9 lines
These small documentation updates made in response to a query in
asterisk-users, where a user was using Playback, but needed the
features of Background, and had no idea that Background existed,
or that it might provide the features he needed. I thought the
best way to avert these kinds of queries was to provide "See Also"
references in all three of "Background", "Playback", "WaitExten".
Perhaps a project to do this with all related apps is in order.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@111410 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r111245 | qwell | 2008-03-26 18:26:33 -0500 (Wed, 26 Mar 2008) | 9 lines
Remove excessive smoother optimization that was causing audio glitches (small "pops")
after (about 200ms later) an "incorrectly" sized frame was received.
While it would be very nice to keep this as optimized as possible, it makes no sense
for the smoother to be dropping random bits of audio like this. Isn't that the
whole point of a smoother?
Closes issue #12093.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@111246 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Per comments from dimas:
1. The code now generates DTMF_BEGIN frames in addition to DTMF_END ones.
2. "quelching" rewritten - now each detector (MF/DTMF/generic tone) may mark fragment of a frame for suppression (squelching, muting) with a call to mute_fragment. Actual muting happens only once at the very end of ast_dsp_process where all marked fragments are zeroed. This way every detector sees original data in the frame without any piece of a frame being zeroed by a detector which was run before.
3. DTMF detector tries to "mute" one block before and one block after the block where actual tone was detected. Muting of previois block is something new for this patch. Obviously this operation is not always possible - if current frame does not contain data for previous block - it is too late. But at least we make our best.
Muting of next block was already done by the old code but it only affects part of the next block which is in the frame being processed. New code keeps this information in state structures so it will mute proper number of samples in the next frame(s) too.
4. Removed ast_dsp_digitdetect and ast_dsp_getdigits APIs because these are not used.
5. DSP API extended a bit - ast_dsp_was_muted() function added which returns true if DSP code was muting any fragment in the last frame. chan_zap uses this function to decide it needs to turn on confmute on the channel.
This is to replace AST_FRAME_DTMF 'm'/'u' (mute/unmute) functionality.
(closes issue #11968)
Reported by: dimas
Patches:
v2-11968-dsp.patch uploaded by dimas (license 88)
v4-11968-zap.patch uploaded by dimas (license 88)
Tested by: dimas, qwell
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@111022 65c4cc65-6c06-0410-ace0-fbb531ad65f3
change, it was possible to start Asterisk with the manager interface enabled, then
either comment out the enabled option or make manager.conf unopenable and the manager
interface would still be enabled.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@110831 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@110629 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r110395 | russell | 2008-03-20 18:13:56 -0500 (Thu, 20 Mar 2008) | 9 lines
Shorten the ast_waitfor() timeout from 500 ms to 50 ms in the autoservice thread.
This really should not make a difference except in very rare cases. That case would
be that all of the channels in autoservice are not generating any frames. In that
case, this change reduces the potential amount of time that a thread waits in
ast_autoservice_stop() for the autoservice thread to wrap back around to the beginning
of its loop.
(closes issue #12266, reported by dimas)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@110396 65c4cc65-6c06-0410-ace0-fbb531ad65f3
other than 8 kHz. The issue here is that format modules give a "whennext" sample
value, which is used to calculate when to set a timer for to retrieve the next
frame. However, the zaptel timer operates on 8 kHz samples, so this must be taken
into account.
(another part of issue #12164, reported by milazzo and jsmith, patch by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@110303 65c4cc65-6c06-0410-ace0-fbb531ad65f3
G.722 music on hold working for me.
(issue #12164, reported by milazzo and jsmith, patches by me)
res/res_musiconhold.c:
- I moved a single line so that the sample queue update happened before
ast_write(). The reason that this was a bug is that the G.722 frame
originally says it has 320 samples in it (which is correct). However,
when the frame is written to a channel that uses RTP, main/rtp.c modifies
the frame to cut the number of samples in half before it sends it on
the wire. This is to account for the stupid incorrect G.722 spec that
makes it so we have to lie about the number of samples with RTP. I should
probably go and re-work the RTP code so it doesn't modify the frame so
that a bug like this won't happen in the future. However, this change to
MOH is harmless.
main/channel.c:
- I made two fixes in regards to generator timing. Generators use samples
for timing. However, this code assumed 8 kHz samples. In one case, it was
a hard coded 160 samples, that is now written as the sample rate / 50. The
other place was dealing with timing a generator based on frames coming from
the other direction. However, that would have only worked if the sample
rates for the formats in both directions were the same. The code now takes
into account that the sample rates may differ, and scales the generator
samples accordingly.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@110268 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r110019 | file | 2008-03-19 15:20:28 -0300 (Wed, 19 Mar 2008) | 6 lines
Make sure that the mark bit does not incorrectly cause video frame timestamps to be calculated as if they are audio frames.
(closes issue #11429)
Reported by: sperreault
Patches:
11429-frametype.diff uploaded by qwell (license 4)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@110020 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r109908 | murf | 2008-03-19 09:41:13 -0600 (Wed, 19 Mar 2008) | 72 lines
(closes issue #11442)
Reported by: tzafrir
Patches:
11442.patch uploaded by murf (license 17)
Tested by: murf
I didn't give tzafrir very much time to test this, but if he does
still have remaining issues, he is welcome to
re-open this bug, and we'll do what is called for.
I reproduced the problem, and tested the fix, so I hope I
am not jumping by just going ahead and committing the fix.
The problem was with what file_save does with templates;
firstly, it tended to print out multiple options:
[my_category](!)(templateref)
instead of
[my_category](!,templateref)
which is fixed by this patch.
Nextly, the code to suppress output of duplicate declarations
that would occur because the reader copies inherited declarations
down the hierarchy, was not working. Thus:
[master-template](!)
mastervar = bar
[template](!,master-template)
tvar = value
[cat](template)
catvar = val
would be rewritten as:
;!
;! Automatically generated configuration file
;! Filename: experiment.conf (/etc/asterisk/experiment.conf)
;! Generator: Manager
;! Creation Date: Tue Mar 18 23:17:46 2008
;!
[master-template](!)
mastervar = bar
[template](!,master-template)
mastervar = bar
tvar = value
[cat](template)
mastervar = bar
tvar = value
catvar = val
This has been fixed. Since the config reader 'explodes' inherited
vars into the category, users may, in certain circumstances, see
output different from what they originally entered, but it should
be both correct and equivalent.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109942 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
This does introduce a dependency on the GMime library for handling HTTP POSTs, but it is available in most distros.
If the library is present, then the compile flag for ENABLE_UPLOADS is enabled by default in menuselect.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109229 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r109226 | mmichelson | 2008-03-17 17:05:49 -0500 (Mon, 17 Mar 2008) | 12 lines
Fix a logic flaw in the code that stores lock info which is displayed
via the "core show locks" command. The idea behind this section of code was
to remove the previous lock from the list if it was a trylock that had failed.
Unfortunately, instead of checking the status of the previous lock, we were referencing
the index immediately following the previous lock in the lock_info->locks array.
The result of this problem, under the right circumstances, was that the lock which
we currently in the process of attempting to acquire could "overwrite" the previous lock
which was acquired. While this does not in any way affect typical operation, it *could*
lead to misleading "core show locks" output.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109227 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: mvanbaak
Tested by: murf, mvanbaak
Due to a bug that occurred when merge_contexts_and_delete scanned the "old" or existing contexts, and found a context
that doesn't exist in the new set, yet owned by a different registrar. The context is created in the new set, with the
old registrar, and and all the priorities and extens that have a different registrar are copied into it. But, not the
includes, ignorepats, and switches. I added code to do this immediately after the context is created.
This still leaves a logical hole in the code. If you define a context in two places, (eg. in extensions.conf and also
in extensions.ael), and they both have includes, but different in composition, no new context will be generated, and
therefore the 'old' includes, switches, and ignorepats will not be copied. I'd have added code to simply add any non-duplicates
into the 'new' context that had a different registrar, but there is one big complication: includes, and switches are definitely
order dependent. (ignorepats I'm not sure about). And we'll have to develop some sort of policy about how we
merge order dependent lists, especially if the intersection of the two sets is empty. (in other words, they do not have any
elements in common). Do the new go first, or the old? I've elected to punt this issue until a user complains. Hopefully,
this is pretty rare thing.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109169 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r108583 | russell | 2008-03-13 16:38:16 -0500 (Thu, 13 Mar 2008) | 11 lines
Fix another issue that was causing crashes in chanspy. This introduces a new
datastore callback, called chan_fixup(). The concept is exactly like the
fixup callback that is used in the channel technology interface. This callback
gets called when the owning channel changes due to a masquerade. Before this
was introduced, if a masquerade happened on a channel being spyed on, the
channel pointer in the datastore became invalid.
(closes issue #12187)
(reported by, and lots of testing from atis)
(props to file for the help with ideas)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@108584 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Though this overflow is exploitable remotely, we are NOT issuing a security
advisory for this since in order to exploit the overflow, the attacker would
have to establish an authenticated manager session AND have the system privilege.
By gaining this privilege, the attacker already has more powerful weapons at his
disposal than overflowing a buffer with a malformed manager header, so the vulnerability
in this case really lies with the authentication method that allowed the attacker to
gain the system privilege in the first place.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@108529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r108135 | russell | 2008-03-12 14:57:42 -0500 (Wed, 12 Mar 2008) | 40 lines
(closes issue #12187, reported by atis, fixed by me after some brainstorming
on the issue with mmichelson)
- Update copyright info on app_chanspy.
- Fix a race condition that caused app_chanspy to crash. The issue was that
the chanspy datastore magic that was used to ensure that spyee channels did
not disappear out from under the code did not completely solve the problem.
It was actually possible for chanspy to acquire a channel reference out of
its datastore to a channel that was in the middle of being destroyed. That
was because datastore destruction in ast_channel_free() was done near the
end. So, this left the code in app_chanspy accessing a channel that was
partially, or completely invalid because it was in the process of being free'd
by another thread. The following sort of shows the code path where the race
occurred:
=============================================================================
Thread 1 (PBX thread for spyee chan) || Thread 2 (chanspy)
--------------------------------------||-------------------------------------
ast_channel_free() ||
- remove channel from channel list ||
- lock/unlock the channel to ensure ||
that no references retrieved from ||
the channel list exist. ||
--------------------------------------||-------------------------------------
|| channel_spy()
- destroy some channel data || - Lock chanspy datastore
|| - Retrieve reference to channel
|| - lock channel
|| - Unlock chanspy datastore
--------------------------------------||-------------------------------------
- destroy channel datastores ||
- call chanspy datastore d'tor ||
which NULL's out the ds' || - Operate on the channel ...
reference to the channel ||
||
- free the channel ||
||
|| - unlock the channel
--------------------------------------||-------------------------------------
=============================================================================
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@108137 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r108083 | file | 2008-03-12 15:26:37 -0300 (Wed, 12 Mar 2008) | 4 lines
Add a trigger mode that triggers on both read and write. The actual function that returns the combined audio frame though will wait until both sides have fed in audio, or until one side stops (such as the case when you call Wait).
(closes issue #11945)
Reported by: xheliox
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@108084 65c4cc65-6c06-0410-ace0-fbb531ad65f3
caching would not work properly for users.conf and any other file read from
more than one place. I needed to add the filename which requested the config
file to get it to work properly.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@107791 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r107352 | kpfleming | 2008-03-11 06:04:29 -0500 (Tue, 11 Mar 2008) | 11 lines
fix up various compiler warnings found with gcc-4.3:
- the output of flex includes a static function called 'input' that is not used, so for the moment we'll stop having the compiler tell us about unused variables in the flex source files (a better fix would be to improve our flex post-processing to remove the unused function)
- main/stdtime/localtime.c makes assumptions about signed integer overflow, and gcc-4.3's improved optimizer tries to take advantage of handling potential overflow conditions at compile time; for now, suppress these optimizations until we can fiure out if the code needs improvement
- main/udptl.c has some references to uninitialized variables; in one case there was no bug, but in the other it was certainly possibly for unexpected behavior to occur
- main/editline/readline.c had an unused variable
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@107373 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r107161 | russell | 2008-03-10 15:17:11 -0500 (Mon, 10 Mar 2008) | 8 lines
Fix another bug specifically related to asynchronous call origination. Once the
PBX is started on the channel using ast_pbx_start(), then the ownership of the
channel has been passed on to another thread. We can no longer access it in this
code. If the channel gets hung up very quickly, it is possible that we could
access a channel that has been free'd.
(inspired by BE-386)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@107162 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r107158 | russell | 2008-03-10 15:04:27 -0500 (Mon, 10 Mar 2008) | 9 lines
Fix some bugs related to originating calls. If the code failed to start a PBX
on the channel (such as if you set a call limit based on the system's load
average), then there were cases where a channel that has already been free'd
using ast_hangup() got accessed. This caused weird memory corruption and
crashes to occur.
(fixes issue BE-386)
(much debugging credit goes to twilson, final patch written by me)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@107159 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
Fix a number of other places where the number of samples in a G722 frame was
not properly handled because of various reasons.
main/rtp.c:
- When a G722 frame is read from the smoother, the number of samples in the
frame must be divided by 2 before being sent out over the network. Even
though G722 is 16 kHz, an error in some previous spec has made it so that
we have to list the number of samples such as if it was 8 kHz.
main/file.c:
- When scheduling the next time to expect a frame, take into account that the
format of the file we're reading from may not be 8 kHz.
codecs/codec_g722.c:
- When converting from G722 to slinear, g722_decode() expects its samples
parameter to be in the silly (real samples / 2) format. Make it so.
- When converting from slinear to G722, properly set the number of samples in
the frame to be the number of bytes of output * 2.
formats/format_pcm.c:
- This format module handles G722, among a number of other formats. However,
the read() and seek() functions did not account for the fact that G722 has
2 samples per byte.
(closes issue #12130, reported by rickross, patched by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@106501 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r106437 | mmichelson | 2008-03-06 16:10:07 -0600 (Thu, 06 Mar 2008) | 8 lines
Quell an annoying message that is likely to print every single time that
ast_pbx_outgoing_app is called. The reason is that __ast_request_and_dial
allocates the cdr for the channel, so it should be expected that the channel
will have a cdr on it.
Thanks to joetester on IRC for pointing this out
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@106438 65c4cc65-6c06-0410-ace0-fbb531ad65f3
an attended transfer over AMI
(closes issue #10585)
Reported by: ornati
Patches:
atxfer-trunk-r90428.diff uploaded by ornati (license 210)
(with modifications from me)
Tested by: putnopvut
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@106236 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r105932 | russell | 2008-03-04 19:52:18 -0600 (Tue, 04 Mar 2008) | 5 lines
Fix a bug that I just noticed in the RTP code. The calculation for setting the
len field in an ast_frame of audio was wrong when G.722 is in use. The len field
represents the number of ms of audio that the frame contains. It would have
set the value to be twice what it should be.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@105933 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r105674 | file | 2008-03-04 14:05:28 -0400 (Tue, 04 Mar 2008) | 8 lines
When a new source of audio comes in (such as music on hold) make sure the marker bit gets set.
(closes issue #10355)
Reported by: wdecarne
Patches:
10355.diff uploaded by file (license 11)
(closes issue #11491)
Reported by: kanderson
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@105675 65c4cc65-6c06-0410-ace0-fbb531ad65f3
LIST instead of an RWLIST. The way this list works makes it such that
a RWLIST provides no additional benefit. Also, a mutex is needed for
use with the thread condition.
Merged revisions 105563 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r105563 | russell | 2008-03-03 09:50:43 -0600 (Mon, 03 Mar 2008) | 24 lines
Merge in some changes from team/russell/autoservice-nochans-1.4
These changes fix up some dubious code that I came across while auditing what
happens in the autoservice thread when there are no channels currently in
autoservice.
1) Change it so that autoservice thread doesn't keep looping around calling
ast_waitfor_n() on 0 channels twice a second. Instead, use a thread condition
so that the thread properly goes to sleep and does not wake up until a
channel is put into autoservice.
This actually fixes an interesting bug, as well. If the autoservice thread
is already running (almost always is the case), then when the thread goes
from having 0 channels to have 1 channel to autoservice, that channel would
have to wait for up to 1/2 of a second to have the first frame read from it.
2) Fix up the code in ast_waitfor_nandfds() for when it gets called with no
channels and no fds to poll() on, such as was the case with the previous code
for the autoservice thread. In this case, the code would call alloca(0), and
pass the result as the first argument to poll(). In this case, the 2nd
argument to poll() specified that there were no fds, so this invalid pointer
shouldn't actually get dereferenced, but, this code makes it explicit and
ensures the pointers are NULL unless we have valid data to put there.
(related to issue #12116)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@105564 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r105560 | file | 2008-03-03 11:28:59 -0400 (Mon, 03 Mar 2008) | 7 lines
It is possible for no audio to pass between the current digit and next digit so expand logic that clears emulation to AST_FRAME_NULL.
(closes issue #11911)
Reported by: edgreenberg
Patches:
v1-11911.patch uploaded by dimas (license 88)
Tested by: tbsky
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@105561 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r105409 | russell | 2008-02-29 17:34:32 -0600 (Fri, 29 Feb 2008) | 23 lines
Fix a major bug in autoservice. There was a race condition in the handling of
the list of channels in autoservice. The problem was that it was possible for
a channel to get removed from autoservice and destroyed, while the autoservice
thread was still messing with the channel. This led to memory corruption, and
caused crashes. This explains multiple backtraces I have seen that have
references to autoservice, but do to the nature of the issue (memory corruption),
could cause crashes in a number of areas.
(fixes the crash in BE-386)
(closes issue #11694)
(closes issue #11940)
The following issues could be related. If you are the reporter of one of these,
please update to include this fix and try again.
(potentially fixes issue #11189)
(potentially fixes issue #12107)
(potentially fixes issue #11573)
(potentially fixes issue #12008)
(potentially fixes issue #11189)
(potentially fixes issue #11993)
(potentially fixes issue #11791)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@105410 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r105116 | russell | 2008-02-28 16:23:05 -0600 (Thu, 28 Feb 2008) | 8 lines
Fix a bug in the lock tracking code that was discovered by mmichelson. The issue
is that if the lock history array was full, then the functions to mark a lock as
acquired or not would adjust the stats for whatever lock is at the end of the array,
which may not be itself. So, do a sanity check to make sure that we're updating
lock info for the proper lock.
(This explains the bizarre stats on lock #63 in BE-396, thanks Mark!)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@105144 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r104841 | mmichelson | 2008-02-27 15:49:20 -0600 (Wed, 27 Feb 2008) | 17 lines
Two fixes:
1. Make the list of ast_dial_channels a lockable list. This is because in some cases,
the ast_dial may exist in multiple threads due to asynchronous execution of its application, and
I found some cases where race conditions could exist.
2. Check in ast_dial_join to be sure that the channel still exists before attempting to lock it, since
it could have gotten hung up but the is_running_app flag on the ast_dial_channel may not have been
cleared yet.
(closes issue #12038)
Reported by: jvandal
Patches:
12038v2.patch uploaded by putnopvut (license 60)
Tested by: jvandal
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@105060 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r105005 | qwell | 2008-02-28 13:20:10 -0600 (Thu, 28 Feb 2008) | 9 lines
Make pbx_exec pass an empty string into applications, if we get NULL.
This protects against possible segfaults in applications that may try
to use data before checking length (ast_strdupa'ing it, for example)
(closes issue #12100)
Reported by: foxfire
Patches:
12100-nullappargs.diff uploaded by qwell (license 4)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@105006 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r104593 | kpfleming | 2008-02-27 10:53:06 -0600 (Wed, 27 Feb 2008) | 8 lines
fallback to standard English prompts properly when using new prompt directory layout
(closes issue #11831)
Reported by: IgorG
Patches:
fallbacken.v1.diff uploaded by IgorG (license 20) (modified by me to improve code and conform rest of function to coding guidelines)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@104594 65c4cc65-6c06-0410-ace0-fbb531ad65f3
automatically generated file like it used to be. This still needs to be there
for modules that have to check it to compile against multiple asterisk versions.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@104244 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r104102 | russell | 2008-02-25 17:19:05 -0600 (Mon, 25 Feb 2008) | 7 lines
Improve the lock tracking code a bit so that a bunch of old locks that threads
failed to lock don't sit around in the history. When a lock is first locked,
this checks to see if the last lock in the list was one that was failed to be
locked. If it is, then that was a lock that we're no longer sitting in a trylock
loop trying to lock, so just remove it.
(inspired by issue #11712)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@104103 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r104092 | qwell | 2008-02-25 14:49:42 -0600 (Mon, 25 Feb 2008) | 11 lines
Allow the use of #include and #exec in situations where the max include depth was only 1.
Specifically, this fixes using #include and #exec in extconfig.conf.
This was basically caused because the config file itself raises the include level to 1.
I opted not to raise the include limit, because recursion here could cause very bizarre behavior.
Pointed out, and tested by jmls
(closes issue #12064)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@104093 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r103786 | mmichelson | 2008-02-18 14:52:09 -0600 (Mon, 18 Feb 2008) | 10 lines
There was an invalid assumption when calculating the duration of a file that the filestream in question
was created properly. Unfortunately this led to a segfault in the situation where an unknown format was
specified in voicemail.conf and a voicemail was recorded. Now, we first check to be sure that the stream
was written correctly or else assume a zero duration.
(closes issue #12021)
Reported by: jakep
Tested by: putnopvut
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103787 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r103780 | tilghman | 2008-02-18 11:31:52 -0600 (Mon, 18 Feb 2008) | 9 lines
When a SIP channel is being auto-destroyed, it's possible for it to still be
in bridge code. When that happens, we crash. Delay the RTP destruction until
the bridge is ended.
(closes issue #11960)
Reported by: norman
Patches:
20080215__bug11960__2.diff.txt uploaded by Corydon76 (license 14)
Tested by: norman
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103781 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r103728 | russell | 2008-02-15 13:50:11 -0600 (Fri, 15 Feb 2008) | 4 lines
In the case that you try to directly reload a module has returned
AST_MODULE_LOAD_DECLINE, log a message indicating that the module is not fully
initialized and must be initialized using "module load".
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103729 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r103726 | russell | 2008-02-15 12:33:29 -0600 (Fri, 15 Feb 2008) | 6 lines
Don't attempt to execute the reload callback for a module that returned
AST_MODULE_LOAD_DECLINE. This fixes a crash that was reported against
chan_console in trunk.
(closes issue #11953, reported by junky, fixed by me)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103727 65c4cc65-6c06-0410-ace0-fbb531ad65f3
to indicate there was more data than there really was, causing the iterator read beyond the end
of the event structure. This led to invalid memory reads and potential crashes.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103559 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Added ability to retrieve list of categories in a config file.
Added ability to retrieve the content of a particular category.
Added ability to empty a context.
Created new action to create a new file.
Updated delete action to allow deletion by line number with respect to category.
Added new action insert to add new variable to category at specified line.
Updated action newcat to allow new category to be inserted in file above another existing category.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103331 65c4cc65-6c06-0410-ace0-fbb531ad65f3
in the event API.
ast_event_iterator_get_ie_type should return the ie type in
host byte order. Furthermore, ast_event_get_ie_raw should already
have its ie type argument in host byte order since it could be called
externally (and it in fact is called in this way by ast_event_get_cached).
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103282 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
........
r101601 | russell | 2008-01-31 17:10:06 -0600 (Thu, 31 Jan 2008) | 12 lines
Fix a couple of places where ast_frfree() was not called on a frame that came
from a translator. This showed itself by g729 decoders not getting released.
Since the flag inside the translator frame never got unset by freeing the frame
to indicate it was no longer in use, the translators never got destroyed, and
thus the g729 licenses were not released.
(closes issue #11892)
Reported by: xrg
Patches:
11892.diff uploaded by russell (license 2)
Tested by: xrg, russell
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@101611 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r101222 | file | 2008-01-30 11:41:04 -0400 (Wed, 30 Jan 2008) | 4 lines
Fix an issue where if a frame of higher sample size preceeded a frame of lower sample size and ast_slinfactory_read was called with a sample size of the combined values or higher a crash would happen.
(closes issue #11878)
Reported by: stuarth
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@101223 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r100581 | russell | 2008-01-28 11:15:41 -0600 (Mon, 28 Jan 2008) | 9 lines
Make some deadlock related fixes. These bugs were discovered and reported
internally at Digium by Steve Pitts.
- Fix up chan_local to ensure that the channel lock is held before the local
pvt lock.
- Don't hold the channel lock when executing the timing function, as it can
cause a deadlock when using chan_local. This actually changes the code back
to be how it was before the change for issue #10765. But, I added some other
locking that I think will prevent the problem reported there, as well.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@100582 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Tilghman Lesher
Steve Murphy
Eliel C. Sardanons
Sean Bright
Kevin P. Fleming
Russell Bryant
Mark Michelson
Terry Wilson
BJ Weschke
Michiel van Baak
Olle Johansson
Jeff Peeler
Richard Mudgett
Dwayne M. Hubbard
Brett Bryant
Brandon Kruse
Pari Nannapaneni
Matthew Fredrickson
Joshua Colp
Luigi Rizzo
Jason Parker
Doug Bailey