There is code in chan_iax2.c that attempts to guarantee that only a single
active thread will handle a call number at a time. This code works once
the thread is added to an active_list of threads, but we are not currently
guaranteed that a newly activated thread will enter the active_list immediately
because it is left up to the thread to add itself after frames have been
queued to it. This means that if two frames come in for the same call number
at the same time, it is possible for them to grab two separate threads because
the first thread did not add itself to the active_list fast enough. This
causes some pretty complex problems.
This patch resolves this race condition by immediately adding an activated
thread to the active_list within the network thread and only depending on
the thread to remove itself once it is done processing the frames queued to
it. By doing this we are guaranteed that if another frame for the same call
number comes in at the same time, that this thread will immediately be found
in the active_list of threads.
Review: https://reviewboard.asterisk.org/r/720/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@270866 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r270658 | twilson | 2010-06-15 15:18:04 -0500 (Tue, 15 Jun 2010) | 20 lines
Make contactdeny apply to src ip when nat=yes
chan_sip's "contactdeny" feature screens the "to be registered contact".
In case of nat=yes it should not use the address information from the
Contact header (which is not used at all for routing), but the source
IP address of the request.
Thus, if nat=yes and a client sends a request from a denied IP address
(e.g. by spoofing the src-IP address) it can bypass the screening.
This commit makes contactdeny apply to the src ip when nat=yes instead.
(closes issue #17276)
Reported by: klaus3000
Patches:
patch-asterisk-trunk-contactdeny.txt uploaded by klaus3000 (license 65)
Tested by: klaus3000
Review: [full review board URL with trailing slash]
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@270724 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The issue here was that the frame created when adjusting for PLC had no offset
to its audio data. If this frame were translated to another format prior to
being sent out an RTP socket, all went well because the translation code would
put an appropriate offset into the frame. However, if the SLIN audio were not
translated before being sent out the RTP socket, bad things would happen.
Specifically, the ast_rtp_raw_write makes the assumption that the frame has
at least enough of an offset that it can accommodate an RTP header. This was
not the case. As such, data was being written prior to the allocation, likely
corrupting the data the memory allocator had written. Thus when the time came
to free the data, all hell broke loose. ....Well, Asterisk crashed at least.
The fix was just what one would expect. Offset the data in the frame by a reasonable
amount. The method I used is a bit odd since the data in the frame is 16 bit integers
and not bytes. I left a big ol' comment about it. This can be improved on if someone
is interested. I was more interested in getting the crash resolved.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@269821 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This eliminates the annoying <beep> on the console.
(closes issue #17477)
Reported by: jvandal
Patches:
20100610__issue17477.diff.txt uploaded by tilghman (license 14)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@269635 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When using the init script as-is currently, it could cause issues on Debian
such as high CPU usage. This fix has worked for several people so I'm
implementing the change. We now handle color displays properly.
(closes issue #16784)
Reported by: pabelanger
Patches:
20100530__issue16784__2.diff.txt uploaded by tilghman (license 14)
Tested by: pabelanger, tilghman
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@269334 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Since we are just checking for table existence, add a WHERE clause that will
return no rows but will raise an error if the table doesn't exist.
(closes issue #17380)
Reported by: kkwong
Patches:
issue17380-01.patch uploaded by seanbright (license 71)
Tested by: kkwong
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@269006 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Uses the VT100 method of clearing the line from the cursor position to the
end of the line: Esc-0K
(closes issue #17160)
Reported by: coolmig
Patches:
20100531__issue17160.diff.txt uploaded by tilghman (license 14)
Tested by: coolmig
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@266585 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a T.38 re-INVITE failed with an 488 or 606 answer, we should
fallback to audio fax by send a re-re-INVITE without T.38. The
function is backported from 1.6 asterisk.
(closes issue #16795)
Reported by: vrban
(closes issue #16692)
Reported by: vrban
Patches:
t38_fallback_to_audio_v3.patch uploaded by vrban (license 756)
Tested by: lmadsen, vrban, haggard
https://reviewboard.asterisk.org/r/514/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@266579 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If you call signal() in a Solaris signal handler, instead of just resetting
the signal handler, it causes the signal to refire, because the signal is not
marked as handled prior to the signal handler being called. This effectively
causes Solaris to immediately exceed the threadstack in recursive signal
handlers and crash.
(closes issue #17000)
Reported by: rmcgilvr
Patches:
20100526__issue17000.diff.txt uploaded by tilghman (license 14)
Tested by: rmcgilvr
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@266142 65c4cc65-6c06-0410-ace0-fbb531ad65f3
At times, the "Member" field was not specified during the event.
It's there now.
(closes issue #15638)
Reported by: elbriga
Patches:
patchAppQueueAgentComplete.diff uploaded by elbriga (license 482)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@266004 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r265320 | twilson | 2010-05-24 14:06:40 -0500 (Mon, 24 May 2010) | 14 lines
Add the FullyBooted AMI event
It is possible to connect to the manager interface before all Asterisk modules
are loaded. To ensure that an application does not send AMI actions that might
require a module that has not yet loaded, the application can listen for the
FullyBooted manager event. It will be sent upon connection if all modules have
been loaded, or as soon as loading is complete. The event:
Event: FullyBooted
Privilege: system,all
Status: Fully Booted
Review: https://reviewboard.asterisk.org/r/639/
........
r265467 | twilson | 2010-05-24 17:21:58 -0500 (Mon, 24 May 2010) | 1 line
Merge the rest of the FullyBooted patch
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@265570 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This also fixes a documentation mistake in file.h that made my original attempt
to correct this problem not work correctly.
(closes issue #17061)
Reported by: RoadKill
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@265089 65c4cc65-6c06-0410-ace0-fbb531ad65f3
From reviewboard
Background:
A Digium customer discovered a somewhat odd bug. The setup is that parties A
and B are bridged, and party A places party B on hold. While party B is
listening to hold music, he mashes a bunch of DTMF. Party A takes party
B off hold while this is happening, but party B continues to hear hold
music. I could reproduce this about 1 in 5 times.
The issue:
When DTMF features are enabled and a user presses keys, the channel that
the DTMF is streamed to is placed in an ast_safe_sleep for 100 ms, the
duration of the emulated tone. If an AST_CONTROL_UNHOLD frame is read
from the channel during the sleep, the frame is dropped. Thus the
unhold indication is never made to the channel that was originally placed
on hold.
The fix:
Originally, I discussed with Kevin possible ways of fixing the specific
problem reported. However, we determined that the same type of problem
could happen in other situations where ast_safe_sleep() is used. Using
autoservice as a model, I modified ast_safe_sleep_conditional() to
defer specific frame types so they can be re-queued once the sleep has
finished. I made a common function for determining if a frame should
be deferred so that there are not two identical switch blocks to
maintain.
Review: https://reviewboard.asterisk.org/r/674/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@264996 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Several callers of ast_callerid_parse() do not initialize the name
parameter before calling thus there is the potential to use an
uninitialized pointer.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@264820 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The reason for ensuring DAHDI 2.3 or above is that this version ensures that
a timer is always available, whereas in previous versions, it was possible
for DAHDI to be loaded, but have no drivers to actually generate timing. If
internal_timing was turned on in this circumstance, a complete lack of audio
would result. This is the reason why internal_timing was not on by default.
However, now that DAHDI ensures the availability of a timer, there is no
reason for this setting to be off (and in fact, it solves a great many initial
user problems).
(closes issue #15932)
Reported by: dimas
Patches:
20100519__issue15932.diff.txt uploaded by tilghman (license 14)
Tested by: tilghman
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@264248 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In the case of accidentally entering the wrong first three letters for the
reading, users could be very frustrated if the name listing is very long. This
allows interrupting the reading by pressing 0 or #. 0 will attempt to execute
a configured operator (o) extension and # will exit and proceed in the
dialplan.
ABE-2200
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@263769 65c4cc65-6c06-0410-ace0-fbb531ad65f3
