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
This patch adds a new field "portinuri" to the sip dialog struct and the sip peer struct. That field is used during RURI generation to determine if the port should be included in the RURI. It is also used in some places to determine if an SRV lookup should occur.
(closes issue #14418)
Reported by: klaus3000
Tested by: klaus3000, mnicholson
Review: https://reviewboard.asterisk.org/r/369/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@221360 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Be default, change SSRC when doing an audio stream changes Asterisk doesn't
honor marker bit when reinvited to already-bridged RTP streams,resulting in
far-end stack discarding packets with "old" timestamps that areactually part of
a new stream. This patch sends AST_CONTROL_SRCUPDATE whenever there is a
reinvite, unless the 'constantssrc' is set to true in sip.conf.
The original issue reported to Digium support detailed the following situation:
ITSP <-> Asterisk 1.4.26.2 <-> SIP-based Application Server Call comes in
fromITSP, Asterisk dials the app server which sends a re-invite back
toAsterisk--not to negotiate to send media directly to the ITSP, but to
indicatethat it's changing the stream it's sending to Asterisk. The app
servergenerates a new SSRC, sequence numbers, timestamps, and sets the marker
bit on the new stream. Asterisk passes through the teimstamp of the new stream,
butdoes not reset the SSRC, sequence numbers, or set the marker bit.
When the timestamp on the new stream is older than the timestamp on the
originalstream, the ITSP (which doesn't know there has been any change) discards
the newframes because it thinks they are too old. This patch addresses this by
changing the SSRC on a stream update unless constantssrc=true is set in
sip.conf.
Review: https://reviewboard.asterisk.org/r/374/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@221086 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fixes a 100% CPU problem in the SIP driver, found by profiling
the driver while the problem was occurring.
(closes issue #14309)
Reported by: pkempgen
Patches:
20090924__issue14309.diff.txt uploaded by tilghman (license 14)
Tested by: pkempgen, vrban
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@220873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The iax frame's retrans sched id was written over right
before iax2_frame_free was called. In iax2_frame_free that
retrans id is used to delete the sched item. By writing over
the retrans field before the sched item could be deleted, it was
possible for a retransmit to occur on a freed frame.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@219519 65c4cc65-6c06-0410-ace0-fbb531ad65f3
INVITE requests must always contain a new unique branch id. When
a new branch id is created for an INVITE, the dialog's invite_branch
variable must be updated so CANCEL requests use the correct branch id.
(closes issue #15262)
Reported by: maniax
Patches:
asterisk-1.6.1.0-sip-branch.patch uploaded by tweety (license 608)
invite_new_branch_trunk.diff uploaded by dvossel (license 671)
Tested by: maniax, dvossel
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@219450 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch cleans up the locking logic in chan_sip.c's
handle_invite_replaces() function as well as making use
of ast_do_masquerade() rather than forcing the masquerade
on an ast_read(). The code had several redundant unlocks
that would result in 'freed more times than we've locked!'
errors. I cleaned these up as well as moving all the unlock
logic to the end of the function. This patch should also
resolve the issue people were having with the replacecall
channel never being unlocked with one legged calls.
(closes issue #15151)
Reported by: irroot
Patches:
invite_w_replaces_1.4.diff uploaded by dvossel (license 671)
Tested by: irroot, dvossel
Review: https://reviewboard.asterisk.org/r/371/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@219303 65c4cc65-6c06-0410-ace0-fbb531ad65f3
After talking to rmudgett about some of his recent iflist locking changes, it
was determined that the only place that would destroy a channel without being
explicitly to do so was in handle_init_event. The loop to walk the interface
list has been modified to wait to destroy the channel until the dahdi_pvt of
the channel to be destroyed is no longer needed.
(closes issue #15378)
Reported by: samy
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@218401 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The IAX2 Call Token security patch inadvertently broke the use of
encryption due to the reorganization of code in the socket_process()
function. When encryption is used, an incoming full frame must first
be decrypted before the information elements can be parsed. The
security release mistakenly moved IE parsing before decryption in
order to process the new Call Token IE. To resolve this, decryption
of full frames is once again done before looking into the frame. This
involves searching for an existing callno, checking the pvt to see if
encryption is turned on, and decrypting the packet before the internal
fields of the full frame are accessed.
associated with AST-2009-006
(closes issue #15834)
Reported by: karesmakro
Patches:
iax2_encryption_fix_1.4.diff uploaded by dvossel (license 671)
Tested by: dvossel, karesmakro
Review: https://reviewboard.asterisk.org/r/355/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@217806 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Remove code that causes loops in registrations.
We have agreed that the patch that this code was part of was bad. I am ripping out the code that causes
the issue. putnopvut needs to check the rest of the patch, if it needs to be changed as well.
This solves the issue reported in #15540, but needs more work before we close it (as described above).
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@217668 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The issue at hand is that some legacy (dying) PBX systems send empty media frames on PRI
links *before* any call progress. The SIP channel receives these frames and by default
signals 183 Session progress and starts sending media. This will cause phones to
play silence and ignore the later 180 ringing message. A bad user experience.
The fix is twofold:
- We discovered that asterisk apps that support early media ("noanswer") did not send
any PROGRESS frame to indicate early media. Fixed.
- We introduce a setting in chan_sip so that users can disable any relay of media frames
before the outbound channel actually indicates any sort of call progress.
In 1.4, 1.6.0 and 1.6.1, this will be disabled for backward compatibility. In later versions
of Asterisk, this will be enabled. We don't assume that it will change your Asterisk
phone experience - only for the better.
We encourage third-party application developers to make sure that if they have applications
that wants to send early media, add a PROGRESS control frame transmission to make sure that
all channel drivers actually will start sending early media. This has not been the default
in Asterisk previous to this patch, so if you got inspiration from our code, you need to
update accordingly. Sorry for the trouble and thanks for your support.
This code has been running for a few months in a large scale installation (over 250
servers with PRI and/or BRI links to old PBX systems).
That's no proof that this is an excellent patch, but, well, it's tested :-)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@216430 65c4cc65-6c06-0410-ace0-fbb531ad65f3
From section 13.3.1.1 of RFC 3261:
If the UAS desires an extended period of time to answer the INVITE,
it will need to ask for an "extension" in order to prevent proxies
from canceling the transaction. A proxy has the option of canceling
a transaction when there is a gap of 3 minutes between responses in a
transaction. To prevent cancellation, the UAS MUST send a non-100
provisional response at every minute, to handle the possibility of
lost provisional responses.
(closes issue #11157)
Reported by: rjain
Tested by: twilson
Review: https://reviewboard.asterisk.org/r/315/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@215682 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If more ports were specified than configured in misdn.conf a reload would crash
asterisk. The problem was the unconfigured port was using data from the
previously configured port. When the data for an unconfigured port was freed a
crash would result from the double free.
(closes issue #12113)
Reported by: agupta
Patches:
bug12113.patch uploaded by jpeeler (license 325)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@212498 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There already was code present to be sure that a CANCEL will contain the same branch-id
as the INVITE it is cancelling. However, for INVITES which are challenged downstream,
this mechanism did not work properly. Now this is taken care of.
This is a backport of a fix already present in all 1.6.X branches and in trunk. It also
fixes ABE-1907.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@211807 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Issue 15655: For the case where dialing is complete for an incoming
call, dahdi_new() was asked to start the PBX and then the code set more
channel variables. If the dialplan hungup before these channel variables
got set, asterisk would likely crash.
* Fixed potential for overlap incoming call to erroneously set channel
variables as global dialplan variables if the ast_channel structure failed
to get allocated.
* Added missing set of CALLINGSUBADDR in the dialing is complete case.
(closes issue #15655)
Reported by: alecdavis
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@210575 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, a wildcard extension in the dialplan (for example, _*.) would take
precedence over picking up a call in the channel's pickup group. This patch simply moves
the block of code handling pickup group matching to above the extension matching code.
(closes issue #14735)
Reported by: stevedavies
Review: https://reviewboard.asterisk.org/r/319/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@210067 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The latest GCC (what will become 4.5.x) has a few new warnings, that in these
cases found some either downright buggy code, or at least seriously poorly
designed code that could be improved.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@209759 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Mostly trivial changes, but I did not know of any other way to fix the
"dereferencing type-punned pointer will break strict-aliasing rules" error
without creating a tmp variable in chan_skinny.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@208746 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For cases where Asterisk sends an INVITE and receives a non 2XX final
response, Asterisk would follow the INVITE transaction by immediately
sending a BYE, which was unnecessary.
(closes issue #14575)
Reported by: chris-mac
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@208587 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This generalizes the fix for issue 13849. The initial fix corrected the
problem that Asterisk would reply with a 491 if a reinvite were received
from an endpoint and we had not yet received an ACK from that endpoint
for the initial INVITE it had sent us. This expansion also allows Asterisk
to appropriately handle an INVITE with authorization credentials if Asterisk
had not received an ACK from the previous transaction in which Asterisk had
responded to an unauthorized INVITE with a 407.
(closes issue #14239)
Reported by: klaus3000
Patches:
14239.patch uploaded by mmichelson (license 60)
Tested by: klaus3000
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@208386 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There was already code for other signaling types in dahdi_handle_event to
handle dialing if a dial operation dial string was present. Simply add
SIG_EMWINK to the list.
(closes issue #14434)
Reported by: araasch
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@207827 65c4cc65-6c06-0410-ace0-fbb531ad65f3
