| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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
|
|
additional space as allocated if the string was built using already-allocated space
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@176254 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@176252 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@176249 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@176247 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@176216 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
during the lifetime of a dialog.
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: http://svn.digium.com/svn/asterisk/branches/1.4@176029 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Reported by De_Mon on #asterisk-dev.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@175921 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
made. My mistake. Ursäkta!
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@175825 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@175792 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@175777 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
confused, DAHDI is still DAHDI)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@175698 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@175590 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@175407 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@175311 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@175294 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@175187 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@175124 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@175029 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@174997 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@174986 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@174985 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
issue #13363 (related to issue #6176). When a hangup occurs during a Macro
execution in earlier 1.4, the h extension would execute within the Macro
context, whereas it was always supposed to execute only within the main context
(where Macro was called). So this fix checks for an "h" extension in the
deepest macro context where a hangup occurred; if it exists, that "h" extension
executes, otherwise the main context "h" is executed.
(closes issue #14122)
Reported by: wetwired
Patches:
20090210__bug14122.diff.txt uploaded by Corydon76 (license 14)
Tested by: andrew
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@174885 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #14448)
Reported by: frawd
Patches:
hold_invite_nosdp.patch uploaded by frawd (license 610)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@174644 f38db490-d61c-443f-a65b-d21fe96a405b
|
