Similar to seanbright's commit 191422, this moves some static buffers
to be defined outside of for loops since it is undefined if memory
will be re-used or if the stack will grow with each iteration of the
loop.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@191628 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fixes a regression from commit 176701. The issue was that
ast_generic_bridge never exited after the feature digit timeout had elapsed,
which prevented the queued DTMF from being sent to the other side.
This issue was reported to me directly.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@191488 65c4cc65-6c06-0410-ace0-fbb531ad65f3
According to Kevin, it is unspecified as to whether a variable defined inside
a block is allocated once by the compiler or for each pass through the block
(loops being the only interesting case), so just define these before we get
into our loop to be sure.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@191422 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch simply removes some old code back before Asterisk used editline.
This fixes the crash that occurred when tab-completing "remove extension".
(closes issue #14689)
Reported by: isaacgal
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@191096 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A user reported via #asterisk that with very long lists of members, a crash
occurs in ast_strdupa, so just use a single buffer and ast_copy_string instead
of stack allocating copys of each interface name.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@191041 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Attempt to make configure script regeneration 'safe' using autoconf 2.63, which embeds a bare CR into the script, thus making Subversion complain about inconsistent line endings
This commit changes the MIME type of the configure script to be 'binary' thus making Subversion no longer inspect line endings, and as a bonus 'svn diff' will no longer try to generate diff output for it, which is not generally useful anyway.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@190721 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When chan_dahdi goes to get an SMDI message, it provides no search criteria.
It just grabs the next message that arrives. This code was written with the
SMDI dialplan functions in mind, since that is now the preferred method of
using SMDI. However, this broke support of it being used from chan_dahdi.
(closes AST-212)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@190661 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If both sides of a Local channel were hung up at around the same time it was
possible for one thread to destroy the local private structure and have the other thread
immediately try to remove the already freed structure from the local channel list.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@190286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Previously, packetization settings were ignored and now they are not. A new
config option 'autoframing' has been added to mirror the way chan_sip handles
it. Turning on the autoframing option (available both as a global option or per
peer) overrides the local settings with the remote packetization settings.
Testing was performed with varying packetization levels with the following
codecs: ulaw, alaw, gsm, and g729.
(closes issue #12415)
Reported by: pj
Patches:
2009012200_h323packetization.diff.txt uploaded by mvanbaak (license 7),
modified by me
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@189991 65c4cc65-6c06-0410-ace0-fbb531ad65f3
On some systems, sed does not recognize \r in the pattern the way it
was used here.
Use tr instead because this works the same across systems.
(closes issue #14936)
Reported by: leobrown
Patches:
2009042201_14936.diff.txt uploaded by mvanbaak (license 7)
Tested by: leobrown, mvanbaak
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@189849 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In certain cases, due to the way Set() works in 1.4, values may not get set
properly. This is a workaround for 1.4 only that corrects for these issues,
without making func_odbc more difficult to use properly.
(closes issue #14614)
Reported by: wdoekes
Patches:
20090309__bug14614__2.diff.txt uploaded by tilghman (license 14)
double_set_unescape_workaround_for_func_odbc.osso-and-tilghman-1.diff uploaded by wdoekes (license 717)
Tested by: wdoekes, tilghman
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@189537 65c4cc65-6c06-0410-ace0-fbb531ad65f3
AEL was not handling the case of a device hint containing an @ symbol, which
caused parking hints (e.g. hint(park:exten@context)) to error out the parser.
This patch makes AEL treat the @ the same way it treats colon and ampersand
now, meaning the characters are included in verbatim.
(closes issue #14941)
Reported by: bpgoldsb
Patches:
bug14941.patch uploaded by seanbright (license 71)
Tested by: bpgoldsb
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@189462 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Many users were finding that their hung up channels were staying up and
causing 100% CPU usage.
(issue #14723)
Reported by: seadweller
Patches:
14723_1-4-tip.patch uploaded by mmichelson (license 60)
Tested by: falves11, bamby
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@189277 65c4cc65-6c06-0410-ace0-fbb531ad65f3
An agent logs in by calling an extension that calls the AgentLogin app. In agents.conf ackcall=always is set, so when they get a call they have the choice to either acknowledge it or ignore it. autologoff=10 is set as well, so if the agent ignores the call over 10sec one may assume that the agent should be logged out (and in this case hungup on as well), but this was not happening.
(closes issue #14091)
Reported by: evandro
Patches:
autologoff.diff uploaded by dvossel (license 671)
Review: http://reviewboard.digium.com/r/225/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@189203 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit fixes the scenario where an incoming call is authenticated
using a peer entry. Previously the channel name was created using either
the username setting from the sip.conf entry or the IP address that the
call came from. Now the channel name will be created using the peer name
itself. This commit will not change the way the channel name is generated
for users or friends.
(closes issue #14256)
Reported by: Nick_Lewis
Patches:
chan_sip.c-chname.patch uploaded by Nick (license 657)
Tested by: Nick_Lewis, file
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@188946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When the caller ID is restricted, the expected behavior is for the caller id to be blank. In chan_dahdi, the national prefix is placed onto the callers number even if its restricted (empty) causing the caller id to be the national prefix rather than blank.
(closes issue #13207)
Reported by: shawkris
Patches:
national_prefix.diff uploaded by dvossel (license 671)
Review: http://reviewboard.digium.com/r/220/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@188646 65c4cc65-6c06-0410-ace0-fbb531ad65f3
audio_audiohook_write_list() does not take into account that the sample size may change after translation depending on if the original frame is is 8khz or 16khz. While no 16kz codecs are supported in 1.4 at the moment, this will save headaches in the future if they ever are. the sample size is now updated after translating to reflect this possibility. Thanks to jcolp and mmichelson for helping me work this out.
(issue AST-197)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@188287 65c4cc65-6c06-0410-ace0-fbb531ad65f3
RFC 5047 explains the proper course of action to take if a
reINVITE is received before the ACK from a previous invite
transaction. What we are to do is to treat the reINVITE as
if it were both an ACK and a reINVITE and process it normally.
Later, when we receive the ACK we had been expecting, we will
ignore it since its CSeq is less than the current iseqno of
the sip_pvt representing this dialog.
(closes issue #13849)
Reported by: klaus3000
Patches:
13849_v2.patch uploaded by mmichelson (license 60)
Tested by: mmichelson, klaus3000
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@187484 65c4cc65-6c06-0410-ace0-fbb531ad65f3
We were unconditionally incrementing the number of mohclasses
registered. However, we should actually only increment if the
call to moh_register was successful.
While this probably has never caused problems, I noticed it
and decided to fix it anyway.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@187045 65c4cc65-6c06-0410-ace0-fbb531ad65f3
"ast_read() called with no recorded file descriptor" is a new message added
after a bug was discovered. Unfortunately, it seems there are a bunch of places
that potentially make such calls to ast_read() and trigger this error message
to be displayed. This commit does two things to help to make this message appear
less.
First, the message has been downgraded to a debug level message if dev mode is
not enabled. The message means a lot more to developers than it does to end users,
and so developers should take an effort to be sure to call ast_read only when
a channel is ready to be read from. However, since this doesn't actually cause an
error in operation and is not something a user can easily fix, we should not spam
their console with these messages.
Second, the message has been moved to after the check for any pending masquerades.
ast_read() being called with no recorded file descriptor should not interfere with
a masquerade taking place.
This could be seen as a simple way of resolving issue #14723. However, I still want
to try to clear out the existing ways of triggering this message, since I feel that
would be a better resolution for the issue.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@186984 65c4cc65-6c06-0410-ace0-fbb531ad65f3
