Age | Commit message (Collapse) | Author | Files | Lines |
|
git-svn-id: http://svn.digium.com/svn/asterisk/tags/1.4.19-rc1@105671 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/tags/1.4.19-rc1@105670 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/tags/1.4.19-rc1@105669 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/tags/1.4.19-rc1@105667 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
cleanup. Properly break out of the loop when a context isn't found when
verify that includes are valid.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@105591 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #12114)
Reported by: jeffg
Patches:
12114.patch uploaded by jeffg (license 192)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@105572 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
pvt list before destroying it.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@105570 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
fails. Also, in passing, centralize the code necessary to destroy a local_pvt.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@105568 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
now is stuff that I have written recently ...
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@105565 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@105563 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@105560 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #12120)
Reported by: flefoll
Patches:
chan_sip.c.br14.patch-just-a-comment uploaded by flefoll (license 244)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@105557 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@105409 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@105326 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(Closes issue #12108)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@105296 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #12107)
Reported by: asgaroth
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@105261 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
type subscribed.
(closes issue #12066)
Reported by: ffadaie
Patches:
branch-1.4-12066-1.diff uploaded by phsultan (license 73)
trunk-12066-1.diff uploaded by phsultan (license 73)
Tested by: ffadaie, phsultan
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@105209 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@105116 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #9843)
Reported by: ibc
Patches:
rc.debian.asterisk.patch uploaded by ibc (license 211)
Tested by: paravoid
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@105113 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
number of available members to call if ringinuse is set to yes.
Thanks to jmls who brought this issue up on IRC
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@105059 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@105005 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@104920 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #12081)
Reported by: jcollie
Patches:
asterisk-1.4.18-funcdesc.patch uploaded by jcollie (license 412)
Tested by: jcollie, Corydon76
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@104868 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@104841 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
forget to free/detach the datastore upon hangup of the spy.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@104787 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
like crazy on every fileexists_core call.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@104783 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@104704 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@104665 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
being able to detect that the calling channel hung up.
(closes issue #12076, reported by junky, patched by me)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@104625 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #11682)
Reported by: caio1982
Patches:
local_atxfer_lang3-1.4.diff uploaded by caio1982 (license 22)
Tested by: caio1982, victoryure
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@104598 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
list to protect the contents instead of the overall module list lock.
(closes issue #12080)
Reported by: ChaseVenters
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@104596 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@104593 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
still
set to make sure that when we come back out of alarm, it gets reported in the log
and manager interface (after discussion with tzafrir on the -dev list)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@104591 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #12086)
Reported by: francesco_r
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@104536 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #12076, reported by junky, patched by me)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@104334 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
does not know what to do with these alarms. Only Asterisk 1.6 cares about it.
So, if we get an unknown alarm in chan_zap, don't generate confusing log messages
about it.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@104332 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@104141 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
tries to use a literal "~" in DESTDIR.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@104139 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
...abspath is new in GNU make 3.81. I feel so...defeated.
Must find new fix!
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@104135 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
DESTDIR that
wasn't an absolute path (such as DESTDIR=~/asterisk-1.4).
Apparently what was happening, was that some of the targets were being expanded to
the full path, so $@ ended up being /root/asterisk-1.4/[...]/ rather than ~/asterisk-1.4/[...]/
It appears that this may be a new "feature" in GNU make.
(*cough* http://en.wikipedia.org/wiki/Principle_of_least_surprise *cough*)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@104132 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This commit brings in a significant set of changes to the SMDI support in Asterisk.
There were a number of bugs in the current implementation, most notably being that
it was very likely on busy systems to pop off the wrong message from the SMDI message
queue. So, this set of changes fixes the issues discovered as well as introducing
some new ways to use the SMDI support which are required to avoid the bugs with
grabbing the wrong message off of the queue.
This code introduces a new interface to SMDI, with two dialplan functions. First,
you get an SMDI message in the dialplan using SMDI_MSG_RETRIEVE() and then you access
details in the message using the SMDI_MSG() function. A side benefit of this is that
it now supports more than just chan_zap.
For example, with this implementation, you can have some FXO lines being terminated
on a SIP gateway, but the SMDI link in Asterisk.
Another issue with the current implementation is that it is quite common that the
station ID that comes in on the SMDI link is not necessarily the same as the Asterisk
voicemail box. There are now additional directives in the smdi.conf configuration
file which let you map SMDI station IDs to Asterisk voicemail boxes.
Yet another issue with the current SMDI support was related to MWI reporting over
the SMDI link. The current code could only report a MWI change when the change
was made by someone calling into voicemail. If the change was made by some other
entity (such as with IMAP storage, or with a web interface of some kind), then the
MWI change would never be sent. The SMDI module can now poll for MWI changes if
configured to do so.
This work was inspired by and primarily done for the University of Pennsylvania.
(also related to issue #9260)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@104119 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #12050)
Reported by: asgaroth
Patches:
12050.patch uploaded by putnopvut (license 60)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@104111 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
pointers to channels that are being spied upon. It was very likely that a
crash would occur if the channel being spied upon hung up. This was because
the current ast_channel handling _requires_ that the object is locked or else
it could disappear at any time (except in the owning channel thread). So, this
patch uses some channel datastore magic on the spied upon channel to be able to
detect if and when the channel goes away.
(closes issue #11877)
(patch written by me, but thanks to kpfleming for the idea, and to file for review)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@104106 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@104102 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
user will be used for inbound authentication for the device, and peer will be used for placing calls to the device.
(closes issue #9044)
Reported by: queuetue
Patches:
sip-gui-friend.diff uploaded by qwell (license 4)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@104095 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #12065)
Reported by: selsky
Patch by: (myself)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@104094 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@104092 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
could cause a crash.
(fixes the crash reported in BE-396)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@104086 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
remote side that the dialog does not exist so they subscribe again using a new dialog.
(closes issue #10727)
Reported by: s0l4rb03
Patches:
10727-2.diff uploaded by file (license 11)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@104084 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
to use ast_strlen_zero to see if it's actually blank.
(closes issue #12061)
Reported by: flefoll
Patches:
chan_sip.c.br14.patch_pedantic_no_totag uploaded by flefoll (license 244)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@104082 f38db490-d61c-443f-a65b-d21fe96a405b
|