| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/tags/1.4.24-rc1@180605 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/tags/1.4.24-rc1@180596 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/tags/1.4.24-rc1@180577 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@180567 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
enum.c did not handle regex backtraces correctly. The '\1' in the regex is a backreference that requires a pattern match to be inserted. The way the code used to work is that it would find the backreference and insert the entire input string minus the '+'. This is incorrect. The regexec() function takes in a variable called pmatch which is an array of structs containing the start and end indexes for each backreference substring. The original code actually passed the pmatch array pointer into regexec but never did anything with it. Now when a backtrace is found, the backtrace number is looked up in the pmatch array and the correct substring is inserted.
(closes issue #14576)
Reported by: chris-mac
Review: http://reviewboard.digium.com/r/187/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@180532 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
defined in separate contexts.
There was a fix put in a while back so that an X-Asterisk-VM-Context message header was
added to stored IMAP voicemails. This would allow for us to differentiate if the same
mailbox name was used in multiple contexts. The problem still left was that not all places
where messages were retrieved actually attempted to use this header for information when
retrieving messages. This commit fixes that so that MWI and message retrieval from VoiceMailMain
work as expected.
(closes issue #13853)
Reported by: vicks1
Patches:
13853_v2.patch uploaded by mmichelson (license 60)
Tested by: lmadsen
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@180464 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
When using the searchcontexts option in voicemail.conf, the code
made the assumption that all mailbox names defined were unique across
all contexts. However, the code did nothing to actually enforce this
assumption, nor did it do anything to alert a user that he may have
created an ambiguity in his voicemail.conf file by defining the same
mailbox name in multiple contexts.
With this change, we now will issue a nice long warning if searchcontexts
is on and we encounter the same mailbox name in multiple contexts and ignore
any duplicates after the first box. Whether searchcontexts is enabled or not,
if we come across a duplicate mailbox in the same context, then we will issue
a warning and ignore the duplicated mailbox. I have also added a small note
to voicemail.conf.sample in the explanation for searchcontexts explaining
that you cannot define the same mailbox in multiple contexts if you have
enabled the option.
(closes issue #14599)
Reported by: lmadsen
Patches:
14599.patch uploaded by mmichelson (license 60) (with slight modification)
Tested by: lmadsen
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@180380 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
During some code analysis, I found that calling ast_rtp_codec_setpref() on an ast_rtp session does not work as expected; it does not adjust the smoother that may on the RTP session, in fact it summarily drops it, even if it has data in it, even if the current format's framing size has not changed. This is not good.
This patch changes this behavior, so that if the packetization size for the current format changes, any existing smoother is safely updated to use the new size, and if no smoother was present, one is created. A new API call for smoothers, ast_smoother_reconfigure(), was required to implement these changes.
Review: http://reviewboard.digium.com/r/184/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@180372 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
value using <> can exist in the name portion.
(issue #AST-194)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@180194 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@180010 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
It had always been possible to explicitly specify a "blank"
value for a sound file in queues.conf and have no sound played
back. The problem with this is that it would result in some ugly
CLI warnings from file.c.
This commit introduces a check when playing a file in app_queue
to see if the name of the file is zero-length and return early if
that is the case. Also, the ability to specify the blank sound
files in queues.conf is now mentioned more clearly in queues.conf.sample
(closes issue #14227)
Reported by: caspy
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@180006 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
'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: http://svn.digium.com/svn/asterisk/branches/1.4@179840 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@179807 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@179741 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@179671 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@179608 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@179536 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This call to ast_waitfor() was being done way too soon in this section of code.
Specifically, there was code in between the call to waitfor and the code that
uses the result that puts the channel in autoservice. By putting the channel
in autoservice, the previous results of ast_waitfor() become meaningless,
as the autoservice thread will do it's own ast_waitfor() and ast_read()
on the channel.
So, when we came back out of autoservice and eventually hit the block of code
that calls ast_read() on the channel, there may not actually be any input on
the channel available. Even though the previous call to ast_waitfor() in
app_meetme said there was input, the autoservice thread has since serviced
the channel for some period of time.
This bug manifested itself while dvossel was doing some testing of MeetMe in
Asterisk trunk. He was using the timerfd timing module. When the code hit
ast_read() erroneously, it determined that it must have been called because of
input on the timer fd, as chan->fdno was set to AST_TIMING_FD, since that was
the cause of the last legitimate call to ast_read() done by autoservice.
In this test, an IAX2 channel was calling into the MeetMe conference. It was
_much_ more likely to be seen with an IAX2 channel because of the way audio
is handled. Every audio frame that comes in results in a call to
ast_queue_frame(), which then uses ast_timer_enable_continuous() to notify
the channel thread that a frame is waiting to be handled. So, the chances
of ast_waitfor() indicating that a channel needs servicing due to a timer
event on an IAX2 event is very high.
Finally, it is interesting to note that if a different timing interface was
being used, this bug would probably not be noticed. When ast_read() is called
and erroneously thinks that there is a timer event to handle, it calls the
ast_timer_ack() function. The pthread and dahdi timing modules handle the
ack() function being called when there is no event by simply ignoring it.
In the case of the timerfd module, it results in a read() on the timer fd
that will block forever, as there is no data to read. This caused Asterisk
to lock up very quickly.
Thanks to dvossel and mmichelson for the fun debugging session. :-)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@179532 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@179468 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@179461 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
directive, and another about strlcpy/strlcat.
(closes issue #14264)
Reported by: dimas
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@179395 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #14566)
Reported by: klaus3000
Patches:
ANSWEREDTIME-1.4-patch.txt uploaded by klaus3000 (license 65)
ANSWEREDTIME-trunk-patch.txt uploaded by klaus3000 (license 65)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@179056 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@178956 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Now prune_users() and prune_peers() are called instead of reload_config() to prune all users/peers that are realtime. These functions remove all users/peers with the rtfriend and delme flags set. iax2_prune_realtime() also lacked the code to properly delete a single friend. For example. if iax2 prune realtime <friend> was called, only the peer instance would be removed. The user would still remain.
(closes issue #14479)
Reported by: mousepad99
Review: http://reviewboard.digium.com/r/176/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@178838 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@178804 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
expressions ($[...]) 8-bit transparent
While I was updating ast_expr2.fl, I missed one rule that would allow 8-bit chars to be caught
in tokens; and in so doing, it absorbs the ${ sequence and messes up the
checking of raw exprs by AEL.
Trunk already has these changes.
(closes issue #14543)
Reported by: klaus3000
Patches:
patch.14543 uploaded by murf (license 17)
Tested by: murf
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@178640 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@178508 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #14540)
Reported by: jtodd
Patch by: jtodd, with additional notes by tilghman (license 14)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@178445 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(issue #14460)
Reported by: moliveras
Tested by: russell
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@178373 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
If BIT_TYPES_DEFINED gets defined before linux/types.h is included, the
__s32 type doesn't get defined
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@178266 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Since the remote side is not actually subscribing to a specific extension when
subscribing for MWI just skip the check to see if the extension exists. They can't use it
to specify the mailbox either since we require configuration of that in sip.conf
(closes issue #14531)
Reported by: festr
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@178205 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@178141 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@177786 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
OpenSolaris definitely needs it to be removed.
Fixed for snuff-home on -dev channel.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@177701 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
During iax2 call negotiation, supported codecs are passed in an Information Element containing a 2 byte field where each bit correlates to a specific codec. In 1.4 only audio codec bits 0-12 are defined, leaving bits 13-15 undefined. By default all bits are enabled unless specified otherwise. Since its a 2 byte field and 13-15 are not defined, these bits are never turned off. In trunk, bits 13-15 are defined, which means 1.4 is advertising support for codecs it does not have when talking to trunk. I fixed this by adding #define for undefined audio codec bits. These bits are then removed from iax2's full bandwidth capabilities.
(closes issue #14283)
Reported by: jcovert
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@177696 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@177540 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
non-interactive threads.
(closes issue #14253)
Reported by: Skavin
Patches:
20090219__bug14253.diff.txt uploaded by Corydon76 (license 14)
Tested by: Skavin
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@177536 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Resiprocate dev team. Thanks!
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@177450 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
it was previously set.
(issue #LUMENVOX-13)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@177383 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@177225 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Several changes in PTLib have occurred requiring build time detection. Changes
accounted for include the library name change, config option change, install
location change, and a boolean type change which is handled by ast_ptlib.h.
Also, the sed check has been modified to properly work with autoconf >= 2.62.
(closes issue #14224)
Reported by: bergolth
Patches:
asterisk-autoconf-sed.patch uploaded by bergolth (license 661)
asterisk-pwlib-v3.patch uploaded by bergolth (license 661)
Tested by: jpeeler
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@177160 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@177096 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r177035 | dbailey | 2009-02-18 11:24:07 -0600 (Wed, 18 Feb 2009) | 2 lines
Fixed error where a check for an zero length, terminated string was needed.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@177039 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
the amount available.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@176945 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This commit brings in the changes that were living out on the
svn/asterisk/team/sruffell/asterisk-1.4-transcoder branch. codec_dahdi.c now
always uses signed linear as the simple codec so that a soft g729 codec will
not end up being preferred to the hardware codec. There are also changes to
allow codec_dahdi.c to feed packets to the hardware in the native sample size of
the codec. This solves problems with choppy audio when using G723.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@176810 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@176701 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Prior to masquerade, move the group definitions to the channel performing the
masq, so that the group count lingers past the bridge.
(closes issue #14275)
Reported by: kowalma
Patches:
20090216__bug14275.diff.txt uploaded by Corydon76 (license 14)
Tested by: kowalma
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@176661 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
restarted, instead waiting until the next registration. We're now
caching the qualify across a reload/restart and starting the qualify
immediately upon loading the peer.
(closes issue #14196)
Reported by: pdf
Patches:
20090120__bug14196_1.4.diff.txt uploaded by pdf (license 663)
Tested by: pdf
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@176426 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
bridging
This should have been committed with rev176247, but I missed it. srcupdate frames no longer break out of the native bridge, but are not being sent to the other call leg either. This fixs that.
issue #13749
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@176354 f38db490-d61c-443f-a65b-d21fe96a405b
|
