to the Set app in trunk/1.6.x, as they come from the 1.4 world. They are only bitten if
they write their AEL dialplan in the 1.4 world, and then carry it over to a trunk/1.6.x
installation where a "make samples" was executed, or where they hand-edited the
asterisk.conf file and added the [compat] category with app_set = 1.6 (or higher).
(this commit does not totally solve 13249, at least not yet)
The change involves issueing a single warning while the AEL file is loading, if:
1. app_set is present in the config file, and set to 1.6 or higher.
2. there are double quotes in an assignment statement (eg x = "hi there";)
3. the warning was not already issued.
The standalone app, aelparse, does not (yet) issue this warning. I'd have to
have it read in the asterisk.conf file, and that's a bit of hassle. I'll add
it if users request it, tho.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@138815 65c4cc65-6c06-0410-ace0-fbb531ad65f3
of the name/value pairs, pointed out by snuffy-home on #asterisk-commits.
For those of you who rely on the position of name/value pairs in manager
events... stop... that is why associative arrays were invented.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@138482 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r138027 | russell | 2008-08-15 10:07:16 -0500 (Fri, 15 Aug 2008) | 9 lines
Ensure that when a hangup occurs in autoservice, that a hangup frame gets
properly deferred to be read from the channel owner when it gets taken out
of autoservice.
(closes issue #12874)
Reported by: dimas
Patches:
v1-12874.patch uploaded by dimas (license 88)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@138028 65c4cc65-6c06-0410-ace0-fbb531ad65f3
would reset to 500 ms every time a non-voice frame
was received. The total time we poll should be 500 ms, so
now we save the amount of time left after the poll returned
and use that as our argument for the next call to poll
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@136633 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Instead, poll the channel until receiving a voice frame. The
cap on this poll is 500 ms.
The optional delay is still allowable in the Answer() application,
but the delay has been moved back to its original position, after
the call to the channel's answer callback. The poll for the voice
frame will not happen if a delay is specified when calling Answer().
(closes issue #12708)
Reported by: kactus
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@136631 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r136062 | mmichelson | 2008-08-06 10:58:40 -0500 (Wed, 06 Aug 2008) | 16 lines
Since adding the AST_CONTROL_SRCUPDATE frame type,
there are places where ast_rtp_new_source may be called
where the tech_pvt of a channel may not yet have an
rtp structure allocated. This caused a crash in chan_skinny,
which was fixed earlier, but now the same crash has been
reported against chan_h323 as well. It seems that the best
solution is to modify ast_rtp_new_source to not attempt to
set the marker bit if the rtp structure passed in is NULL.
This change to ast_rtp_new_source also allows the removal
of what is now a redundant pointer check from chan_skinny.
(closes issue #13247)
Reported by: pj
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@136063 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r135841 | mmichelson | 2008-08-05 19:25:10 -0500 (Tue, 05 Aug 2008) | 27 lines
Merging the issue11259 branch.
The purpose of this branch was to take into account
"burps" which could cause jitterbuffers to misbehave.
One such example is if the L option to Dial() were used
to inject audio into a bridged conversation at regular
intervals. Since the audio here was not passed through
the jitterbuffer, it would cause a gap in the jitterbuffer's
timestamps which would cause a frames to be dropped for a
brief period.
Now ast_generic_bridge will empty and reset the jitterbuffer
each time it is called. This causes injected audio to be handled
properly.
ast_generic_bridge also will empty and reset the jitterbuffer
if it receives an AST_CONTROL_SRCUPDATE frame since the change
in audio source could negatively affect the jitterbuffer.
All of this was made possible by adding a new public API call
to the abstract_jb called ast_jb_empty_and_reset.
(closes issue #11259)
Reported by: plack
Tested by: putnopvut
........
r135847 | mmichelson | 2008-08-05 19:27:54 -0500 (Tue, 05 Aug 2008) | 4 lines
Revert inadvertent changes to app_skel that occurred when
I was testing for a memory leak
........
r135850 | mmichelson | 2008-08-05 19:29:54 -0500 (Tue, 05 Aug 2008) | 3 lines
Remove properties that should not be here
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@135851 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r135799 | murf | 2008-08-05 17:13:20 -0600 (Tue, 05 Aug 2008) | 34 lines
(closes issue #12982)
Reported by: bcnit
Tested by: murf
I discovered that also, in the previous bug fixes and changes,
the cdr.conf 'unanswered' option is not being obeyed, so
I fixed this.
And, yes, there are two 'answer' times involved in this
scenario, and I would agree with you, that the first
answer time is the time that should appear in the CDR.
(the second 'answer' time is the time that the bridge
was begun).
I made the necessary adjustments, recording the first
answer time into the peer cdr, and then using that to
override the bridge cdr's value.
To get the 'unanswered' CDRs to appear, I purposely
output them, using the dial cmd to mark them as
DIALED (with a new flag), and outputting them if
they bear that flag, and you are in the right mode.
I also corrected one small mention of the Zap device
to equally consider the dahdi device.
I heavily tested 10-sec-wait macros in dial, and
without the macro call; I tested hangups while the
macro was running vs. letting the macro complete
and the bridge form. Looks OK. Removed all the
instrumentation and debug.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@135821 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: falves11
Tested by: murf
falves11 ==
The changes I introduce here seem to clear up the problem
for me. However, if they do not for you, please reopen this
bug, and we'll keep digging.
The root of this problem seems to be a subtle memory corruption
introduced when creating an extension with an empty extension
name. While valgrind cannot detect it outside of DEBUG_MALLOC
mode, when compiled with DEBUG_MALLOC, this is certain death.
The code in main/features.c is a puzzle to me. On the initial
module load, the code is attempting to add the parking extension
before the features.conf file has even been opened!
I just wrapped the offending call with an if() that will not
try to add the extension if the extension name is empty. THis
seems to solve the corruption, and let the "memory show allocations"
work as one would expect.
But, really, adding an extension with an empty name is a seriously
bad thing to allow, as it will mess up all the pattern matching
algorithms, etc. So, I added a statement to the add_extension2 code to return
a -1 if this is attempted.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@135265 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r134883 | murf | 2008-07-31 13:23:42 -0600 (Thu, 31 Jul 2008) | 51 lines
(closes issue #11849)
Reported by: greyvoip
Tested by: murf
OK, a few days of debugging, a bunch of instrumentation
in chan_sip, main/channel.c, main/pbx.c, etc. and 5 solid
notebook pages of notes later, I have made the small
tweek necc. to get the start time right on the second
CDR when:
A Calls B
B answ.
A hits Xfer button on sip phone,
A dials C and hits the OK button,
A hangs up
C answers ringing phone
B and C converse
B and/or C hangs up
But does not harm the scenario where:
A Calls B
B answ.
B hits xfer button on sip phone,
B dials C and hits the OK button,
B hangs up
C answers ringing phone
A and C converse
A and/or C hangs up
The difference in start times on the second CDR is because
of a Masquerade on the B channel when the xfer number is
sent. It ends up replacing the CDR on the B channel with
a duplicate, which ends up getting tossed out. We keep
a pointer to the first CDR, and update *that* after the
bridge closes. But, only if the CDR has changed.
I hope this change is specific enough not to muck
up any current CDR-based apps. In my defence, I
assert that the previous information was wrong,
and this change fixes it, and possibly other
similar scenarios.
I wonder if I should be doing the same thing
for the channel, as I did for the peer, but
I can't think of a scenario this might affect.
I leave it, then, as an exersize for the users,
to find the scenario where the chan's CDR
changes and loses the proper start time.
........
and as to 1.4 to trunk; have I expressed my
feelings about code shifting from one file
to another? Good.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@134922 65c4cc65-6c06-0410-ace0-fbb531ad65f3
driver into a common place for multiple channel drivers.
(closes issue #13152)
Reported by: caio1982
Patches:
atxfer_complete_sound3.diff uploaded by caio1982 (license 22)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@134401 65c4cc65-6c06-0410-ace0-fbb531ad65f3
respectively. Also, take the opportunity to clean up the CLI prompt
generation code.
(closes issue #13175)
Reported by: eliel
Patches:
cliprompt.patch uploaded by eliel (license 64)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@134353 65c4cc65-6c06-0410-ace0-fbb531ad65f3
implementations. Asterisk has, for a long time,
had its own implementation of poll(2) which
just used the input arguments to call select(2).
In 1.4, this internal implementation was used
for Darwin systems. This was removed in Asterisk
trunk at some point, but it seems as though this
was not the right move to make.
On Mac OS X, it appears as though the poll used
to gather CLI input does not respond properly
when connecting via a remote Asterisk console.
Reverting to the use of Asterisk's poll fixed
the issue.
Also, there is now an option for the configure
script, --enable-internal-poll, which will allow
for anyone to use Asterisk's internal poll
implementation in case they suspect that their
system's poll implementation is buggy.
closes issue #11928)
Reported by: adriavidal
Patches:
1.6.0-configurev2.patch uploaded by putnopvut (license 60)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@134125 65c4cc65-6c06-0410-ace0-fbb531ad65f3
called from elsewhere in Asterisk to find the current state of a device. In
that case, we want to use the cached value if it exists. The other way is when
processing a device state change. In that case, we do not want to check the
cache because returning the last known state is counter productive.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@133945 65c4cc65-6c06-0410-ace0-fbb531ad65f3
we do NOT need to uri_decode in manager.
(if I sent core%20show%20channels from a telnet
session, it should be interpreted literally, however,
if I send that from an http session, it should be
decoded, which is the behaivor now)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@133770 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r133649 | tilghman | 2008-07-25 12:19:39 -0500 (Fri, 25 Jul 2008) | 8 lines
Fix some errant device states by making the devicestate API more strict in
terms of the device argument (only without the unique identifier appended).
(closes issue #12771)
Reported by: davidw
Patches:
20080717__bug12771.diff.txt uploaded by Corydon76 (license 14)
Tested by: davidw, jvandal, murf
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@133665 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ago (does not affect 1.4), where you would pass
a pointer to the end of a character array, and
ast_uri_decode would do no good.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@133651 65c4cc65-6c06-0410-ace0-fbb531ad65f3
to Asterisk licensing information. The licensing page includes the Asterisk license,
as well as a (not yet complete) list of 3rd party libraries that may be used, as well
as what license we receive them under.
Help filling out this list in the format that I have started in doxyref.h would be
much appreciated. :)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@133575 65c4cc65-6c06-0410-ace0-fbb531ad65f3
