This fix may potentially cause problems with CDR backends that access the channel a CDR is associated with via the channel list. This fix makes the channel unavabile at the time when the CDR backend is invoked. This has been documented in include/asterisk/cdr.h.
(closes issue #15316)
Reported by: vmarrone
Tested by: mnicholson
Review: https://reviewboard.asterisk.org/r/362/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@219136 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Pattern matching for extensions uses a type of scoring system, giving values for
specificity to each character in the pattern. Unfortunately, this is done character
by character, in order. This does lead to some less specific patterns being first
in line for matching, but it will usually get the job done.
This patch merely brings CID matching to the same level as extension matching.
This patch does not attempt to tackle the problem shared by extension matching.
(closes issue #14708)
Reported by: klaus3000
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@218867 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The firmware can now be found on downloads.digium.com, where the rest of our
binary downloads live. This was the last part of our Asterisk tarballs that
was considered non-free by Debian. :-)
(closes issue #15838)
Reported by: paravoid
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@218798 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Also, not in the original bug report, but related fields are accountcode and
musicclass, and the inheritance of datastores.
(closes issue #15372)
Reported by: Romik
Patches:
20090828__issue15372.diff.txt uploaded by tilghman (license 14)
Tested by: cervajs
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@218577 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
In general channel names are in the form Foo/Bar-Z, but the channel name
could have multiple hyphens and look like Foo/B-a-r-Z. Use strrchr to
truncate the channel name at the last hyphen.
(closes issue #15810)
Reported by: dhubbard
Patches:
dw-softhangup-1.4.patch uploaded by dhubbard (license 733)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@215270 65c4cc65-6c06-0410-ace0-fbb531ad65f3
We have kept this comment around long enough, that it's pretty clear that we're
keeping the code, because changing the code would require a pretty fundamental
architectural shift. We've also taken criticism in some quarters, because it
was believed that it was referring to the code being nasty. No, the code isn't
nasty, just the operation itself is rather odd. Fixed for eternity (probably
not).
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@214701 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In ast_write(), if a channel has a list of audiohooks, those
lists are written to and the resulting frame is what ast_write()
should continue with. The problem was the returned audiohook frame
was not being handled at all, and the original frame passed
into it did not contain the mixed audio, so essentially audio
was being lost. One result of this was chan_spy's whisper
mode no longer worked. To complicate the issue, frames
passed into ast_write may either be a single frame, or a list
of frames. So, as the list of frames is processed in the
audiohook_write, the returned frames had to be added to a new
list.
(closes issue #15660)
Reported by: corruptor
Tested by: dvossel
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@214194 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Without this patch, asterisk creates a temporary file before determining if the
specified command is valid. If invalid, we weren't properly cleaning up the file.
(closes issue #15730)
Reported by: zmehmood
Patches:
M15730.diff uploaded by junky (license 177)
Tested by: zmehmood
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@212763 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
