Age | Commit message (Collapse) | Author | Files | Lines |
|
* 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: http://svn.digium.com/svn/asterisk/branches/1.4@210575 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Updated the imapstorage.txt documentation to reflect that issues with
c-client versions older than 2007 seem to cause crashing issues that
are not seen with more recent versions. Documentation has been updated
to reflect this.
(closes issue #14496)
Reported by: vbcrlfuser
Patches:
__20090727-imap-documentation-patch.txt uploaded by lmadsen (license 10)
Tested by: lmadsen, mmichelson, dbrooks
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@210563 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Ensure that system headers located in /usr/local/include are actually treated
as system headers by the compiler, and not as local headers which are subject
to warnings from the -Wundef compiler option and others.
(closes issue #15606)
Reported by: mvanbaak
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@210237 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@210067 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
developer discussions.
(related to issue #15639)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@210066 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(Related to issue #15639)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@210065 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #15639)
Reported by: nmav
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@210064 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(issue #15396)
Reported by: aragon
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@209879 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
When Milliwatt() was changed internally to use Playtones() so that the proper
tone was used, it introduced a drop in gain in the output signal. So, use
the playtones API directly and specify a volume argument such that the output
matches the gain of the original Milliwatt() code.
(closes issue #15386)
Reported by: rue_mohr
Patches:
issue_15386.rev2.diff uploaded by russell (license 2)
Tested by: rue_mohr
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@209838 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@209759 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@209315 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
There are some VoIP providers out there that will not accept SDP
offers with odd numbered UDPTL ports. While it is my personal opinion
that these VoIP providers are misinterpreting RFC 2327, it really is
not a big deal to play along with their silly little games. Of course,
since restricting UDPTL ports to only even numbers reduces the range
of available ports by half, so the option to use only even port numbers
is off by default. A user can enable the behavior by setting
use_even_ports=yes in udptl.conf.
(closes issue #15182)
Reported by: CGMChris
Patches:
15182.patch uploaded by mmichelson (license 60)
Tested by: CGMChris
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@209131 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
pthread_self returns a pthread_t which is not an unsigned int on all
pthread implementations. Casting it to an unsigned int fixes compiler warnings.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@208990 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@208923 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@208746 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
I know what some of you are thinking: "UGH! Mark, why are you using
ast_strdup and ast_free for the string when you can just use ast_strdupa
and let the memory free itself?! Have the bats been chewing on your brain
again?"
Based on past experiences, I don't like using ast_strdupa inside a loop.
It's a good way to potentially exhaust stack space. Also, since this only
happens when reloading queues, I don't think that heap allocations and
frees are going to be a huge problem.
(closes issue #15559)
Reported by: amorsen
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@208622 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This does not indicate an error. A return of -1 just means that the channel
has been hung up.
(reported in #asterisk-dev)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@208592 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@208587 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@208386 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #14696)
Reported by: fdecher
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@208380 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@208312 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #15442)
Reported by: ffloimair
Patches:
15442.patch uploaded by mmichelson (license 60)
Tested by: tkarl, ffloimair
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@208262 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #15556)
Reported by: smw1218
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@208083 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
states the argument is not optional).
This change makes URIENCODE and QUOTE behave similarly, since the documentation
states that the argument is not optional, for both.
(closes issue #15439)
Reported by: pkempgen
Patches:
20090706__issue15439.diff.txt uploaded by tilghman (license 14)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@207945 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@207827 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
amount of time.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@207786 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
AST-224
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@207714 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This commit changes the build system so that user-provided flags (in ASTCFLAGS
and ASTLDFLAGS) are supplied to the compiler/linker *after* all flags provided
by the build system itself, so that the user can effectively override the
build system's flags if desired. In addition, ASTCFLAGS and ASTLDFLAGS can now
be provided *either* in the environment before running 'make', or as variable
assignments on the 'make' command line. As a result, the use of COPTS and LDOPTS
is no longer necessary, so they are no longer documented, but are still supported
so as not to break existing build systems that supply them when building Asterisk.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@207647 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This patch adds a new dahdi_wait function to specifically wait for the wink
event. If the wink is not eventually received the channel is hung up.
(closes issue #14434)
Reported by: araasch
Patches:
emwinkmod uploaded by araasch (license 693)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@207573 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Copied from Review board:
In issue 12434, the reporter describes a situation in which audio and video
is offered on the call, but because videosupport is disabled in sip.conf,
Asterisk gives no response at all to the video offer. According to RFC 3264,
all media offers should have a corresponding answer. For offers we do not
intend to actually reply to with meaningful values, we should still reply
with the port for the media stream set to 0.
In this patch, we take note of what types of media have been offered and
save the information on the sip_pvt. The SDP in the response will take into
account whether media was offered. If we are not otherwise going to answer
a media offer, we will insert an appropriate m= line with the port set to 0.
It is important to note that this patch is pretty much a bandage being
applied to a broken bone. The patch *only* helps for situations where video
is offered but videosupport is disabled and when udptl_pt is disabled but
T.38 is offered. Asterisk is not guaranteed to respond to every media offer.
Notable cases are when multiple streams of the same type are offered.
The 2 media stream limit is still present with this patch, too.
In trunk and the 1.6.X branches, things will be a bit different since Asterisk
also supports text in SDPs as well.
(closes issue #12434)
Reported by: mnnojd
Review: https://reviewboard.asterisk.org/r/311
Review: https://reviewboard.asterisk.org/r/313
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@207423 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
I changed this check to only happen in a dev-mode build. I also added a
comment explaining what is going on. I also made it so that detection of
this situation does not affect ast_read() operation.
(closes issue #14723)
Reported by: seadweller
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@207360 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/tags/1.4.26@207358 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/tags/1.4.26@207357 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/tags/1.4.26@207356 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Yep, it's even ifdefed out code. But it made it to the RR list...
(closes issue #14726)
Reported by: lmadsen
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@207155 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Previously overlap dialing could only be turned on or off for both incoming and
outgoing calls. New parameters incoming, outgoing, and both have been added to
allow further control. There is no change in default behavior with these new
options and allows in band DTMF to be accepted in one direction if required.
(closes issue #14471)
Reported by: eboscani
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@207092 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(issue #15376)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@207033 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Some ITSP make use of the "Anonymous" display name to detect a
requirement to withhold caller id across the PSTN. This does
not work if the display name is "Unknown".
(closes issue #14465)
Reported by: Nick_Lewis
Patches:
chan_sip.c-callerpres.patch uploaded by Nick (license 657)
chan_sip.c-callerpres_trunk.patch uploaded by dvossel (license 671)
Tested by: Nick_Lewis, dvossel
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@206938 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #15518)
Reported by: pkempgen
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@206872 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
If the CALLERPRES() dialplan function is set to nothing,
a segfault occurs. This is user error to begin with, but
I'd rather see a cli warning message than have Asterisk
crash on me.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@206867 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #15517)
Reported by: adomjan
Patches:
func_realtime.c-ast_variable_destroy.diff uploaded by adomjan (license 487)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@206807 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/be/branches/C.2-...
..........
Fixed chan_misdn crash because mISDNuser library is not thread safe.
With Asterisk the mISDNuser library is driven by two threads concurrently:
1. channels/misdn/isdn_lib.c::manager_event_handler()
2. channels/misdn/isdn_lib.c::misdn_lib_isdn_event_catcher()
Calls into the library are done concurrently and recursively from
isdn_lib.c.
Both threads can fiddle with the master/child layer3_proc_t lists. One
thread may traverse the list when the other interrupts it and then removes
the list element which the first thread was currently handling. This is
exactly what caused the crash. About 60 calls were needed to a Gigaset
CX475 before it occurred once.
This patch adds locking when calling into the mISDNuser library.
This also fixes some cb_log calls with wrong port parameter.
JIRA ABE-1913
Patches: misdn-locking.patch (Modified with mostly cosmetic changes)
..........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@206706 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@206635 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
* issue #14355 - Crash if attempt to transfer a call to an application.
Masquerade the other pair of the four asterisk channels involved in the
two calls. The held call already must be a bridged call (not an
applicaton) or it would have been rejected.
* issue #14692 - Held calls are not automatically cleared after transfer.
Allow the core to initate disconnect of held calls to the ISDN port. This
also fixes a similar case where the party on hold hangs up before being
transferred or taken off hold.
* JIRA ABE-1903 - Orphaned held calls left in music-on-hold.
Do not simply block passing the hangup event on held calls to asterisk
core.
* Fixed to allow held calls to be transferred to ringing calls.
Previously, held calls could only be transferred to connected calls.
* Eliminated unused call states to simplify hangup code.
* Eliminated most uses of "holded" because it is not a word.
(closes issue #14355)
(closes issue #14692)
Reported by: sodom
Patches:
misdn_xfer_v14_r205839.patch uploaded by rmudgett (license 664)
Tested by: rmudgett
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@206487 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r206384 | russell | 2009-07-14 09:45:47 -0500 (Tue, 14 Jul 2009) | 6 lines
Ensure apathetic replies are sent out on the proper socket.
chan_iax2 supports multiple address bindings. The send_apathetic_reply()
function did not attempt to send its response on the same socket that the
incoming message came in on.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@206385 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
JIRA ABE-1911
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@206284 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/tags/1.4.26-rc6@206224 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/tags/1.4.26-rc6@206223 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/tags/1.4.26-rc6@206222 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #14702)
Reported by: klaus3000
Patches:
patch_asterisk_1.4.23_CID_matching.txt uploaded by klaus3000 (license 65)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@206126 f38db490-d61c-443f-a65b-d21fe96a405b
|