situations.
This involves setting a proper cdr disposition coresponding to the given
failure condition and ensuring the proper information is stored in the cdr
record.
(closes issue #13691)
Reported by: dferrer
Tested by: mnicholson
(closes issue #13637)
Reported by: atis
Tested by: atis
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@194028 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The problem was that the hangup code was setting the invitestate too early. The result of
this was that we would always send a CANCEL request, even if it was not an appropriate
time to do so (e.g. we have not yet received a provisional response for our INVITE).
Note that this same fix had been applied to trunk and the 1.6.X branches starting with
revision 155467. This is why you will see this revision being blocked from those places.
AST-216
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@193880 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This allows more concurrent extensions to be copied for a single voicemail,
without creating a possibility of upsetting existing users, where a dialplan
could run out of stack space where it had run fine before. Alternatively,
we could have allocated off the heap, but that is a larger change and would
have increased the chance for instability introduced by this change.
This is really solved starting in 1.6.0.11, as the use of an ast_str buffer
allows an unlimited number of extensions (up to available memory). We
additionally create a new warning message when the buffer length is exceeded,
permitting administrators to see an issue after the fact, whereas previously
the list was silently truncated.
(closes issue #14739)
Reported by: p_lindheimer
Patches:
20090417__bug14739.diff.txt uploaded by tilghman (license 14)
Tested by: p_lindheimer
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@193755 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In the state MISDN_CALLING (i.e. SETUP was sent but no answer has arrived yet),
it is not allowed to clear the call with RELEASE_COMPLETE. It must be
cleared with DISCONNECT. A RELEASE_COMPLETE is only allowed as an answer
to a SETUP. (See Q.931 ch. 5.3.2, 5.3.2.a, 5.3.2.b)
Patches:
chan-misdn-ccstate7.patch uploaded by customer.
JIRA ABE-1862
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@193613 65c4cc65-6c06-0410-ace0-fbb531ad65f3
(Note: This is not a new feature, it was previously undocumented and broken.)
The Asterisk logger has a feature to support absolute pathnames for logger channels, but the code implementing the feature was broken. This has been fixed, and the absolute path feature is now documented in the sample logger.conf.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@193193 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If the single digit DTMF is an extension in the specified context, then
go there and signal no DTMF. Otherwise, we should exit with that DTMF.
If we're in Macro, we'll exit and seek that DTMF as the beginning of an
extension in the Macro's calling context. If we're not in Macro, then
we'll simply seek that extension in the calling context. Previously,
someone complained about the behavior as it related to the interior of a
Gosub routine, and the fix (#14011) inadvertently broke FreePBX
(#14940). This change should fix both of these situations, but with the
possible incompatibility that if a single digit extension does not exist
(but a longer extension COULD have matched), it would have previously
gone immediately to the "i" extension, but will now need to wait for a
timeout.
(closes issue #14940)
Reported by: p_lindheimer
Patches:
20090420__bug14940.diff.txt uploaded by tilghman (license 14)
Tested by: p_lindheimer
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@193119 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Added the dialed extension and context to the chan_misdn messages warning
that the dialed number cannot be matched in the dialplan.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@193050 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If the fullcontact field appears in both the sippeers and the
sipregs table, then during reconstruction of the field, it will
otherwise be doubled.
(closes issue #14754)
Reported by: Alexei Gradinari
Patches:
20090506__bug14754.diff.txt uploaded by tilghman (license 14)
Tested by: lmadsen
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@192932 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Just changed park_exec to always return non-zero. I really wasn't entirely sure
at first if this was a bug. Decided it was since it would be surprising when
not using ParkedCall in the dialplan to hang up and have dialplan execution
continue.
(closes issue #14555)
Reported by: francesco_r
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@192858 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Internet Explorer (tested with 7.0) does not like trailing commas on constructs
like object initializers, so get rid of them to avoid some errors.
(closes issue #15026)
Reported by: rajnishgiri
Patches:
bug15026.patch uploaded by seanbright (license 71)
Tested by: seanbright
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@192524 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The CDR code involved with bridges wrongly assumed that the currently executing application and data
values will always exist. It is possible for this to be false when call forwarding is involved.
(closes issue #14984)
Reported by: gincantalupo
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@192454 65c4cc65-6c06-0410-ace0-fbb531ad65f3
mohinterpret and mohsuggest global variables were not copied over during build_users and build_peers.
(closes issue #14728)
Reported by: dimas
Patches:
v1-14728.patch uploaded by dimas (license 88)
Tested by: dimas, dvossel
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@192213 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fixes a case where a certain message could get played twice.
(closes issue #13155)
Reported by: greenfieldtech
Patches:
app_voicemail.c.multi-lang-patch uploaded by greenfieldtech (license 369)
Tested by: greenfieldtech
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@191778 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
