https://origsvn.digium.com/svn/asterisk/branches/1.4
I had some work to do to port these changes to trunk; the
check_expr stuff hasn't been updated here for quite some
time, it appears. I added some more tests to the check_expr2
suite. I had to play around with the makefile a bit, etc.
I added STANDALONE2 #ifdefs to ast_expr2.y so as not to
conflict structure with aelparse.
........
r179807 | murf | 2009-03-03 11:11:34 -0700 (Tue, 03 Mar 2009) | 19 lines
These changes allow AEL to better check ${} constructs within $[...], that are concatenated with text.
I modified and added rules in ast_expr2.fl to better handle
the concatenations.
I added some default routines to ast_expr2.y so the standalone would
compile. It also looks like I haven't run this thru bison since 2.1, so
it's good to get this updated.
The Makefile has comments added now for check_expr2 and check_expr to
explain what they are for, and how to run them.
The testexpr2s stuff has been removed, in favor of check_expr2.
expr2.testinput has been updated to include the two expressions
that inspired these changes (from mcnobody on #asterisk this morning)
The regression has been run and all looks well.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@179973 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r179840 | file | 2009-03-03 14:27:09 -0400 (Tue, 03 Mar 2009) | 9 lines
Do not assume that the bridge_cdr is still attached to the channel when the 'h' exten is finished executing.
It is possible for a masquerade operation to occur when the 'h' exten is operating. This operation moves
the CDR records around causing the bridge_cdr to no longer exist on the channel where it is expected to.
We can not safely modify it afterwards because of this, so don't even try.
(closes issue #14564)
Reported by: meric
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@179841 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r179741 | russell | 2009-03-03 10:45:46 -0600 (Tue, 03 Mar 2009) | 6 lines
Ensure chan->fdno always gets reset to -1 after handling a channel fd event.
Since setting fdno to -1 had to be moved, a couple of other code paths that
do process an fd event return early and do not pass through the code path
where it was moved to. So, set it to -1 in a few other places, too.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@179742 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r179671 | file | 2009-03-03 10:38:09 -0400 (Tue, 03 Mar 2009) | 3 lines
Move where fdno is set to the default value to *after* the read callback of the channel driver is called.
We have to do this as the underlying channel driver may need the fdno value to determine what to read.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@179672 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r179608 | russell | 2009-03-03 07:53:52 -0600 (Tue, 03 Mar 2009) | 9 lines
Make it easier to detect an improper call to ast_read().
When you call ast_waitfor() on a channel, the index into the channel fds array
that holds the file descriptor that poll() determines has input available is
stored in fdno. This patch clears out this value after a call to ast_read()
and also reports errors if ast_read() is called without an fdno set.
From a discussion on the asterisk-dev list.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@179609 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r179536 | jpeeler | 2009-03-02 17:54:39 -0600 (Mon, 02 Mar 2009) | 15 lines
Fix bridging regression from commit 176701
This fixes a bad regression where the bridge would exit after an attended
transfer was made. The problem was due to nexteventts getting set after the
masquerade which caused the bridge to return AST_BRIDGE_COMPLETE.
(closes issue #14315)
Reported by: tim_ringenbach
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@179537 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r179468 | tilghman | 2009-03-02 17:09:01 -0600 (Mon, 02 Mar 2009) | 10 lines
When ending a recording with silence detection, remember to reduce the duration.
The end of the recording is correspondingly trimmed, but the duration was not
trimmed by the number of seconds trimmed, so the saved duration was necessarily
longer than the actual soundfile duration.
(closes issue #14406)
Reported by: sasargen
Patches:
20090226__bug14406.diff.txt uploaded by tilghman (license 14)
Tested by: sasargen
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@179469 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r179461 | russell | 2009-03-02 16:58:18 -0600 (Mon, 02 Mar 2009) | 8 lines
Ensure that only one thread is calling ast_settimeout() on a channel at a time.
For example, with an IAX2 channel, you can have both the channel thread and the
chan_iax2 processing threads calling this function, and doing so twice at the
same time is a bad thing.
(Found in a debugging session with dvossel and mmichelson)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@179462 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
In this case, it's just a matter of reducing the default timeouts from 2000
to 1000 msec, as the max def feature digit timeout is no longer halved.
........
r178956 | murf | 2009-02-26 14:27:32 -0700 (Thu, 26 Feb 2009) | 18 lines
This change moves the default feature digit timeout to 1000 ms from the previous default of 500.
As per bug 14515, a dev discussion arrived at a "mediated concensus"
of a default feature digit timeout of 1.0 sec. Some voted for 1300;
ctooley thought 1500 for distracted phone users in phone booths;
kpfleming put his foot down at 1.0 sec.
Users who found the previous default max delay of 250 msec perfect,
are welcome to override the new default. Notice that I said that
250 msec was the default; wait a minute, you might say, the config
file said it was 500 msec!; well, because of the bug fix for 14515,
we found that 500 msec was actually enforcing a max of 250. The bug
fix would restore 500 msec, but we felt even that was a bit tight
for most users... 2000 msec was pushed earlier by mmichelson, so
that reduces to 1000 msec after the bug fix. Enjoy!
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@178986 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r178804 | murf | 2009-02-26 10:09:03 -0700 (Thu, 26 Feb 2009) | 28 lines
This patch prevents the feature detection timeout from being cut in half.
Because the ast_channel_bridge() call will return 0 and pass
a frame pointer for both DTMF_BEGIN and DTMF_END, the feature_timer
field in hte config struct is getting decremented twice, which
effectively cuts the digittimeout in half. I added conditions
to the if statement to only let DTMF_END frames to flow thru,
which solved the problem. Also, when the frame pointer is null,
let control flow thru-- this usually happens on timeouts. I added
a comment to the code to explain what's going on and why.
Many thanks to sodom for reporting this problem. Personnally, it always seemed
like something was wrong with the featuredigittimeout, but I never
could quite decide what... and was too busy to investigate.
This bug forced the issue, and now we know.
Sodom had other issues in 14515, but I couldn't reproduce them. If
he still has problems, and wants to get them solved, he is welcome
to reopen 14515.
(closes issue #14515)
Reported by: sodom
Patches:
14515.patch uploaded by murf (license 17)
Tested by: murf, sodom
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@178828 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r178141 | russell | 2009-02-23 17:09:01 -0600 (Mon, 23 Feb 2009) | 14 lines
Fix infinite DTMF when a BEGIN is received without an END.
This commit is related to rev 175124 of 1.4 where a previous attempt was made
to fix this problem. The problem with the previous patch was that the inserted
code needed to go _before_ setting the lastrxts to the current timestamp.
Because those were the same, the dtmfcount variable was never decremented, and
so the END was never sent.
In passing, I removed the dtmfsamples variable which was completed unused. I
also removed a redundant setting of the lastrxts variable.
(closes issue #14460)
Reported by: moliveras
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@178142 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177786 | tilghman | 2009-02-20 16:59:52 -0600 (Fri, 20 Feb 2009) | 9 lines
Don't print the CR-NL combination when we aren't outputting to the manager.
An embedded CR-NL in a CLI command screws up several AMI parsers that don't
expect to see that combination in the middle of output.
(Closes issue #14305)
Reported by: martins
Patch by: tilghman
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177787 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
Trunk was already pretty 8-bit clean; but I'm still
removing the --full from the flex command so everything
is uniform.
........
r177540 | murf | 2009-02-19 15:51:37 -0700 (Thu, 19 Feb 2009) | 21 lines
This patch fixes a problem with 8-bit input to the ast_expr2 scanner.
The real culprit was the --full argument to flex
in the Makefile! This causes a 7-bit scanner to be
generated.
I reviewed the rules and found one rule where I needed
to specifically include 8-bit chars for a token.
I tested against the text supplied by ibercom, and
all looks very well.
This has been there a surprisingly long time!
(closes issue #14498)
Reported by: ibercom
Patches:
14498.patch uploaded by murf (license 17)
Tested by: murf
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177595 65c4cc65-6c06-0410-ace0-fbb531ad65f3
action_bridge() and bridge_exec() both search for the channels to bridge to, and then immediately drop the lock. Instead, they should hold the lock until the masquerade is complete. This will guarantee the channel remains and prevent any other weirdness from occurring. In action_bridge() some more weirdness comes into play. Both channels are needlessly locked at the same time and perform the exact same logic. It makes sense from a coding organizational standpoint, but could cause a theoretical deadlock so I split the code up. There is an issue associated with this, but since its a rather complicated thing to reproduce I'm not certain this alone will close it.
issue# 14296
Review: http://reviewboard.digium.com/r/167/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@177226 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The big problem here is that the 3rd argument provided in these uses of strncpy()
did not reserve a byte for the null terminator, leaving the potential for writing
one byte past the end of the buffer.
Aside from this, there were coding guidelines violations with regards to spacing,
as well as hard coded lengths being used instead of sizeof().
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@176901 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r176701 | jpeeler | 2009-02-17 15:54:34 -0600 (Tue, 17 Feb 2009) | 17 lines
Modify bridging to properly evaluate DTMF after first warning is played
The main problem is currently if the Dial flag L is used with a warning sound,
DTMF is not evaluated after the first warning sound. To fix this, a flag has
been added in ast_generic_bridge for playing the warning which ensures that if
a scheduled warning is missed, multiple warrnings are not played back (due to a
feature evaluation or waiting for digits). ast_channel_bridge was modified to
store the nexteventts in the ast_bridge_config structure as that information
was lost every time ast_channel_bridge was reentered, causing a hangup due to
incorrect time calculations.
(closes issue #14315)
Reported by: tim_ringenbach
Reviewed on reviewboard:
http://reviewboard.digium.com/r/163/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@176708 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1) Add module use count handling so that timing modules can be unloaded.
2) Implement unload_module() functions for the timing interface modules.
3) Allow multiple timing modules to be loaded, and use the one with the
highest priority value.
4) Report which timing module is being use in the "timing test" CLI command.
(closes issue #14489)
Reported by: russell
Review: http://reviewboard.digium.com/r/162/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@176666 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch changes the scheduler to use a max-heap to store pending scheduler
entries instead of a fully sorted doubly linked list. When the number of
entries in the scheduler gets large, this will perform much better. For much
more detailed information on this change, see the review request.
Review: http://reviewboard.digium.com/r/160/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@176639 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch includes a number of changes to the indications API. The primary
motivation for this work was to improve stability. The object management
in this API was significantly flawed, and a number of trivial situations could
cause crashes.
The changes included are:
1) Remove the module res_indications. This included the critical functionality
that actually loaded the indications configuration. I have seen many people
have Asterisk problems because they accidentally did not have an
indications.conf present and loaded. Now, this code is in the core,
and Asterisk will fail to start without indications configuration.
There was one part of res_indications, the dialplan applications, which did
belong in a module, and have been moved to a new module, app_playtones.
2) Object management has been significantly changed. Tone zones are now
managed using astobj2, and it is no longer possible to crash Asterisk by
issuing a reload that destroys tone zones while they are in use.
3) The API documentation has been filled out.
4) The API has been updated to follow our naming conventions.
5) Various bits of code throughout the tree have been updated to account
for the API update.
6) Configuration parsing has been mostly re-written.
7) "Code cleanup"
The code is from svn/asterisk/team/russell/indications/.
Review: http://reviewboard.digium.com/r/149/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@176627 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The problem here is that the hint processing code was subscribed to the wrong
event type. So, it started processing state for a hint too soon, before the
device state cache had been updated.
Also, fix a similar bug in app_queue, as it was also subscribed to the wrong
event type.
(closes issue #14461)
Reported by: alecdavis
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@176557 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r176216 | kpfleming | 2009-02-16 15:10:38 -0600 (Mon, 16 Feb 2009) | 3 lines
fix a flaw in the ast_string_field_build() family of API calls; these functions made no attempt to reuse the space already allocated to a field, so every time the field was written it would allocate new space, leading to what appeared to be a memory leak.
........
r176254 | kpfleming | 2009-02-16 15:41:46 -0600 (Mon, 16 Feb 2009) | 3 lines
correct a logic error in the last stringfields commit... don't mark additional space as allocated if the string was built using already-allocated space
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@176255 65c4cc65-6c06-0410-ace0-fbb531ad65f3
I was finding that on my dev box, occasionally attempting to "stop now" in
trunk would cause Asterisk to hang. I traced this to the fact that the logger
thread was waiting on a condition which had already been signalled. The logger
thread also need to be sure to check the value of the close_logger_thread variable.
The close_logger_thread variable is only checked when the list of logmessages is empty.
This allows for the logger thread to print and free any pending messages before exiting.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@176174 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1) It had numerous coding guidelines violations with regards to formatting.
2) It allocated memory using ast_calloc() that was never freed.
3) It didn't check for failure from the allocation.
4) It used sprintf() and strcat() to build the result, doing zero checking to
prevent writing past the end of the provided buffer.
The function also lacks API documentation, but that has not been addressed in
this commit.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@175829 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds passthrough, file recording and file playback support for the codecs listed above, with negotiation over SIP/SDP supported. Due to Asterisk's current limitation of treating a codec/bitrate combination as a unique codec, only G.722.1 at 32 kbps and G.722.1C at 48 kbps are supported.
Along the way, some related work was done:
1) The rtpPayloadType structure definition, used as a return result for an API call in rtp.h, was moved from rtp.c to rtp.h so that the API call was actually usable. The only previous used of the API all was chan_h323.c, which had a duplicate of the structure definition instead of doing it the right way.
2) The hardcoded SDP sample rates for various codecs in chan_sip.c were removed, in favor of storing these sample rates in rtp.c along with the codec definitions there. A new API call was added to allow retrieval of the sample rate for a given codec.
3) Some basic 'a=fmtp' parsing for SDP was added to chan_sip, because chan_sip *must* decline any media streams offered for these codecs that are not at the bitrates that we support (otherwise Bad Things (TM) would result).
Review: http://reviewboard.digium.com/r/158/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@175508 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r175311 | tilghman | 2009-02-12 15:19:40 -0600 (Thu, 12 Feb 2009) | 9 lines
Fix crashes when receiving certain T.38 packets. Also, increase the maximum
size of T.38 packets and warn users when they try to set the limits above those
maximums.
(closes issue #13050)
Reported by: schern
Patches:
20090212__bug13050.diff.txt uploaded by Corydon76 (license 14)
Tested by: schern
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@175334 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r175294 | jpeeler | 2009-02-12 14:34:36 -0600 (Thu, 12 Feb 2009) | 9 lines
Fix ParkedCall event information for From field in the case of a blind transfer
If the parker information can not be obtained from the peer, try and see if
the BLINDTRANSFER channel variable has been set. Previously, a blind transfer
to the ParkAndAnnounce app would return nothing for the From.
Closes AST-189
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@175298 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r175187 | jpeeler | 2009-02-12 11:57:10 -0600 (Thu, 12 Feb 2009) | 6 lines
Fix crash in event of failed attempt to transfer to parking
The peer may not necessarily exist, such as in the case of a transfer to
ParkAndAnnounce. In this case don't try to play a sound to it.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@175188 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r175124 | russell | 2009-02-12 10:51:13 -0600 (Thu, 12 Feb 2009) | 27 lines
Don't send DTMF for infinite time if we do not receive an END event.
I thought that this was going to end up being a pretty gnarly fix, but it turns
out that there was actually already a configuration option in rtp.conf,
dtmftimeout, that was intended to handle this situation. However, in between
Asterisk 1.2 and Asterisk 1.4, the code that processed the option got lost.
So, this commit brings it back to life.
The default timeout is 3 seconds. However, it is worth noting that having
this be configurable at all is not really the recommended behavior in RFC 2833.
From Section 3.5 of RFC 2833:
Limiting the time period of extending the tone is necessary
to avoid that a tone "gets stuck". Regardless of the
algorithm used, the tone SHOULD NOT be extended by more than
three packet interarrival times. A slight extension of tone
durations and shortening of pauses is generally harmless.
Three seconds will pretty much _always_ be far more than three packet
interarrival times. However, that behavior is not required, so I'm going to
leave it with our legacy behavior for now.
Code from svn/asterisk/team/russell/issue_14460
(closes issue #14460)
Reported by: moliveras
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@175125 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Core show locks information involving an ao2_trylock did not
show the function that called ao2_trylock, but would instead
show ao2_trylock as the source of the lock. This is not useful
when trying to debug locking issues.
One bizarre note is that this logic is already in 1.4 but somehow
did not get merged to trunk or the 1.6.X branches.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@175121 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The 'd' option would not work for channel types which use RTP to transport
DTMF digits. The only way to allow for this to work was to answer the channel
if we saw that this option was enabled.
I realized that this may cause issues with CDRs, specifically with giving false
dispositions and answer times. I therefore modified ast_answer to take another
parameter which would tell if the CDR should be marked answered.
I also extended this to the Answer application so that the channel may be answered
but not CDRified if desired.
I also modified app_dictate and app_waitforsilence to only answer the channel if it
is not already up, to help not allow for faulty CDR answer times.
All of these changes are going into Asterisk trunk. For 1.6.0 and 1.6.1, however, all
the changes except for the change to the Answer application will go in since we do
not introduce new features into stable branches
(closes issue #14164)
Reported by: DennisD
Patches:
14164.patch uploaded by putnopvut (license 60)
Tested by: putnopvut
Review: http://reviewboard.digium.com/r/145
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@174945 65c4cc65-6c06-0410-ace0-fbb531ad65f3
We need to do this because while we know that the freeing of the channel may cause something to become
not in use we do not know this for sure. There may be another channel that is still up which would cause
it to be in use.
(closes issue #13238)
Reported by: kowalma
Patches:
20090121__bug13238.diff.txt uploaded by Corydon76 (license 14)
Tested by: alecdavis
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@174844 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The explanation behind this fix is a bit complicated, and I've already
typed it up in the code as a huge comment inside of manager.c, so I'll
give the abridged version here.
We needed a way to separate action-specific data from session-specific data.
Unfortunately, the only way to maintain API compatibility and to not have to
change every single manager action was to rename the current mansession structure
and wrap it inside a new mansession structure which actually contains action-
specific data.
(closes issue #14364)
Reported by: awk
Patches:
14364_better.patch uploaded by putnopvut (license 60)
Tested by: putnopvut
Review: http://reviewboard.digium.com/r/148/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@174764 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r174583 | mnicholson | 2009-02-10 11:52:42 -0600 (Tue, 10 Feb 2009) | 18 lines
Improve behavior of jitterbuffer when maxjitterbuffer is set.
This change improves the way the jitterbuffer handles maxjitterbuffer and
dramatically reduces the number of frames dropped when maxjitterbuffer is
exceeded. In the previous jitterbuffer, when maxjitterbuffer was exceeded, all
new frames were dropped until the jitterbuffer is empty. This change modifies
the code to only drop frames until maxjitterbuffer is no longer exceeded.
Also, previously when maxjitterbuffer was exceeded, dropped frames were not
tracked causing stats for dropped frames to be incorrect, this change also
addresses that problem.
(closes issue #14044)
Patches:
bug14044-1.diff uploaded by mnicholson (license 96)
Tested by: mnicholson
Review: http://reviewboard.digium.com/r/144/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@174584 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit expands the Asterisk scheduler API to include a common implementation
of a scheduler context being processed by a dedicated thread. chan_iax2 has been
updated to use this new code. Also, as a result, this resolves some race
conditions related to the previous chan_iax2 scheduler handling.
Related to rev 171452 which resolved the same issues in 1.4.
Code from team/russell/sched_thread2
Review: http://reviewboard.digium.com/r/129/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@173858 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r173211 | jpeeler | 2009-02-03 15:57:01 -0600 (Tue, 03 Feb 2009) | 17 lines
Parking attempts made to one end of a bridge no longer will hang up due to a
parking failure.
Parking attempts made using either one-touch, or doing either a blind or
assisted transfer to the parking extension now keep up the bridge instead of
hanging up the attempted parked party. Normal causes for the parking attempt
to fail includes the specific specified extension (via PARKINGEXTEN) not being
available or if all the parking spaces are currently in use. To avoid having
to reverse a masquerade park_space_reserve was made to provide foresight if
a parking attempt will succeed and if so reserve the parking space.
(closes issue #13494)
Reported by: mdu113
Reviewed by Russell: http://reviewboard.digium.com/r/133/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@173500 65c4cc65-6c06-0410-ace0-fbb531ad65f3
an fseek() on the stream, which is an invalid operation for a socket. Turning
off buffering explicitly lets the stdio functions know they cannot do this,
thus avoiding a potential error.
(closes issue #14400)
Reported by: fnordian
Patches:
tcptls.patch uploaded by fnordian (license 110)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@173458 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The problem came from the fact that a frame read from a format interpreter
was not freed. Adding a call to ast_frfree fixed this. The explanation for
why this caused the problem is a bit complex, but here goes:
There was a problem in all versions of Asterisk where the embedded frame
of a filestream structure was referenced after the filestream was freed. This
was fixed by adding reference counting to the filestream structure. The refcount
would increase every time that a filestream's frame pointer was pointing to an
actual frame of data. When the frame was freed, the refcount would decrease. Once
the refcount reached 0, the filestream was freed, and as part of the operation,
the open files were closed as well.
Thus it becomes more clear why a missing ast_frfree would cause a reference leak
and cause the files to not be closed. You may ask then if there was a frame leak
before this patch. The answer to that is actually no! The filestream code was
"smart" enough to know that since the frame we received came from a format interpreter,
the frame had no malloced data and thus didn't need to be freed. Now, however, there
is cleanup that needs to be done when we finish with the frame, so we do need to
call ast_frfree on the frame to be sure that the refcount for the filestream is
decremented appropriately.
(closes issue #14384)
Reported by: fiddur
Patches:
14384.patch uploaded by putnopvut (license 60)
Tested by: fiddur, putnopvut
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@173354 65c4cc65-6c06-0410-ace0-fbb531ad65f3
interfere with correct parsing of the extension. Also, if an unterminated
character class DOES make its way into the pbx core (through some other
method), ensure that it does not crash Asterisk.
(closes issue #14362)
Reported by: Nick_Lewis
Patches:
20090129__bug14362.diff.txt uploaded by Corydon76 (license 14)
Tested by: Corydon76
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@173311 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2. Use curl to download sound files, as curl is installed natively on OS X,
whereas wget and fetch are not.
(closes issue #14332)
Reported by: oej
Tested by: Corydon76
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@173130 65c4cc65-6c06-0410-ace0-fbb531ad65f3
to be used within the dial app, before a call is bridged.
Many thanks to sobomax for submitting this patch.
Quoting from bug 11582:
"So the goal of the patch was to use the user configured feature code during the
call setup phase. The original ast_feature_interpret() function is not well suited
for this purpose as it uses much call bridge specific data and doesn't separate a
detection of feature from a feature handler call. So a new function ast_feature_detect()
has been extracted off the ast_feature_interpret() function but keeping the original
logic intact except some insignificant changes to locking.
"Having created the ast_feature_detect() function the possibility to use feature detection
in almost any place of the asterisk code. So a call to this function has been added to
wait_for_answer() function of app_dial.so module. This code doesn't call the feature handler
however and uses old call leg disconnect logic to make the changes as small and simple as
possible to prevent unexpected problems. A disconnect feature currently is the only one
supported during call setup as other features as call parking and call transfer don't make much
sense during call setup. However if need in some of the features would arise it is much easier to
implement as the infrastructure changes are already in place with this patch."
I have cleaned up the patch somewhat, and verified that the existing functionality is not
harmed, and that the new functionality works. Terry has committed his stuff, and there were
no conflicts (see 14274).
(closes issue #11583)
Reported by: sobomax
Patches:
patch-apps__app_dial.c uploaded by sobomax (license 359)
patch-include__asterisk__features.h uploaded by sobomax (license 359)
patch-res__res_features.c uploaded by sobomax (license 359)
enable-features-during-call-setup.diff uploaded by sobomax (license 359)
11583.newdiff uploaded by murf (license 17)
enable-features-during-call-setup-1.diff uploaded by sobomax (license 359)
11583.latest-patch uploaded by murf (license 17)
Tested by: sobomax, murf
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172890 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172517 | twilson | 2009-01-30 11:47:41 -0600 (Fri, 30 Jan 2009) | 37 lines
Fix feature inheritance with builtin features
When using builtin features like parking and transfers, the AST_FEATURE_* flags
would not be set correctly for all instances when either performing a builtin
attended transfer, or parking a call and getting the timeout callback. Also,
there was no way on a per-call basis to specify what features someone should
have on picking up a parked call (since that doesn't involve the Dial() command).
There was a global option for setting whether or not all users who pickup a
parked call should have AST_FEATURE_REDIRECT set, but nothing for DISCONNECT,
AUTOMON, or PARKCALL.
This patch:
1) adds the BRIDGE_FEATURES dialplan variable which can be set either in the
dialplan or with setvar in channels that support it. This variable can be set
to any combination of 't', 'k', 'w', and 'h' (case insensitive matching of the
equivalent dial options), to set what features should be activated on this
channel. The patch moves the setting of the features datastores into the
bridging code instead of app_dial to help facilitate this.
2) adds global options parkedcallparking, parkedcallhangup, and
parkedcallrecording to be similar to the parkedcalltransfers option for
globally setting features.
3) has builtin_atxfer call builtin_parkcall if being transfered to the parking
extension since tracking everything through multiple masquerades, etc. is
difficult and error-prone
4) attempts to fix all cases of return calls from parking and completed builtin
transfers not having the correct permissions
(closes issue #14274)
Reported by: aragon
Patches:
fix_feature_inheritence.diff.txt uploaded by otherwiseguy (license 396)
Tested by: aragon, otherwiseguy
Review http://reviewboard.digium.com/r/138/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172580 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172438 | tilghman | 2009-01-29 16:54:29 -0600 (Thu, 29 Jan 2009) | 9 lines
Lose the CAP_NET_ADMIN at every fork, instead of at startup. Otherwise, if
Asterisk runs as a non-root user and the administrator does a 'restart now',
Asterisk loses the ability to set QOS on packets.
(closes issue #14004)
Reported by: nemo
Patches:
20090105__bug14004.diff.txt uploaded by Corydon76 (license 14)
Tested by: Corydon76
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172441 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- Also, change a function in app.c to return a userful value instead of always returning 0.
Patch by fnordian, changed by Corydon76 and myself.
This does not close the bug report, as fnordian had an additional change we're still discussing.
(related to issue #14059)
Reported by: fnordian
Patches:
chan_sip_hfield.patch uploaded by fnordian (license 110)
20090116__bug14059.diff.txt uploaded by Corydon76 (license 14)
Tested by: fnordian, Corydon76, oej
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172268 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172030 | murf | 2009-01-28 11:51:16 -0700 (Wed, 28 Jan 2009) | 46 lines
This patch fixes h-exten running misbehavior in manager-redirected
situations.
What it does:
1. A new Flag value is defined in include/asterisk/channel.h,
AST_FLAG_BRIDGE_HANGUP_DONT, which used as a messenge to the
bridge hangup exten code not to run the h-exten there (nor
publish the bridge cdr there). It will done at the pbx-loop
level instead.
2. In the manager Redirect code, I set this flag on the channel
if the channel has a non-null pbx pointer. I did the same for the
second (chan2) channel, which gets run if name2 is set...
and the first succeeds.
3. I restored the ending of the cdr for the pbx loop h-exten
running code. Don't know why it was removed in the first place.
4. The first attempt at the fix for this bug was to place code
directly in the async_goto routine, which was called from a
large number of places, and could affect a large number of
cases, so I tested that fix against a fair number of transfer
scenarios, both with and without the patch. In the process,
I saw that putting the fix in async_goto seemed not to affect
any of the blind or attended scenarios, but still, I was
was highly concerned that some other scenarios I had not tested
might be negatively impacted, so I refined the patch to
its current scope, and jmls tested both. In the process, tho,
I saw that blind xfers in one situation, when the one-touch
blind-xfer feature is used by the peer, we got strange
h-exten behavior. So, I inserted code to swap CDRs and
to set the HANGUP_DONT field, to get uniform behavior.
5. I added code to the bridge to obey the HANGUP_DONT flag,
skipping both publishing the bridge CDR, and running
the h-exten; they will be done at the pbx-loop (higher)
level instead.
6. I removed all the debug logs from the patch before committing.
7. I moved the AUTOLOOP set/reset in the h-exten code in res_features
so it's only done if the h-exten is going to be run. A very
minor performance improvement, but technically correct.
(closes issue #14241)
Reported by: jmls
Patches:
14241_redirect_no_bridgeCDR_or_h_exten_via_transfer uploaded by murf (license 17)
Tested by: murf, jmls
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172063 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r171621 | mmichelson | 2009-01-27 14:06:01 -0600 (Tue, 27 Jan 2009) | 18 lines
Prevent a crash from occurring when a jitter buffer interpolated frame is
removed from a slinfactory
slinfactory used the "samples" field of an ast_frame in order to determine
the amount of data contained within the frame. In certain cases, such as
jitter buffer interpolated frames, the frame would have a non-zero value for
"samples" but have NULL "data"
This caused a problem when a memcpy call in ast_slinfactory_read would attempt
to access invalid memory. The solution in use here is to never feed frames into
the slinfactory if they have NULL "data"
(closes issue #13116)
Reported by: aragon
Patches:
13116.diff uploaded by putnopvut (license 60)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@171622 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r170648 | file | 2009-01-23 16:16:39 -0400 (Fri, 23 Jan 2009) | 4 lines
When a channel is answered make sure any indications currently playing stop. Usually the phone would do this but if the channel was already answered then they are being generated by Asterisk and we darn well need to stop them.
(closes issue #14249)
Reported by: RadicAlish
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@170652 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r170392 | mmichelson | 2009-01-23 09:40:39 -0600 (Fri, 23 Jan 2009) | 28 lines
Fix broken call pickup
There was a subtle change in ast_do_masquerade which
resulted in failed attempts to pickup calls. The problem
was that the value of the AST_FLAG_OUTGOING flag was
copied from the clone to the original channel. In the case
of call pickup, this meant that the AST_FLAG_OUTGOING flag
ended up being cleared on the channel that was attempting
to execute the pickup.
Because this flag was not set, when ast_read came across
an answer frame, it ignored it. The result of this was that
the calling channel was never properly answered.
This fix changes the behavior in ast_do_masquerade to set
the flags on the original channel to the union of the flags
on the clone channel. This way, if the AST_FLAG_OUTGOING
flag is set on either of the two channels involved in the
masquerade, the resulting channel will have the flag set
as well.
(closes issue #14206)
Reported by: francesco_r
Patches:
14206.patch uploaded by putnopvut (license 60)
Tested by: francesco_r, aragon, putnopvut
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@170393 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r170050 | file | 2009-01-22 11:13:56 -0400 (Thu, 22 Jan 2009) | 6 lines
Do a string comparison instead of pointer comparison since some people specify the context they are actually in as an argument to get around some funkiness.
(closes issue #14011)
Reported by: dveiga
Patches:
pbx.c.patch uploaded by dveiga (license 665)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@170051 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit fixes a crash that was occurring when attempting to
say a number between 10000 and 100000 due to dividing by 0.
This also removes some places where a "zero" is spoken when it
should not be.
(closes issue #14291)
Reported by: dant
Patches:
say.c-14291.diff uploaded by dant (license 670)
Tested by: dant
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@169794 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r169722 | tilghman | 2009-01-21 15:02:32 -0600 (Wed, 21 Jan 2009) | 8 lines
Extra NULLs in the output cause some terminal types to abort in the middle of
a color code, causing terminal weirdness.
(closes issue #14130)
Reported by: coolmig
Patches:
20090121__bug14130.diff.txt uploaded by Corydon76 (license 14)
Tested by: Corydon76, coolmig
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@169723 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes a problem that caused chan_sip to think that every open TCP session
was to a remote address of 0.0.0.0:0.
(closes issue #14287)
Reported by: jamesgolovich
Patches:
bug-14287.diff.txt uploaded by jamesgolovich (license 176)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@169620 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is an ugly hack from 1.4 that allows the timeout callback from a parked
call to use the right channel name for the callback when the park is done with
a builtin attended transfer (that isn't completed early). This hasn't ever
worked in trunk and no one has complained yet, so eh.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@169510 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The HW_PHYSMEM64 is only available in latest OpenBSD and/or amd64 versions of OpenBSD.
Use HW_PHYSMEM when HW_PHYSMEM64 is not available.
(closes issue #14129)
Reported by: ys
Patches:
2009011600_physmem64.diff.txt uploaded by mvanbaak (license 7)
Tested by: mvanbaak, jtodd
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@169327 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r168716 | twilson | 2009-01-15 12:22:49 -0600 (Thu, 15 Jan 2009) | 12 lines
Convert call to park_call_full to masq_park_call_announce
Since we removed the AST_PBX_KEEPALIVE return value, we need to use masqueraded
parking, otherwise we will try to call ast_hangup() in __pbx_run() and in
do_parking_thread() and then promptly crash.
(closes issue #14215)
Reported by: waverly360
Tested by: otherwiseguy
(closes issue #14228)
Reported by: kobaz
Tested by: otherwiseguy
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@168941 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Steve Murphy
Joshua Colp
Russell Bryant
Jeff Peeler
Tilghman Lesher
Jason Parker
Michiel van Baak
Sean Bright
Kevin P. Fleming
David Vossel
Doug Bailey
Olle Johansson
Mark Michelson
Matthew Nicholson
Terry Wilson
Richard Mudgett