SIP channel names were supposed to be unique by way of a name suffix derived from the
pointer to the channel's private data. Uniqueness was preserved on 32-bit systems, but
not on 64-bit systems. This patch, as suggested by kpfleming, replaces this suffix with
a simple incremented unsigned int.
(closes issue #15152)
Reported by: palbrecht
Review: https://reviewboard.asterisk.org/r/420/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@226972 65c4cc65-6c06-0410-ace0-fbb531ad65f3
while the called party had not yet answered.
This was fixed by introducing an argument to the 'n' option which, when enabled, removes the introduction
file under all scenarios. This was done to preserve the behavior that has existed for quite some time.
(closes issue #14674)
Reported by: ulogic
Patches:
bug14674.patch uploaded by jpeeler (license 325)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@226889 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Update the documentation in sip.conf.sample in order to make it more clear
that directmedia/canreinvite do not cause Asterisk to ignore reINVITEs. It
is only used to stop Asterisk from generating a reINVITE, but does not stop
it from accepting them if necessary.
(closes issue #15644)
Reported by: lmadsen
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@226382 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Set OSARCH to linux-gnu even if host_os is linux-gnueabi
* When checking if we are Linux, check OSARCH rather than host_os
The newer ARM ABI ("EABI") shows the OS name 'linux-gnueabi' rather than
'linux-gnu' . This patch sets OSARCH to be 'linux-gnu' even in such a case.
OSARCH is tested for the value of 'linux-gnu' in one or two places in the
tree. This patch also fixes the check libcap to check for $OSARCH rather
than $host_os .
See also: http://wiki.debian.org/ArmEabiPort
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@225957 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For some reason the menuselect.makeopts file was listed as PHONY in the Makefile,
resulting in 'make' needing to rebuild it for every build. This then resulted in
the embedded module rules being rebuilt on every build, which can be slow and is
unnecessary.
This patch fixes the problem by properly allowing 'make' to know when the
menuselect.makeopts file needs to be rebuilt (defining the proper dependencies).
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@225581 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Update valgrind.txt documentation and add valgrind.supp file in order to
allow those who are creating valgrind output to have less false errors in
the logfile.
(closes issue #16007)
Reported by: atis
Patches:
valgrind.txt.diff uploaded by atis (license 242)
asterisk2.supp uploaded by atis (license 242)
Tested by: atis, amorsen
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@225484 65c4cc65-6c06-0410-ace0-fbb531ad65f3
It is possible for the PBX thread to queue up signaling frames before
a destination call number is received. This can result in signaling
frames being sent out with no destination call number. Since recent
versions of Asterisk require accurate destination callnumbers for all
Full Frames, this can cause a VNAK loop to occur. To resolve this
no signaling frames are sent until a destination callnumber is received,
and destination call numbers are now only required for iax_pvt matching
when the frame is an ACK.
Review: https://reviewboard.asterisk.org/r/413/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@225243 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The shrinking of caller id removes '(', ' ', ')', non-trailing '.',
and '-' from the string. This means values such as 555.5555 and
test-test result in 555555 and testtest. There are instances,
such as Skype integration, where a specific value is passed via
caller id that must be preserved unmodified. This patch makes
the shrinking of caller id optional in chan_sip and chan_iax in
order to support such cases. By default this option is on to
preserve previous expected behavior.
(closes issue #15940)
Reported by: dimas
Patches:
v2-15940.patch uploaded by dimas (license 88)
15940_shrinkcallerid_trunk.c uploaded by dvossel (license 671)
Tested by: dvossel
Review: https://reviewboard.asterisk.org/r/408/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@225032 65c4cc65-6c06-0410-ace0-fbb531ad65f3
While this looks like an optimization, it prevents a crash from occurring
when used with certain audiohook callbacks (diagnosed with SVN trunk,
backported to 1.4 to keep the source consistent across versions).
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@224855 65c4cc65-6c06-0410-ace0-fbb531ad65f3
While testing some endpoints that support 16kHz and 32kHz sample rates, some
log messages were generated due to calc_rxstamp() computing timestamps in a way
that produced odd results, so this patch sanitizes the result of the
computations.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@224670 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The problem here is that chan_dahdi is designed in such a way to set
certain values in the dahdi_pvt only once. One of those such values
is the configured caller id data in chan_dahdi.conf. For PRI, the
configured caller id data could be overwritten during a call. Instead
of saving the data and restoring, it was decided that for all non-analog
channels it was simply best to not set the configured caller id in the
first place and also clear it at the end of the call.
(closes issue #15883)
Reported by: jsmith
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@224330 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When the Busy() or Congestion() application is used towards ISDN (an ISDN
progress is sent), the responding ISDN Disconnect or Release may contain
the ISDN cause user busy or one of the congestion causes. In chan_dahdi.c
these causes will only set the needbusy or needcongestion flags and not
activate the softhangup procedure. Unfortunately only the latter can
interrupt the endless wait loop of Busy()/Congestion().
Result: PRI channels staying in state busy for the rest of asterisk life
or until the other end times out and forces the call to clear.
(in issue 0014292)
Reported by: tomaso
Patches:
disc_rel_userbusy.patch uploaded by tomaso (license 564)
(This patch is unrelated to the issue.)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@224260 65c4cc65-6c06-0410-ace0-fbb531ad65f3
chan_sip has some code to automatically switch from T.38 mode to voice mode when
a voice frame is written to the channel while it is in T.38 mode; this was
intended to handle the situation when a FAX transmission has ended and the channel
is not yet hung up, but is causing problems at the beginning of FAX sessions as
well when there are still voice frames 'in flight' at the time the T.38 negotiation
completes. This patch removes the automatic switchover.
(issue #16025)
Reported by: jamicque
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@223692 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The purpose of this code was to have a hangup frame put on the list of deferred
frames. However, the code that read the hangup frame was outside of the scope
of where the hangup frame was declared.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@223485 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch is related to a number of issues on the bug tracker that show
crashes related to freeing frames that came from a filestream. A number of
fixes have been made over time while trying to figure out these problems, but
there re still people seeing the crash. (Note that some of these bug reports
include information about other problems. I am specifically addressing
the filestream frame crash here.)
I'm still not clear on what the exact problem is. However, what is _very_
clear is that we have seen quite a few problems over time related to unexpected
behavior when we try to use embedded frames as an optimization. In some cases,
this optimization doesn't really provide much due to improvements made in other
areas.
In this case, the patch modifies filestream handling such that the embedded frame
will not be returned. ast_frisolate() is used to ensure that we end up with a
completely mallocd frame. In reality, though, we will not actually have to malloc
every time. For filestreams, the frame will almost always be allocated and freed
in the same thread. That means that the thread local frame cache will be used.
So, going this route doesn't hurt.
With this patch in place, some people have reported success in not seeing the
crash anymore.
(SWP-150)
(AST-208)
(ABE-1834)
(issue #15609)
Reported by: aragon
Patches:
filestream_frisolate-1.4.diff2.txt uploaded by russell (license 2)
Tested by: aragon, russell
(closes issue #15817)
Reported by: zerohalo
Tested by: zerohalo
(closes issue #15845)
Reported by: marhbere
Review: https://reviewboard.asterisk.org/r/386/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@222878 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Memory leak when the same config option is set more than once in an
misdn.conf section. Why must this be considered? Templates! Defining a
template with default port options and later adding to or overriding some
of them.
Patches:
memleak-misdn.patch
JIRA ABE-1998
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@222797 65c4cc65-6c06-0410-ace0-fbb531ad65f3
misdn.conf: astdtmf must be set to "yes". With "no", buffer loss does not
occur.
The translated frame "f2" when passing through ast_dsp_process() is not
freed whenever it is not used further in process_ast_dsp(). Then in the
end it is never ever freed.
Patches:
translate.patch
JIRA ABE-1993
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@222691 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The variable index used in this scenario for accessing the dahdi_pvts was
wrong and was most likely copied from the several other places it is used
correctly.
(closes issue #15998)
Reported by: tsearle
Patches:
dahdi_reset_crash.patch uploaded by tsearle (license 373)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@222393 65c4cc65-6c06-0410-ace0-fbb531ad65f3
See Mantis issue for details of what prompted this change.
Additional notes:
This patch changes the ao2_iterator API in two ways: F_AO2I_DONTLOCK
has become an enum instead of a macro, with a name that fits our
naming policy; also, it is now necessary to call
ao2_iterator_destroy() on any iterator that has been
created. Currently this only releases the reference to the container
being iterated, but in the future this could also release other
resources used by the iterator, if the iterator implementation changes
to use additional resources.
(closes issue #15987)
Reported by: kpfleming
Review: https://reviewboard.asterisk.org/r/383/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@222152 65c4cc65-6c06-0410-ace0-fbb531ad65f3
I have not been able to reproduce the problem of losing channels.
However, I have seen in the code a reentrancy problem that might give
these symptoms.
The reentrancy patch does several things:
1) Guards B channel and B channel structure allocation.
2) Makes the B channel structure find routines more precise in locating records.
3) Never leave a B channel allocated if we received cause 44.
The last item may cause temporary outgoing call problems, but they should
clear when the line becomes idle.
(closes issue #15490)
Reported by: slutec18
Patches:
issue15490_channel_alloc_reentrancy.patch uploaded by rmudgett (license 664)
Tested by: rmudgett, slutec18
(closes issue #15458)
Reported by: FabienToune
Patches:
issue15458_channel_alloc_reentrancy.patch uploaded by rmudgett (license 664)
Tested by: FabienToune, rmudgett, slutec18
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@221769 65c4cc65-6c06-0410-ace0-fbb531ad65f3
