https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r311297 | rmudgett | 2011-03-17 21:59:05 -0500 (Thu, 17 Mar 2011) | 12 lines
Race condition when ISDN CallRerouting/CallDeflection invoked.
The queued AST_CONTROL_BUSY could sometimes be processed before the
call_forward dial string is recognized.
* Moved setting the call_forwarding dial string after sending a response
to the initiator and just queue an empty frame to wake up the media thread
instead of an AST_CONTROL_BUSY.
* Added check for empty rerouting/deflection number and respond with an
error.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@311298 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r311295 | rmudgett | 2011-03-17 21:22:07 -0500 (Thu, 17 Mar 2011) | 35 lines
Merged revision 310986 from
https://origsvn.digium.com/svn/asterisk/be/branches/C.3-bier
..........
r310986 | rmudgett | 2011-03-16 13:56:28 -0500 (Wed, 16 Mar 2011) | 28 lines
Dial() o option broke when connected line feature added.
The patch restores the o option behavior and adds the ability to specify
the CallerID. The Dial o and f options are complementary to each other.
The o option stores the CallerID on the outgoing channel as the channel's
CallerID. The f option forces the CallerID sent by the outgoing channel.
o(x) - The argument 'x' is optional. If not present, then specify that
the CallerID that was present on the *calling* channel be stored as the
CallerID on the *called* channel. This was the behavior of Asterisk 1.0
and earlier. If present, then specify the CallerID stored on the *called*
channel. Note that o(${CALLERID(all)}) is similar to option o without
parameters.
f(x) - The argument 'x' is optional and its presence changes the behavior
of this option. If not present, then force the outgoing CallerID on a
call-forward or deflection to the dialplan extension for this Dial() using
a dialplan 'hint'. For example, some PSTNs do not allow CallerID to be
set to anything other than the numbers assigned to you. If present, then
force the outgoing CallerID to 'x'.
Patches:
jira_abe_2752_dial_fo_options.patch uploaded by rmudgett (license 664)
Tested by: rmudgett
JIRA ABE-2752
JIRA SWP-3096
..........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@311296 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r311197 | jrose | 2011-03-17 14:03:34 -0500 (Thu, 17 Mar 2011) | 11 lines
This fixes a nasty chanspy bug which was causing a channel leak every time a spied on channel made a call.
In addition to the above, it makes certain channel destruction occurs so that applications don't get stuck waiting for datastore destruction while monitored by chanspy.
(closes issue #18742)
Reported by: jkister
Tested by: jkister, jcovert, jrose
Review: http://reviewboard.digium.internal/r/106/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@311198 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r310902 | twilson | 2011-03-16 12:19:57 -0500 (Wed, 16 Mar 2011) | 43 lines
Merged revisions 310889 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r310889 | twilson | 2011-03-16 12:03:27 -0500 (Wed, 16 Mar 2011) | 36 lines
Merged revisions 310888 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r310888 | twilson | 2011-03-16 11:58:42 -0500 (Wed, 16 Mar 2011) | 29 lines
Don't delay DTMF in core bridge while listening for DTMF features
This patch is mostly the work of Olle Johansson. I did some cleanup and
added the silence generating code if transmit_silence is set.
When a channel listens for DTMF in the core bridge, the outbound DTMF is not
sent until we have received DTMF_END. For a long DTMF, this is a disaster. We
send 4 seconds of DTMF to Asterisk, which sends no audio for those 4 seconds.
Some products see this delay and the time skew on RTP packets that results and
start ignoring the audio that is sent afterward.
With this change, the DTMF_BEGIN frame is inspected and checked. If it matches
a feature code, we wait for DTMF_END and activate the feature as before. If
transmit_silence=yes in asterisk.conf, silence is sent if we paritally match a
multi-digit feature. If it doesn't match a feature, the frame is forwarded
along with the DTMF_END without delay. By doing it this way, DTMF is not delayed.
(closes issue #15642)
Reported by: jasonshugart
Patches:
issue_15652_dtmf_ast-1.4.patch.txt uploaded by twilson (license 396)
Tested by: globalnetinc, jde
(closes issue #16625)
Reported by: sharvanek
Review: https://reviewboard.asterisk.org/r/1092/
Review: https://reviewboard.asterisk.org/r/1125/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@310941 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
(closes issue #18693)
........
r310734 | may | 2011-03-15 00:45:53 +0300 (Tue, 15 Mar 2011) | 12 lines
Introduce t.38 parameters control functionality not full but enough for
Send/RcvFax support
Introduce t.38 controls between asterisk core and channel/proto layers.
Not all parameters are transferred from proto layers but *Fax apps
tested and work ok.
(issue #18693)
Reported by: benngard2
Patches:
issue-18693.patch uploaded by may213 (license 454)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@310735 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r310636 | rmudgett | 2011-03-14 11:50:59 -0500 (Mon, 14 Mar 2011) | 39 lines
Merged revisions 310635 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r310635 | rmudgett | 2011-03-14 11:47:54 -0500 (Mon, 14 Mar 2011) | 32 lines
Merged revisions 310633 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r310633 | rmudgett | 2011-03-14 11:38:24 -0500 (Mon, 14 Mar 2011) | 25 lines
"Caller*ID failed checksum" on Wildcard TDM2400P and TDM410
The last character in the caller id message is getting a framing error.
The checksum is the last character in the message. A framing error in the
checksum could be because:
1) The sender did not send a full stop bit.
2) The sender cut off the FSK carrier too soon.
3) The sender opted to send zero of the specified zero to 10 trailing mark
bits and round-off errors in the code resulted in the code not being where
it thought it was in the demodulated bit stream.
Bit 8 of 'b' is set when parity error.
Bit 9 of 'b' is set when framing error.
Made ignore the framing and parity error bits if the errored character is
the checksum. We can tolerate a framing/parity error there. The checksum
character validates the message.
(closes issue #18474)
Reported by: nivek
Patches:
callerid.c.1.patch uploaded by nivek (license 636) (with modifications)
Tested by: nivek
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@310637 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r310462 | tilghman | 2011-03-12 14:27:54 -0600 (Sat, 12 Mar 2011) | 45 lines
Merged revisions 310448 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r310448 | tilghman | 2011-03-12 14:24:54 -0600 (Sat, 12 Mar 2011) | 38 lines
Recorded merge of revisions 310435 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r310435 | tilghman | 2011-03-12 14:22:07 -0600 (Sat, 12 Mar 2011) | 31 lines
Add AELSub, which provides a stable entry point into AEL subroutines.
This commit needs some explanation, given that we're adding a new application
into an existing release branch. This is generally a violation of our release
policy, except in very limited circumstances, and I believe this is one of
those circumstances.
The problem that this solves is one of the sanity of using multiple dialplan
languages to define a dialplan. In the case of the reporter, he or she is
using AEL is define subroutines, while using Realtime extensions to invoke
those subroutines. While you can do this, it's based upon the reality of AEL
using actual dialplan extensions; however, there is no guarantee that the
details of _how_ AEL is compiled into extensions will remain stable. In fact,
at the time of this commit, it has already changed twice, once in a
fundamental way.
Now normally, a new application would only be added to trunk. However, this
application is explicitly to create a stable user-level API between versions,
and adding it to trunk only will not solve the user's problem of switching
between 1.6.2 and 1.8, nor will it help anybody switching from 1.8 to 1.10.
Therefore, it needs to go into existing release branches. For the sake of
consistency, and also because one of the changes was between 1.4 and 1.6.x,
I am also electing to commit this to 1.4.
(closes issue #18910)
Reported by: alexandrekeller
Patches:
20110304__issue18919__1.6.2.diff.txt uploaded by tilghman (license 14)
20110304__issue18919__1.4.diff.txt uploaded by tilghman (license 14)
Tested by: alexandrekeller
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@310500 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Recent versions of GCC have a tuning option value of 'native', which causes
the compiler to optimize the build for the CPU the compile is performed on.
Since most people are building Asterisk on the machine they plan to run it on,
the configure script and build system will now use this value unless a different
value is specified by the user in CFLAGS when the configure script is executed.
In addition, this value will be used for building the GSM and LPC10 codecs as
well, in preference to the logic that has been in their Makefiles forever to
optimize for certain types of CPUs.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@310332 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r310287 | alecdavis | 2011-03-11 19:47:44 +1300 (Fri, 11 Mar 2011) | 17 lines
remote_bridge_loop: prevent segfault when after transfer of IAX2 of DAHDI call
If the channel condition is one of the following after breaking out of the loop, don't try to update_peer
(where x = 0/1)
1). ZOMBIE
2). cx->tech_pvt != pvtx
3). gluex != ast_rtp_instance_get_glue(cx->tech->type))
(closes issue #18781)
Reported by: alecdavis
Patches:
bug18781.diff3.txt uploaded by alecdavis (license 585)
Tested by: alecdavis, ZX81
Review: https://reviewboard.asterisk.org/r/1128/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@310288 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r310240 | twilson | 2011-03-10 10:05:45 -0600 (Thu, 10 Mar 2011) | 13 lines
Add \r\n to remaining http headers passed to ast_http_send
r309204 changed the behavior of ast_http_send. It now requires headers
to be passed with trailing \r\n. This change updates the remaining
instances in the code that did not pass the \r\n.
(closes issue #18186)
Reported by: nivaldomjunior
Patches:
res_phoneprov.c.diff uploaded by lathama (license 1028)
manager.diff.txt uploaded by twilson (license 396)
Tested by: lathama
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@310241 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r309808 | tilghman | 2011-03-06 18:54:42 -0600 (Sun, 06 Mar 2011) | 14 lines
Merged revisions 309251 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r309251 | tilghman | 2011-03-01 19:06:02 -0600 (Tue, 01 Mar 2011) | 7 lines
Revert previous 2 commits, and instead conditionally redefine the same macro used in flex 2.5.35 that clashed with our workaround.
Not surprisingly, the workaround was exactly the same code as was provided by
the Flex maintainers, albeit in two different places, in different macros.
This should fix the FreeBSD builds, which have an older version of Flex.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@309809 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Adding the setvar option with variable substitution on the value allows things
like setting the outbound caller id name to the summary of a calendar event,
etc. Values could be chained together as they are appended in order to do some
scripting if necessary.
Review: https://reviewboard.asterisk.org/r/1134/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@309640 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r309542 | mnicholson | 2011-03-04 13:00:33 -0600 (Fri, 04 Mar 2011) | 11 lines
Merged revisions 309541 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r309541 | mnicholson | 2011-03-04 12:59:20 -0600 (Fri, 04 Mar 2011) | 4 lines
Check for errors from fseek() when loading config file, properly abort on errors from fread(), and supply a traceback for errors generated when loading the config file.
Also, prepend a newline to traceback output so that the main error message is on it's own line.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@309543 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r309445 | rmudgett | 2011-03-04 09:22:04 -0600 (Fri, 04 Mar 2011) | 46 lines
Get real channel of a DAHDI call.
Starting with Asterisk v1.8, the DAHDI channel name format was changed for
ISDN calls to: DAHDI/i<span>/<number>[:<subaddress>]-<sequence-number>
There were several reasons that the channel name had to change.
1) Call completion requires a device state for ISDN phones. The generic
device state uses the channel name.
2) Calls do not necessarily have B channels. Calls placed on hold by an
ISDN phone do not have B channels.
3) The B channel a call initially requests may not be the B channel the
call ultimately uses. Changes to the internal implementation of the
Asterisk master channel list caused deadlock problems for chan_dahdi if it
needed to change the channel name. Chan_dahdi no longer changes the
channel name.
4) DTMF attended transfers now work with ISDN phones because the channel
name is "dialable" like the chan_sip channel names.
For various reasons, some people need to know which B channel a DAHDI call
is using.
* Added CHANNEL(dahdi_span), CHANNEL(dahdi_channel), and
CHANNEL(dahdi_type) so the dialplan can determine the B channel currently
in use by the channel. Use CHANNEL(no_media_path) to determine if the
channel even has a B channel.
* Added AMI event DAHDIChannel to associate a DAHDI channel with an
Asterisk channel so AMI applications can passively determine the B channel
currently in use. Calls with "no-media" as the DAHDIChannel do not have
an associated B channel. No-media calls are either on hold or
call-waiting.
(closes issue #17683)
Reported by: mrwho
Tested by: rmudgett
(closes issue #18603)
Reported by: arjankroon
Patches:
issue17683_18603_v1.8_v2.patch uploaded by rmudgett (license 664)
Tested by: stever28, rmudgett
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@309446 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r309256 | qwell | 2011-03-02 13:54:20 -0600 (Wed, 02 Mar 2011) | 15 lines
Merged revisions 309255 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r309255 | qwell | 2011-03-02 13:53:47 -0600 (Wed, 02 Mar 2011) | 8 lines
Fix usage of "hasvoicemail=yes" and "mailbox=" in users.conf for SIP.
Since it's a duplicate, nothing is going to be done, so delme doesn't need to
be set at all. Strangely, when this was added, this was being set to 1 in 1.6,
and 0 in trunk.
(issue AST-439)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@309257 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r309035 | tilghman | 2011-02-28 05:10:28 -0600 (Mon, 28 Feb 2011) | 15 lines
Merged revisions 309033-309034 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r309033 | tilghman | 2011-02-28 04:43:12 -0600 (Mon, 28 Feb 2011) | 4 lines
A later version of flex already includes the fwrite workaround code, which if used twice causes a compilation error.
Detect whether Flex will compile without the workaround; if so, suppress our workaround code.
........
r309034 | tilghman | 2011-02-28 05:07:52 -0600 (Mon, 28 Feb 2011) | 2 lines
Clarify meaning, removing double negative (stupid!)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@309036 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r308945 | alecdavis | 2011-02-26 07:52:53 +1300 (Sat, 26 Feb 2011) | 21 lines
Fix Deadlock with attended transfer of SIP call
Call path
sip_set_rtp_peer (locks chan then pvt)
transmit_reinvite_with_sdp
try_suggested_sip_codec
pbx_builtin_getvar_helper (locks p->owner)
But by the time p->owner lock was attempted, seems as though chan and p->owner were different.
So in sip_set_rtp_peer, lock pvt first then lock p->owner using deadlocking methods.
(closes issue #18837)
Reported by: alecdavis
Patches:
bug18837-trunk.diff3.txt uploaded by alecdavis (license 585)
Tested by: alecdavis, Irontec, ZX81, cmaj
Review: [https://reviewboard.asterisk.org/r/1126/]
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@308946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r308903 | rmudgett | 2011-02-24 15:38:41 -0600 (Thu, 24 Feb 2011) | 9 lines
Invalid read in ast_channel_set_caller_event().
Valgrind reported that ast_channel_set_caller_event() was reading data
from a freed buffer when using the pre_set structure.
Rearange things to pre-calculate the name and number pointer before
updating the caller party structure to see if the name or number was
changed.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@308904 65c4cc65-6c06-0410-ace0-fbb531ad65f3