This change resolves a crash observed locally during some T.38 testing.
A call was set up using a call file, and when the T.38 reinvite came in,
the channel state was still AST_STATE_DOWN. The reason is explained by
a comment in the code that previously lived in the handling of
AST_STATE_RINGING. This change modifies the logic to handle the same
race condition for any channel state that is not UP.
(closes ABE-1895)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@203115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Valid format is: pritimer=timer_name,timer_value
* Fixed segfault if the ',' is missing.
* Completely check the range returned by pri_timer2idx() to prevent
possible access outside array bounds.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@203036 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a CANCEL were received by Asterisk, we would send a 487 in response
to the original INVITE and a 200 OK for the CANCEL. If there were a network
hiccup which caused the 200 OK and the 487 to be lost, then the UA communicating
with Asterisk may try to retransmit its CANCEL. Asterisk's response to this used
to be to try sending another 487 to the canceled INVITE and another 200 OK to the
CANCEL.
The problem here is that the originally-sent 487 was sent "reliably" meaning that
it will be retransmitted until it is received properly. So when we receive the second
CANCEL it is likely that the first batch of 487s we sent is still going strong and
reaches the UA. The result was that the second set of 487s would be retransmitted
constantly until the maximum number of retries had been reached.
The fix for this is that if we receive a second CANCEL for an INVITE, then we cancel
the retransmission of the first set of 487s and start a second set. This causes the
dialog to be terminated reasonably.
(closes issue #14584)
Reported by: klaus3000
Patches:
14584_v2.patch uploaded by mmichelson (license 60)
Tested by: klaus3000
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@202341 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There was a while loop in get_ip_and_port_from_sdp which was controlled
by a call to get_sdp_iterate. The loop would exit either if what we were
searching for was found or if the return was NULL. The problem is that
get_sdp_iterate never returns NULL. This means that if what we were searching
for was not present, the loop would run infinitely. This modification of the
loop fixes the problem.
(closes issue #15213)
Reported by: schmidts
(closes issue #15349)
Reported by: samy
(closes issue #14464)
Reported by: pj
(closes issue #15345)
Reported by: aragon
Patches:
sip_inf_loop.patch uploaded by mmichelson (license 60)
Tested by: aragon
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@202336 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If the "h" extension fails, give it another chance in main/pbx.c, when it
returns from the bridge code. Fixes an issue where the "h" extension may
occasionally not fire, when a Dial is executed from a Macro.
Debugged in #asterisk with user tompaw.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@201828 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For Music on Hold classes that are not files mode, meaning that we are executing
an application that will feed us audio data, we use a thread to monitor the
external application and read audio from it. This thread also makes use of the
MoH class object. In the MoH class destructor, we used pthread_cancel() to ask
the thread to exit. Unfortunately, the code did not wait to ensure that the
thread actually went away. What needed to be done is a pthread_join() to ensure
that the thread fully cleans up before we proceed. By adding this one line, we
resolve two significant problems:
1) Since the thread was never joined, it never fully goes away. So, on every
reload of non-files mode MoH, an unused thread was sticking around.
2) There was a race condition here where the application monitoring thread
could still try to access the MoH class, even though the thread executing
the MoH reload has already destroyed it.
(issue #15109)
Reported by: jvandal
(issue #15123)
Reported by: axisinternet
(issue #15195)
Reported by: amorsen
(issue AST-208)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@201600 65c4cc65-6c06-0410-ace0-fbb531ad65f3
It is possible for datastore fixup functions to remove the datastore from the list
and free it. In particular, the queue_transfer_fixup in app_queue does this. While
I don't yet know of this causing any crashes, it certainly could.
Found while discussing a separate issue with Brian Degenhardt.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@201450 65c4cc65-6c06-0410-ace0-fbb531ad65f3
StopMixMonitor only indicates to the MixMonitor thread to stop
writing to the file. It does not guarantee that the recording's
file handle is available to the dialplan immediately after execution.
This results in a race condition. To resolve this, the filestream
pointer is placed in a datastore on the channel. When StopMixMonitor
is called, the datastore is retrieved from the channel and the
filestream is closed immediately before returning to the dialplan.
Documentation indicating the use of StopMixMonitor to free files
has been updated as well.
(closes issue #15259)
Reported by: travisghansen
Tested by: dvossel
Review: https://reviewboard.asterisk.org/r/283/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@201423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Zombie channels could be passed, and chan_sip.c wasn't checking for it.
Could crash Asterisk. Now checking for NULL pointer.
(closes issue #15330)
Reported by: okrief
Tested by: dbrooks
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@201380 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When the list to be appended is empty, and the list to be appended to is *not*,
AST_LIST_APPEND_LIST would actually cause the target list to become broken,
and no longer have a pointer to its last entry. This patch fixes the problem.
(reported by Stanislaw Pitucha on the asterisk-dev mailing list)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@201261 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There are various media paths in Asterisk (codec translators and UDPTL, primarily)
that can generate more than one frame to be generated when the application calling
them expects only a single frame. This patch addresses a number of those cases,
at least the primary ones to solve the known problems. In addition it removes the
broken TRACE_FRAMES support, fixes a number of bugs in various frame-related API
functions, and cleans up various code paths affected by these changes.
https://reviewboard.asterisk.org/r/175/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@200991 65c4cc65-6c06-0410-ace0-fbb531ad65f3
We were setting the stack size for each thread to 240KB regardless of
architecture, which meant that in some scenarios we actually had less available
stack space on 64 bit processors (pointers use 8 bytes instead of 4). So now we
calculate the stack size we reserve based on the platform's __WORDSIZE, which
gives us:
32 bit -> 240KB
64 bit -> 496KB
128 bit -> 1008KB (that's right, we're ready for 128 bit processors)
Patch typed by me but written by several members of #asterisk-dev, including
Kevin, Tilghman, and Qwell.
(closes issue #14932)
Reported by: jpiszcz
Patches:
06052009_issue14932.patch uploaded by seanbright (license 71)
Tested by: seanbright
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@199626 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Hints with two or more devices that include ONHOLD gave unexpected results.
(closes issue #15057)
Reported by: p_lindheimer
Patches:
onhold_trunk.diff uploaded by dvossel (license 671)
pbx.c.1.4.patch uploaded by p (license 558)
devicestate.c.trunk.patch uploaded by p (license 671)
Tested by: p_lindheimer, dvossel
Review: https://reviewboard.asterisk.org/r/254/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@199297 65c4cc65-6c06-0410-ace0-fbb531ad65f3
During asterisk startup, a lock on the list of modules is obtained by the
primary thread while each module is initialized. Issue 13778 pointed out a
problem with this approach, however. Because the AMI is loaded before other
modules, it is possible for a module reload to be issued by a connected client
(via Action: Command), causing a deadlock.
The resolution for 13778 was to move initialization of the manager to happen
after the other modules had already been lodaded. While this fixed this
particular issue, it caused a problem for users (like FreePBX) who call AMI
scripts via an #exec in a configuration file (See issue 15189).
The solution I have come up with is to defer any reload requests that come in
until after the server is fully booted. When a call comes in to
ast_module_reload (from wherever) before we are fully booted, the request is
added to a queue of pending requests. Once we are done booting up, we then
execute these deferred requests in turn.
Note that I have tried to make this a bit more intelligent in that it will not
queue up more than 1 request for the same module to be reloaded, and if a
general reload request comes in ('module reload') the queue is flushed and we
only issue a single deferred reload for the entire system.
As for how this will impact existing installations - Before 13778, a reload
issued before module initialization was completed would result in a deadlock.
After 13778, you simply couldn't connect to the manager during startup (which
causes problems with #exec-that-calls-AMI configuration files). I believe this
is a good general purpose solution that won't negatively impact existing
installations.
(closes issue #15189)
(closes issue #13778)
Reported by: p_lindheimer
Patches:
06032009_15189_deferred_reloads.diff uploaded by seanbright (license 71)
Tested by: p_lindheimer, seanbright
Review: https://reviewboard.asterisk.org/r/272/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@199022 65c4cc65-6c06-0410-ace0-fbb531ad65f3
We were trying to reference members of a struct that had previously been freed.
This patch makes sure that we free the struct after it has been removed from
the spooler queue.
(closes issue #15072)
Reported by: garlew
Patches:
spool.diff uploaded by garlew (license 376)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@198957 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The function ast_call_forward() forwards a call to an extension specified in an ast_channel's call_forward string. After an ast_channel is called, if the channel's call_forward string is set this function can be used to forward the call to a new channel and terminate the original one. I have included this api call in both channel.c's ast_request_and_dial() and res_feature.c's feature_request_and_dial(). App_dial and app_queue already contain call forward logic specific for their application and options.
(closes issue #13630)
Reported by: festr
Review: https://reviewboard.asterisk.org/r/271/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@198891 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The response message (either Error or Success) needs an extra trailing \r\n
after the fields to inform the client that the message is complete.
(closes issue #14876)
Reported by: srt
Patches:
05302009_1.4_res_jabber.c.diff uploaded by seanbright (license 71)
asterisk_14876.patch uploaded by srt (license 378)
trunk-14876-2.diff uploaded by phsultan (license 73)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@198370 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change also involves the addition of an AST_CDR_FLAG_ORIGINATED flag that is used on originated channels to distinguish: them from dialed channels.
(closes issue #12946)
Reported by: meral
Patches:
null-cdr2.diff uploaded by mnicholson (license 96)
Tested by: mnicholson, dbrooks
(closes issue #15122)
Reported by: sum
Tested by: sum
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@198068 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There was a missing semi-colon after the echo statement in the Makefile that was
causing problems for some users. Fix suggested by reporter.
(closes issue #15225)
Reported by: pdavis
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@197998 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Updated the MixMonitor documentation for the 'b' option so that
it is more obvious that you must not optimize awat the Local
channel when using this option.
(issue #14829)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@197895 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When we receive a SIP reinvite, it is possible that we may not be able to process the
reinvite immediately since we have also sent a reinvite out ourselves. The problem is
that whoever sent us the reinvite may have also sent a reinvite out to another party,
and that reinvite may have succeeded.
As a result, even though we are not going to accept the reinvite we just received, it
is important for us to not have problems if we suddenly start receiving RTP from a new
source. The fix for this is to grab the media source information from the SDP of the
reinvite that we receive. This information is passed to the RTP layer so that it will
know about the alternate source for media.
Review: https://reviewboard.asterisk.org/r/252
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@197588 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If we already have an address for a peer, and we are reloading the sip
configuration, try to use that address to contact the peer, instead of
getting it from the Contact.
(closes issue #15194)
Reported by: ibc
Patches:
sip.patch uploaded by eliel (license 64)
Tested by: manwe
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@197562 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There are two flags being added to the chanspy audiohook here. One
is the pre-existing AST_AUDIOHOOK_TRIGGER_SYNC flag. With this set,
we ensure that the read and write slinfactories on the audiohook do
not skew beyond a certain tolerance.
In addition, there is a new audiohook flag added here,
AST_AUDIOHOOK_SMALL_QUEUE. With this flag set, we do not allow for
a slinfactory to build up a substantial amount of audio before
flushing it. For this particular issue, this means that the person
spying on the call will hear the conversations in real time with very
little delay in the audio.
(closes issue #13745)
Reported by: geoffs
Patches:
13745.patch uploaded by mmichelson (license 60)
Tested by: snblitz
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@197537 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The presence of rport is now stored as a separate flag. Once the dialog is setup and authenticated
(or it passes through unauthenticated) the proper nat flag is set.
(closes issue #13823)
Reported by: dimas
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@197466 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Since we use bashisms in build_tools/mkpkgconfig, we should call on bash
explicitly when running from the Makefile, otherwise we get errors during a
'make install.'
(closes issue #15209)
Reported by: seandarcy
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@197264 65c4cc65-6c06-0410-ace0-fbb531ad65f3
