https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r219136 | mnicholson | 2009-09-17 09:58:39 -0500 (Thu, 17 Sep 2009) | 10 lines
Prevent a potential race condition and crash when hanging up a channel by removing the channel from the channel list before begining channel tear down.
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/trunk@219139 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r218867 | dbrooks | 2009-09-16 13:00:45 -0500 (Wed, 16 Sep 2009) | 13 lines
Fixes CID pattern matching behavior to mirror that of extension pattern matching.
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/trunk@218868 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In passing, correct the formatting of the Timestamp attribute so that there is a
space after the colon and before the value.
(closes issue #15861)
Reported by: Ivan
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@217408 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r216430 | oej | 2009-09-04 15:45:48 +0200 (Fre, 04 Sep 2009) | 27 lines
Make apps send PROGRESS control frame for early media and fix too early media issue in SIP
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/trunk@216438 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds a document describing the language prompt submission process,
licensing terms and other issues related to that process. In addition, it
modifies the sound file searching process to support language codes with
any number of suffices (not limited to just "xx" or "xx_YY"), so that prompts
can be named with gender, customer/company, etc. suffices as well.
(closes issue #15771)
Reported by: jtodd
Patches:
language-criteria.txt uploaded by jtodd
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@216006 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- Init the parkings list member of struct parkinglot.
Thanks Sean for the explanation why this should be here.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@215622 65c4cc65-6c06-0410-ace0-fbb531ad65f3
One note on defining _POSIX_C_SOURCE: while this feature test macro
works to require certain behaviors on Linux, it works differently on *BSD
platforms to REMOVE certain API calls that are not in the POSIX specification,
such as vasprintf(3). Thus, defining it while depending upon vasprintf (and
other extensions to the POSIX standard) to be defined is a recipe to ensure
that Asterisk is only buildable on Linux.
Hence, this define which was meant to INCREASE portability, effectively
ensures the opposite.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@214863 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r214701 | tilghman | 2009-08-28 15:13:32 -0500 (Fri, 28 Aug 2009) | 8 lines
Modify comment to be a bit more accurate.
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/trunk@214702 65c4cc65-6c06-0410-ace0-fbb531ad65f3
(closes issue #15786)
Reported by: a_villacis
Patches:
asterisk-1.6.2.0-beta4-manager-fix-crash-on-include-nonexistent-file.patch uploaded by a villacis (license 660)
(Plus a few of my own, to catch the remaining places within manager.c where it could have been a problem)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@214514 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Added DYNAMIC_FEATURENAME which holds the last triggered dynamic feature.
Added DYNAMIC_PEERNAME which holds the unique channel name on the other side
and is set when a dynamic feature is triggered.
(closes issue #14663)
Reported by: tamiel
Patches:
20090313_features.diff uploaded by tamiel (license 712)
Tested by: tamiel
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@214309 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r214194 | dvossel | 2009-08-26 11:36:42 -0500 (Wed, 26 Aug 2009) | 19 lines
ast_write() ignores ast_audiohook_write() results
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/trunk@214195 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r212763 | seanbright | 2009-08-18 12:36:00 -0400 (Tue, 18 Aug 2009) | 11 lines
Delay the creation of temporary files until we have a valid manager command to handle.
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/trunk@212764 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The logic here was reversed as ast_safe_system returns -1 on error and not on
success. Fix suggested by reporter.
(closes issue #15667)
Reported by: loic
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@212574 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Based on a post on the gcc-help mailing list and some subsequent reading,
we can increase our portability to various platforms by directly defining
the POSIX and X/OPEN API feature sets we wish to have available. This patch
does that, and also includes a double-check to ensure that the system
we are compiling on can actually provide the requested feature sets.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@212463 65c4cc65-6c06-0410-ace0-fbb531ad65f3
documentation of a function/application.
This will make reading the docs on the CLI way more easy.
(closes issue #15694)
Reported by: mvanbaak
Patches:
2009081100-extralinesoptionlist.diff.txt uploaded by mvanbaak (license 7)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@212339 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Even though the get_channel_by_name() API advertised that you could search by
name or uniqueid (just as the old API did), searching by uniqueid was not
actually implemented. This patch fixes that problem.
The ast_channel_get_full() function now makes a second search attempt by
uniqueid if the parameter was a name. The channel comparison function also
now knows how to compare by unqieueid.
Finally, a bug was fixed in passing where OBJ_POINTER was being passed in some
scenarios where it should not have been.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@211390 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Some T.38 endpoints treat T38FaxMaxDatagram as the maximum IFP size that should
be sent to them, rather than the maximum packet payload size. If such an
endpoint also requests UDPRedundancy as the error correction mode, we'll end
up calculating a tiny maximum IFP size, so small as to be unusable. This patch
sets a lower bound on what we'll consider the remote's maximum IFP size to be,
assuming that endpoints that do this really can accept larger packets than
they've offered to accept.
(closes issue #15649)
Reported by: dazza76
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@210992 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r210913 | tilghman | 2009-08-06 16:45:01 -0500 (Thu, 06 Aug 2009) | 7 lines
Because channel information can be accessed outside of the channel thread, we must lock the channel prior to modifying it.
(closes issue #15397)
Reported by: caspy
Patches:
20090714__issue15397.diff.txt uploaded by tilghman (license 14)
Tested by: caspy
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@210914 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The find_channel_by_group callback was only looking at the channel that was
attempting to make the pickup instead of the other channels in the container.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@210302 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r209759 | kpfleming | 2009-07-31 19:52:00 -0500 (Fri, 31 Jul 2009) | 7 lines
Minor changes inspired by testing with latest GCC.
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/trunk@209760 65c4cc65-6c06-0410-ace0-fbb531ad65f3
