Age | Commit message (Collapse) | Author | Files | Lines |
|
* The queue_transfer_fixup function was searching for and removing
the datastore from the incorrect channel, so this was fixed.
* Most datastore operations regarding the queue_transfer datastore
were being done without the channel locked, so proper channel locking
was added, too.
(closes issue #14086)
Reported by: ZX81
Patches:
14086v2.patch uploaded by putnopvut (license 60)
Tested by: ZX81, festr
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@168628 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
change gets rid of the warning.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@168608 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
The number of available slots for calls in app_page was hardcoded to 128.
Proper bounds checking was not in place to enforce this limit, so if more than
128 extensions were passed to the Page() app, Asterisk would crash. This patch
instead dynamically allocates memory for the ast_dial structures and removes
the (non-functional) arbitrary limit.
This issue would have special importance to anyone who is dynamically creating
the argument passed to the Page application and allowing more than 128
extensions to be added by an outside user via some external interface.
The patch posted by a_villacis was slightly modified for some coding guidelines
and other cleanups. Thanks, a_villacis!
(closes issue #14217)
Reported by: a_villacis
Patches:
20080912-asterisk-app_page-fix-buffer-overflow.patch uploaded by a (license 660)
Tested by: otherwiseguy
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@168593 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@168561 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
These changes eliminate the need for (and use of)
the KEEPALIVE return code in res_features.c;
There are other places that use this result code
for similar purposes at a higher level, these appear
to be left alone in 1.4, but attacked in trunk.
The reason these changes are being made in 1.4, is
that parking ends a channel's life, in some situations,
and the code in the bridge (and some other places),
was not checking the result code properly, and dereferencing
the channel pointer, which could lead to memory corruption
and crashes.
Calling the masq_park function eliminates this danger
in higher levels.
A series of previous commits have replaced some parking calls
with masq_park, but this patch puts them ALL to rest,
(except one, purposely left alone because a masquerade
is done anyway), and gets rid of the code that tests
the KEEPALIVE result, and the NOHANGUP_PEER result codes.
While bug 13820 inspired this work, this patch does
not solve all the problems mentioned there.
I have tested this patch (again) to make sure I have
not introduced regressions.
Crashes that occurred when a parked party hung up
while the parking party was listening to the numbers
of the parking stall being assigned, is eliminated.
These are the cases where parking code may be activated:
1. Feature one touch (eg. *3)
2. Feature blind xfer to parking lot (eg ##700)
3. Run Park() app from dialplan (eg sip xfer to 700)
(eg. dahdi hookflash xfer to 700)
4. Run Park via manager.
The interesting testing cases for parking are:
I. A calls B, A parks B
a. B hangs up while A is getting the numbers announced.
b. B hangs up after A gets the announcement, but
before the parking time expires
c. B waits, time expires, A is redialed,
A answers, B and A are connected, after
which, B hangs up.
d. C picks up B while still in parking lot.
II. A calls B, B parks A
a. A hangs up while B is getting the numbers announced.
b. A hangs up after B gets the announcement, but
before the parking time expires
c. A waits, time expires, B is redialed,
B answers, A and B are connected, after
which, A hangs up.
d. C picks up A while still in parking lot.
Testing this throroughly involves acting all the permutations
of I and II, in situations 1,2,3, and 4.
Since I added a few more changes (ALL references to KEEPALIVE in the bridge
code eliimated (I missed one earlier), I retested
most of the above cases, and no crashes.
H-extension weirdness.
Current h-extension execution is not completely
correct for several of the cases.
For the case where A calls B, and A parks B, the
'h' exten is run on A's channel as soon as the park
is accomplished. This is expected behavior.
But when A calls B, and B parks A, this will be
current behavior:
After B parks A, B is hung up by the system, and
the 'h' (hangup) exten gets run, but the channel
mentioned will be a derivative of A's...
Thus, if A is DAHDI/1, and B is DAHDI/2,
the h-extension will be run on channel
Parked/DAHDI/1-1<ZOMBIE>, and the
start/answer/end info will be those
relating to Channel A.
And, in the case where A is reconnected to
B after the park time expires, when both parties
hang up after the joyful reunion, no h-exten
will be run at all.
In the case where C picks up A from the
parking lot, when either A or C hang up,
the h-exten will be run for the C channel.
CDR's are a separate issue, and not addressed
here.
As to WHY this strange behavior occurs,
the answer lies in the procedure followed
to accomplish handing over the channel
to the parking manager thread. This procedure
is called masquerading. In the process,
a duplicate copy of the channel is created,
and most of the active data is given to the
new copy. The original channel gets its name
changed to XXX<ZOMBIE> and keeps the PBX
information for the sake of the original
thread (preserving its role as a call
originator, if it had this role to begin
with), while the new channel is without
this info and becomes a call target (a
"peer").
In this case, the parking lot manager
thread is handed the new (masqueraded)
channel. It will not run an h-exten
on the channel if it hangs up while
in the parking lot. The h exten will
be run on the original channel instead,
in the original thread, after the bridge
completes.
See bug 13820 for our intentions as
to how to clean up the h exten behavior.
Review: http://reviewboard.digium.com/r/29/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@166093 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Reported by: tzafrir
Replace a bunch of if defined checks for Zaptel/DAHDI through several new defines in dahdi_compat.h. This removes a lot of code duplication. Example from bug:
#ifdef HAVE_ZAPTEL
fd = open("/dev/zap/pseudo", O_RDWR);
#else
fd = open("/dev/dahdi/pseudo", O_RDWR);
#endif
is replaced with:
fd = open(DAHDI_FILE_PSEUDO, O_RDRW);
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@165991 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This patch resolved some random crash issues observed by a user on a BSD system
(closes issue #14111)
Reported by: ys
Patches:
app_chanspy.c.diff uploaded by ys (license 281)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@165889 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
certain crashes, especially when shared mailboxes are used.
(closes issue #13653)
Reported by: howardwilkinson
Patches:
asterisk-1.4.21.2-appvoicemail-sharedimap-lock.patch uploaded by howardwilkinson (license 590)
Tested by: jpeeler
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@165767 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #14106)
Reported by: ys
Patches:
app_followme.c.2.diff uploaded by ys (license 281)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@165537 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(Closes issue #13962, closes issue #13363)
Fixed by myself (license 14)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@165317 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
configs are handled.
Also cleaned up some coding guidelines violations in app_realtime.c,
mostly related to spacing
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@165255 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This is a bug I noticed while looking at the code for app_macro. This return code
means that another thread has assumed ownership of the channel and it can no longer
be touched. (I hate this return code with a passion, by the way.)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@164876 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #14074)
Reported by: wetwired
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@164204 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
can better detect an exceptional case. This follows on to the changes made
in revision 156386. Related to issue #13851.
(closes issue #13974)
Reported by: paradise
Patches:
20081208__bug13974.diff.txt uploaded by Corydon76 (license 14)
Tested by: file, blitzrage, ZX81
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@164082 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
FreeBSD 32-bit build.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@163084 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This patch also contains a conversion from using long to time_t
for representing times for a queue, as well as some whitespace
fixes.
(closes issue #14060)
Reported by: nivek
Patches:
datastore_fixup.patch.corrected uploaded by nivek (license 636)
with slight modification from me
Tested by: nivek
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@163080 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@162463 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
without actually having implemented it. Oops.
(Reported by Olivier on the -users list)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@162348 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
receive session progress when dialing a device and not ringing.
(closes issue #14005)
Reported by: ddl
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@162341 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
hear ringback.
We need to make sure that we don't start writing audio to the trunk channel until we're
actually ready to answer it. Otherwise, the channel driver will treat it as inband
progress, even though all they are getting is silence.
(closes issue #12471)
Reported by: mthomasslo
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@162286 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #14038)
Reported by: ffloimair
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@162273 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #13330)
Reported by: jcovert
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@162014 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@160770 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
and glibc.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@160207 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@159096 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(Closes issue #13863)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@159025 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
completely unrelated commit. Thanks to Theo Belder
on the Asterisk-dev list for pointing this out.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@158306 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
that ast_call() fails. For incoming SIP channels, this was causing
us to send a 603 instead of a 486 when the call-limit was reached on
the destination channel.
(closes issue #13867)
Reported by: still_nsk
Patches:
13867.diff uploaded by putnopvut (license 60)
Tested by: blitzrage
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@158053 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Reported by: akkornel
This fix is the result of a bug fix in ast_app_separate_args r124395. If an argument does not exist it should always be set to a null string rather than a null pointer.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@157365 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
app_followme which would occur at the end of an attended
transfer. The error occurred because we initially stored
a pointer to an ast_channel which then was hung up due
to a masquerade.
This commit adds a "fixup" callback to the bridge_config
structure to allow for end_bridge_callback_data to be
changed in the case that a new channel pointer is needed
for the end_bridge_callback.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@157305 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
resulted in the password not being saved, even if the input matched
what you gave when first prompted to enter a new password. This is
because the return value of ast_readstring was checked, but not checked
properly.
This bug was discovered by Jared Smith during an Asterisk training course.
Thanks for reporting it!
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@156816 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
reason. This prevents While/EndWhile from working within the "h"
extension.
Reported by: jgalarneau (for ABE C.2)
Fixed by: me
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@156755 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
instead.
(closes issue #13851)
Reported by: ruddy
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@156386 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #13889)
Reported by: eliel
Patches:
app_meetme.c.patch uploaded by eliel (license 64)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@156294 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
uninitialized variable when compiling 1.6.1.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@156289 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Reported by: pep
This change adds an announce_thread responsible for playing announcements to an existing conference. This allows all announcing to be immediately stopped if necessary but more importantly allows other threads that need to play something to not block. There are multiple benefits to this, but the actual bug is for solving the scenario for a channel to be unusable after hang up for the entire duration of the parting announcement. The parting announcement can be extremely long depending on what the user recorded upon joining the conference.
Reviewed by Russell on Review Board:
http://reviewboard.digium.com/r/25/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@156178 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
if an attended transfer occurred during the call. I traced the cause to
the CDR on one of the channels being NULL. murf suggested a check in
the end bridge callback to be sure the CDR is non-NULL before proceeding,
so that's what I'm adding.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@156167 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
change to the ast_bridge_config struct as well. To understand the reason
for this change, see the following post:
http://gcc.gnu.org/ml/gcc-help/2008-11/msg00049.html
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@155553 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(Closes issue #13829)
Reported by: jaroth
Patch by: me (modified jaroth's patch)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@154066 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
being passed to printf()-like functions and ignored results from read()/write() and friends
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@153337 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@153270 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
variables that were set after ast_bridge_call was called would not show up in the 'h' exten. Added a callback function to handle setting variables, etc. from w/in the bridging code. Calls back into a nested function within the function calling ast_bridge_call
(closes issue #13793)
Reported by: greenfieldtech
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@153095 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
dial and queue... I wasted some time (stupidly) trying
to get the one-touch parking stuff working, because it
didn't occur to me that I had to also have the corresponding
options in the dial command! Duh! (In all this time, I never
set this up before!)
So, to keep some poor fool from suffering the same fate,
I made the features.conf.sample file mention the corresponding
opts in dial/queue; and the docs for dial/app specifically
mention the corresponding decls in the feature.conf file.
I hope this doesn't spoil some vast, eternal plan...
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@152538 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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.
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: http://svn.digium.com/svn/asterisk/branches/1.4@152535 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(Fixes AST-107)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@152463 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
per call (which could otherwise lead to inconsistent status reports).
(closes issue #13216)
Reported by: ruddy
Patches:
20081014__bug13216.diff.txt uploaded by Corydon76 (license 14)
Tested by: ruddy
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@152368 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
whether the call was completed within the service level
when a transfer takes place. This way, we do not "break"
the leastrecent and fewestcalls strategies by not logging
a call until after the transferred call has ended.
(closes issue #13395)
Reported by: Marquis
Patches:
app_queue.c.transfer.patch uploaded by Marquis (license 32)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@149200 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
possible memory leak.
(closes issue #13658)
Reported by: explidous
Patch by: me
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@149061 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@148987 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
in headers like 'Subject' and 'To'.
Closes AST-107.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@148916 f38db490-d61c-443f-a65b-d21fe96a405b
|