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/branches/1.4@179461 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.4@178956 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.4@178838 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.4@178804 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.4@178640 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.4@178205 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.4@178141 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.4@177786 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.4@177696 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.4@177540 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.4@177225 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.4@177160 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.4@176810 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.4@176701 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.4@176661 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.4@176426 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.4@176354 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Apparently on FreeBSD, attempting to set the O_NONBLOCKING flag separately
from opening the file was causing an "inappropriate ioctl for device" error.
While I cannot fathom why this would be happening, I certainly am not opposed
to making the code a bit more compact/efficient if it also fixes a bug.
(closes issue #14482)
Reported by: ys
Patches:
meetme.patch uploaded by ys (license 281)
Tested by: ys
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@176249 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In iax2, when a AST_CONTROL_SRCUPDATE is received it breaks from the native bridge, but since there is no code path to handle srcupdate it just goes to be beginning of the loop. This was causing packet storms of srcupdate frames between servers. Now srcupdate frames do not break the native bridge for processing.
(closes issue #13749)
Reported by: adiemus
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@176247 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This issue crept up with subscriptions on the AA50. When an outgoing NOTIFY is sent a new branch value
is created and the Via header is changed to reflect it. Since this was a stringfield a new spot in the
pool was used for the value while the old was left untouched/unused. If the current pool was full a new
pool was created. This would cause memory usage to increase steadily.
(issue #AA50-2332)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@176029 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If calling into VoiceMailMain when using IMAP storage, it was
possible to crash Asterisk by hanging up the phone when prompted
for a voicemail mailbox. This patch fixes the issue.
While it may appear that this patch is superficial, it allows code
execution to continue to the failure case just below the IMAP_STORAGE
code block where this patch has been applied
(closes issue #14473)
Reported by: dwpaul
Patches:
voicemail_imap_crash_no_mailbox.patch uploaded by dwpaul (license 689)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@175590 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This section was already present in trunk and other branches,
but did not exist in 1.4.
(closes issue #14395)
Reported by: ZX81
Patches:
14395.patch uploaded by putnopvut (license 60)
Tested by: ZX81
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@175407 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.4@175311 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.4@175294 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.4@175187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.4@175124 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This attribute contains a JID that identifies the initiator of the GoogleTalk
voice session. The GoogleTalk client discards Asterisk's replies if the
initiator attribute contains uppercase characters.
(closes issue #13984)
Reported by: jcovert
Patches:
chan_gtalk.2.patch uploaded by jcovert (license 551)
Tested by: jcovert
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@175029 65c4cc65-6c06-0410-ace0-fbb531ad65f3
