Age | Commit message (Collapse) | Author | Files | Lines |
|
(closes issue #13600)
Reported by: atis
Patches:
20090106__bug13600.diff.txt uploaded by Corydon76 (license 14)
Tested by: atis
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@168603 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
I found that the allow_multiple_logins function would never return
0 due to an incorrect comparison being used when traversing the
list of agents. While I was modifying this function, I also did
a little bit of coding guidelines cleanup, too.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@168598 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
|
|
(closes issue #14176)
Reported by: paraeco
Patches:
chan_sip.c.diff uploaded by paraeco (license 658)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@168551 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #14226)
Reported by: caspy
Patches:
20090113__bug14226.diff.txt uploaded by Corydon76 (license 14)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@168546 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Reported by: hoowa
Update the app CDR field for AGI commands that are not executing an application via "exec".
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@168516 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Reported by: IgorG
Tested by: denisgalvao
This gits rid of the notion of an owning_app allowing the request and hangup to be initiated by different threads. Originating from an active agent channel requires this. The implementation primarily changes __login_exec to wait on a condition variable rather than a lock.
Review: http://reviewboard.digium.com/r/35/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@168507 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
after being contacted by Olle Johansson and being shown how this fix is
incorrect. Thanks to Olle for clearing this up for me.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@168482 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@168480 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@168382 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@168379 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@168267 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@168198 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
* Miscellaneous doxygen comments added.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@168191 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
INFO, NOTIFY, OPTIONS, REFER, and MESSAGE requests
were not checking the topmost Via to determine where
to send the response. Adding check_via calls to those
request handlers solves this.
(closes issue #13071)
Reported by: baron
Patches:
check_via.patch uploaded by baron (license 531)
Tested by: baron
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@168128 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #14069)
Reported by: evandro
Patches:
20081214__bug14069.diff.txt uploaded by Corydon76 (license 14)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@167840 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@167714 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Asterisk channel, and the lock on that channel cannot be obtained because it is held by another thread, instead of dropping the request/response, queue it for later processing when the channel lock becomes available.
http://reviewboard.digium.com/r/117/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@167620 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@167566 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@167554 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@167545 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
an ao2 object.
Reported by JunK-Y on IRC, #asterisk-dev
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@167541 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
In passing, simplify the handling of returning a default tone zone.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@167432 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #14177)
Reported by: nic_bellamy
Patches:
asterisk-trunk-svn-r167242-ast_db_gettree.patch uploaded by nic (license 299)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@167299 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r167259 | tilghman | 2009-01-06 14:44:03 -0600 (Tue, 06 Jan 2009) | 2 lines
Security fix AST-2009-001.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@167260 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
There are some boolean attributes for T.38 such
as T38FaxFillBitRemoval, T38FaxTranscodingMMR, and
T38FaxTranscodingJBIG. By simply being present, we
should treat these as a "true" value. The current
code, however, was requiring a 1 or 0 as the value
of the attribute in order to parse it. This is due
to the fact that there are some T.38 endpoints and
gateways that also transmit this information
incorrectly. This patch follows the "be liberal in
what you accept and strict in what you send"
philosophy by accepting both the correctly- and
incorrectly-formatted attributes, but only sending
information as it is supposed to be sent.
It was also discovered that a particular type of
T.38 gateway sends some non-standard T.38 SDP
attributes. Instead of using T38FaxMaxDatagram
and T38MaxBitRate, it used T38MaxDatagram and
T38FaxMaxRate respectively. We now will properly
accept these attributes as well.
Note that there are a lot of patches cited in
the below commit message template. This is
because the person who submitted these patches is
an awesome person and wrote 1.4, 1.6.0, and 1.6.1
variants.
(closes issue #13976)
Reported by: linulin
Patches:
chan_sip.c.1.4-update1.diff uploaded by arcivanov (license 648)
chan_sip.c.1.6.0-update1.diff uploaded by arcivanov (license 648)
chan_sip.c.1.6.1-update1.diff uploaded by arcivanov (license 648)
chan_sip.c.1.4-relaxedT38_update1.diff uploaded by arcivanov (license 648)
chan_sip.c.1.6.0-relaxedT38_update1.diff uploaded by arcivanov (license 648)
chan_sip.c.1.6.1-relaxedT38_update1.diff uploaded by arcivanov (license 648)
Tested by: arcivanov
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@167179 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
in the ALSA sample code (see http://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2pcm_8c-example.html#a32)
Reported by: Jerry Geis (via the -users list)
Fixed by: me (license 14)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@167095 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(Closes #14153)
Reported by: Jerry Geis, via the users list.
Patch by: me (license 14)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@166953 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
http://lists.digium.com/pipermail/asterisk-dev/2008-December/035919.html
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@166772 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(Closes issue #14120)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@166592 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
callback
The fix for this is to simply set the newly created datastore's data pointer
to NULL if it is inherited but has no duplicate callback.
(closes issue #14113)
Reported by: francesco_r
Patches:
14113.patch uploaded by putnopvut (license 60)
Tested by: francesco_r
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@166568 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #14127)
Reported by: andrew
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@166509 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
It has been discovered that if a channel is locked prior
to a call to ast_autoservice_stop, then it is likely that
a deadlock will occur. The reason is that the call to
ast_autoservice_stop has a check built into it to be sure
that the thread running autoservice is not currently trying
to manipulate the channel we are about to pull out of
autoservice.
The autoservice thread, however, cannot advance beyond where
it currently is, though, because it is trying to acquire
the lock of the channel for which autoservice is attempting
to be stopped.
The gist of all this is that a channel MUST NOT be locked
when attempting to stop autoservice on the channel.
In this particular case, the channel was locked by a call
to ast_read. A call to ast_exists_extension led to autoservice
being started and stopped due to the existence of dialplan
switches.
It may be that there are future commits which handle the same
symptoms but in a different location, but based on my looks through
the code, it is very rare to see a construct such as this one.
(closes issue #14057)
Reported by: rtrauntvein
Patches:
14057v3.patch uploaded by putnopvut (license 60)
Tested by: rtrauntvein
Review: http://reviewboard.digium.com/r/107/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@166380 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@166297 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #13566)
Reported by: igorcarneiro
Tested by: russell
Review: http://reviewboard.digium.com/r/106/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@166262 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #13538)
Reported by: mbit
Patches:
13538.patch uploaded by putnopvut (license 60)
Tested by: putnopvut
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@166157 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
|
|
This patch handles some additional cases that could result in partial writes
to the file description. This was done to address complaints about partial
writes on AMI.
(issue #13546) (more changes needed to address potential problems in 1.6)
Reported by: srt
Tested by: russell
Review: http://reviewboard.digium.com/r/99/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@165796 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 #14099)
Reported by: caspy
Patches:
res_musiconhold.c.patch.killpg.try2 uploaded by caspy (license 645)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@165661 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
bridging to another channel. If we are not we actually want to bring the audio back to us.
(closes issue #13545)
Reported by: davidw
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@165591 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
|
|
is one of the few things I could find that was just plain wrong.
Even though it probably isn't possible for it to happen, it seems weird
to have code that checks if a pointer is NULL and then immediately dereferences
that pointer if it was NULL.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@164977 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
is exiting while holding a lock.
If the last lock attempt was a trylock, and it failed, it will still be in the
list of locks so that it can be reported.
(closes issue #13219)
Reported by: pj
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@164881 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
|