This patch adds pass-through support for CELT. CELT
formats are defined in codecs.conf and can be configured
to any sample rate a CELT endpoint supports. This patch also
addresses a crash in channel.c resulting from a frame list being
freed incorrectly. This crash was discovered while testing a CELT
translator which had to split encoded audio into multiple frames.
The codec translator is not a part of this patch, but may be
contributed in the future.
Review: https://reviewboard.asterisk.org/r/1294/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@326855 f38db490-d61c-443f-a65b-d21fe96a405b
Asterisk now has protocol independent support for processing text messages
outside of a call. Messages are routed through the Asterisk dialplan.
SIP MESSAGE and XMPP are currently supported. There are options in sip.conf
and jabber.conf that enable these features.
There is a new application, MessageSend(). There are two new functions,
MESSAGE() and MESSAGE_DATA(). Documentation will be available on
the project wiki, wiki.asterisk.org.
Thanks to Terry Wilson for the assistance with development and to David Vossel
for helping with some additional testing.
Review: https://reviewboard.asterisk.org/r/1042/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@321546 f38db490-d61c-443f-a65b-d21fe96a405b
The ast_string_field_build_va functions were written to take to separate
va_lists to work around FreeBSD 4 not having va_copy defined.
In the end, we don't support anything using gcc < 3 anyway because we use
va_copy all over the place anyway. This patch just simplifies things by
removing the second va_list function arguments in favor of va_copy.
Review: https://reviewboard.asterisk.org/r/1233/
--This line, and those below, will be ignored--
M include/asterisk/stringfields.h
M main/utils.c
M main/channel.c
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@320946 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r320823 | rmudgett | 2011-05-25 12:06:38 -0500 (Wed, 25 May 2011) | 18 lines
The AMI Newstate event contains different information between v1.4 and v1.8.
The addition of connected line support in v1.8 changes the behavior of the
channel caller ID somewhat. The channel caller ID value no longer time
shares with the connected line ID on outgoing call legs. The timing of
some AMI events/responses output the connected line ID as caller ID.
These party ID's are now separate.
* The ConnectedLineNum and ConnectedLineName headers were added to many
AMI events/responses if the CallerIDNum/CallerIDName headers were also
present.
(closes issue #18252)
Reported by: gje
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1227/
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@320825 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r320796 | rmudgett | 2011-05-25 11:23:11 -0500 (Wed, 25 May 2011) | 17 lines
Give zombies a safe channel driver to use.
Recent crashes from zombie channels suggests that they need a safe home to
goto. When a masquerade happens, the physical part of the zombie channel
is hungup. The hangup normally sets the channel private pointer to NULL.
If someone then blindly does a callback to the channel driver, a crash is
likely because the private pointer is NULL.
The masquerade now sets the channel technology of zombie channels to the
kill channel driver.
Related to the following issues:
(issue #19116)
(issue #19310)
Review: https://reviewboard.asterisk.org/r/1224/
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@320820 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r320057 | rmudgett | 2011-05-20 11:43:02 -0500 (Fri, 20 May 2011) | 19 lines
Crash while transferring a call during DTMF feature timeout.
When a call is being attended transferred during the time between
AST_FRAME_DTMF_BEGIN and AST_FRAME_DTMF_END, the transferred channel
becomes a zombie (so tech data is not available), making ast_dtmf_stream()
segfault when it tries to send the DTMF digit (at least with SIP
channels).
Patch based on feature-end-zombie.patch uploaded by Irontec (license 1256)
* Check for zombies when ast_channel_bridge() returns.
* Guarantee that the fo parameter value is initialized in
ast_channel_bridge() before any returns.
(closes issue #19116)
Reported by: Irontec
Tested by: rmudgett
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@320058 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r316265 | russell | 2011-05-03 14:55:49 -0500 (Tue, 03 May 2011) | 5 lines
Fix a bunch of compiler warnings generated by gcc 4.6.0.
Most of these are -Wunused-but-set-variable, but there were a few others
mixed in here, as well.
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@316293 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r313588 | rmudgett | 2011-04-13 11:31:50 -0500 (Wed, 13 Apr 2011) | 55 lines
Merged revisions 313579 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r313579 | rmudgett | 2011-04-13 11:29:49 -0500 (Wed, 13 Apr 2011) | 48 lines
Merged revisions 313545 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r313545 | rmudgett | 2011-04-13 11:21:24 -0500 (Wed, 13 Apr 2011) | 41 lines
Asterisk does not hangup a channel after endpoint hangs up.
If the call that the dialplan started an AGI script for is hungup while
the AGI script is in the middle of a command then the AGI script is not
notified of the hangup. There are many AGI Exec commands that this can
happen with. The reported applications have been: Background, Wait, Read,
and Dial. Also the AGI Get Data command.
* Don't wait on the Asterisk channel after it has hung up. The channel is
likely to never need servicing again.
* Restored the AGI script's ability to return the AGI_RESULT_HANGUP value
in run_agi(). It previously only could return AGI_RESULT_SUCCESS or
AGI_RESULT_FAILURE after the DeadAGI and AGI applications were merged.
(closes issue #17954)
Reported by: mn3250
Patches:
issue17954_v1.8.patch uploaded by rmudgett (license 664)
issue17954_v1.6.2.patch uploaded by rmudgett (license 664)
issue17954_v1.4.patch uploaded by rmudgett (license 664)
Tested by: rmudgett
JIRA SWP-2171
(closes issue #18492)
Reported by: devmod
Tested by: rmudgett
JIRA SWP-2761
(closes issue #18935)
Reported by: nvitaly
Tested by: astmiv, rmudgett
JIRA SWP-3216
(closes issue #17393)
Reported by: siby
Tested by: rmudgett
JIRA SWP-2727
Review: https://reviewboard.asterisk.org/r/1165/
........
................
................
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@313606 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@308904 f38db490-d61c-443f-a65b-d21fe96a405b
-Functional changes
1. Dynamic global format list build by codecs defined in codecs.conf
2. SILK 8khz, 12khz, 16khz, and 24khz with custom attributes defined in codecs.conf
3. Negotiation of SILK attributes in chan_sip.
4. SPEEX 32khz with translation
5. SLINEAR 8khz, 12khz, 24khz, 32khz, 44.1khz, 48khz, 96khz, 192khz with translation
using codec_resample.c
6. Various changes to RTP code required to properly handle the dynamic format list
and formats with attributes.
7. ConfBridge now dynamically jumps to the best possible sample rate. This allows
for conferences to take advantage of HD audio (Which sounds awesome)
8. Audiohooks are no longer limited to 8khz audio, and most effects have been
updated to take advantage of this such as Volume, DENOISE, PITCH_SHIFT.
9. codec_resample now uses its own code rather than depending on libresample.
-Organizational changes
Global format list is moved from frame.c to format.c
Various format specific functions moved from frame.c to format.c
Review: https://reviewboard.asterisk.org/r/1104/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@308582 f38db490-d61c-443f-a65b-d21fe96a405b
Pass a MCID request to the bridged channel so the bridged channel can send
it to the network.
The ability to send the MCID request on an ISDN span is enabled with the
new chan_dahdi.conf mcid_send option.
JIRA SWP-2845
JIRA ABE-2736
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@306755 f38db490-d61c-443f-a65b-d21fe96a405b
This patch is the foundation of an entire new way of looking at media in Asterisk.
The code present in this patch is everything required to complete phase1 of my
Media Architecture proposal. For more information about this project visit the link below.
https://wiki.asterisk.org/wiki/display/AST/Media+Architecture+Proposal
The primary function of this patch is to convert all the usages of format
bitfields in Asterisk to use the new format and format_cap APIs. Functionally
no change in behavior should be present in this patch. Thanks to twilson
and russell for all the time they spent reviewing these changes.
Review: https://reviewboard.asterisk.org/r/1083/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@306010 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r305923 | rmudgett | 2011-02-02 18:24:40 -0600 (Wed, 02 Feb 2011) | 24 lines
Merged revisions 305889 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r305889 | rmudgett | 2011-02-02 18:15:07 -0600 (Wed, 02 Feb 2011) | 17 lines
Merged revisions 305888 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r305888 | rmudgett | 2011-02-02 18:02:43 -0600 (Wed, 02 Feb 2011) | 8 lines
Minor AST_FRAME_TEXT related issues.
* Include the null terminator in the buffer length. When the frame is
queued it is copied. If the null terminator is not part of the frame
buffer length, the receiver could see garbage appended onto it.
* Add channel lock protection with ast_sendtext().
* Fixed AMI SendText action ast_sendtext() return value check.
........
................
................
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@305939 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r303549 | russell | 2011-01-24 14:51:37 -0600 (Mon, 24 Jan 2011) | 45 lines
Merged revisions 303548 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r303548 | russell | 2011-01-24 14:49:53 -0600 (Mon, 24 Jan 2011) | 38 lines
Merged revisions 303546 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r303546 | russell | 2011-01-24 14:32:21 -0600 (Mon, 24 Jan 2011) | 31 lines
Fix channel redirect out of MeetMe() and other issues with channel softhangup.
Mantis issue #18585 reports that a channel redirect out of MeetMe() stopped
working properly. This issue includes a patch that resolves the issue by
removing a call to ast_check_hangup() from app_meetme.c. I left that in my
patch, as it doesn't need to be there. However, the rest of the patch fixes
this problem with or without the change to app_meetme.
The key difference between what happens before and after this patch is the
effect of the END_OF_Q control frame. After END_OF_Q is hit in ast_read(),
ast_read() will return NULL. With the ast_check_hangup() removed, app_meetme
sees this which causes it to exit as intended. Checking ast_check_hangup()
caused app_meetme to exit earlier in the process, and the target of the
redirect saw the condition where ast_read() returned NULL.
Removing ast_check_hangup() works around the issue in app_meetme, but doesn't
solve the issue if another application did the same thing. There are also
other edge cases where if an application finishes at the same time that a
redirect happens, the target of the redirect will think that the channel hung
up. So, I made some changes in pbx.c to resolve it at a deeper level. There
are already places that unset the SOFTHANGUP_ASYNCGOTO flag in an attempt to
abort the hangup process. My patch extends this to remove the END_OF_Q frame
from the channel's read queue, making the "abort hangup" more complete. This
same technique was used in every place where a softhangup flag was cleared.
(closes issue #18585)
Reported by: oej
Tested by: oej, wedhorn, russell
Review: https://reviewboard.asterisk.org/r/1082/
........
................
................
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@303551 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r301504 | jpeeler | 2011-01-12 12:12:08 -0600 (Wed, 12 Jan 2011) | 26 lines
Merged revisions 301503 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r301503 | jpeeler | 2011-01-12 12:11:49 -0600 (Wed, 12 Jan 2011) | 19 lines
Merged revisions 301502 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r301502 | jpeeler | 2011-01-12 12:10:42 -0600 (Wed, 12 Jan 2011) | 12 lines
Fix CPU spike when pressing DTMF after agent login.
The problem here is that DTMF was being continuously deferred and requeued
since ast_safe_sleep is called in a loop. There are serveral other places in the
code that sleeps and then loops in a similar fashion. Because of this fact I
opted to not defer DTMF any more, which will not affect the original fix:
https://reviewboard.asterisk.org/r/674
(closes issue #18130)
Reported by: rgj
........
................
................
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@301505 f38db490-d61c-443f-a65b-d21fe96a405b
Previously, I had added the ast_sched_thread stuff that was a generic scheduler
thread implementation. However, if you used it, it required using different
functions for modifying scheduler contents. This patch reworks how this is
done and just allows you to optionally start a thread on the original scheduler
context structure that has always been there. This makes it trivial to switch
to the generic scheduler thread implementation without having to touch any of
the other code that adds or removes scheduler entries.
In passing, I made some naming tweaks to add ast_ prefixes where they were not
there before.
Review: https://reviewboard.asterisk.org/r/1007/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@299091 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r297825 | jpeeler | 2010-12-07 16:59:30 -0600 (Tue, 07 Dec 2010) | 26 lines
Merged revisions 297824 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r297824 | jpeeler | 2010-12-07 16:58:54 -0600 (Tue, 07 Dec 2010) | 19 lines
Merged revisions 297823 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r297823 | jpeeler | 2010-12-07 16:57:48 -0600 (Tue, 07 Dec 2010) | 12 lines
Revert code that changed SSRC for DTMF.
Some previous behavior was attempted to be restored, but mistakingly I did
not realize that the previous behavior was incorrect. This fixes DTMF not
being detected since DTMF shouldn't cause the SSRC to change.
(related to issue #17404)
(closes issue #18189)
(closes issue #18352)
Reported by: marcbou
Tested by: cmbaker82
........
................
................
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@297826 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r296230 | russell | 2010-11-24 17:29:44 -0600 (Wed, 24 Nov 2010) | 20 lines
Merged revisions 296221 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r296221 | russell | 2010-11-24 17:28:19 -0600 (Wed, 24 Nov 2010) | 13 lines
Merged revisions 296213 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r296213 | russell | 2010-11-24 17:26:43 -0600 (Wed, 24 Nov 2010) | 6 lines
Make Asterisk less crashy.
Since we might not put a new translation path on the channel, go ahead and
set it to NULL right after destroying the old one to ensure we don't try
to free an invalid translation path later on.
........
................
................
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@296235 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r296084 | russell | 2010-11-24 14:23:46 -0600 (Wed, 24 Nov 2010) | 26 lines
Merged revisions 296083 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r296083 | russell | 2010-11-24 14:23:11 -0600 (Wed, 24 Nov 2010) | 19 lines
Merged revisions 296082 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r296082 | russell | 2010-11-24 14:22:32 -0600 (Wed, 24 Nov 2010) | 12 lines
Fix false reporting of an error by set_format().
In the case that the native format was able to be changed to match the
new requested format, the code proceeded to attempt to build a translation
path, anyway. The result would be NULL, since no translation path is
necessary and resulted in this function thinking an error has occurred.
This case is now specifically caught and no attempt to build a translation
path is attempted.
Thanks to our automated tests and bamboo.asterisk.org for catching this problem
and making a whole lot of noise when things started failing. :-)
........
................
................
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@296085 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r296002 | russell | 2010-11-24 11:13:08 -0600 (Wed, 24 Nov 2010) | 52 lines
Merged revisions 296001 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r296001 | russell | 2010-11-24 11:03:16 -0600 (Wed, 24 Nov 2010) | 45 lines
Merged revisions 296000 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r296000 | russell | 2010-11-24 10:48:39 -0600 (Wed, 24 Nov 2010) | 38 lines
Handle failures building translation paths more effectively.
The problem scenario occurred on a heavily loaded system that was using the
codec_dahdi module and exceeded the hardware transcoding capacity. The failure
mode at that point was not good. The report came in to us as an Asterisk
lock-up. The "core show locks" shows a ton of threads locked up (but no
obvious deadlock). Upon deeper investigation, when the system is in this
state, the CPU was maxed out. The CPU was being consumed by the Asterisk
logger spewing messages on every audio frame for calls set up after transcoder
capacity was reached.
The purpose of this patch is to make Asterisk handle failures to create a
translation path in a more graceful manner. If we can't translate, then the
call just needs to be dropped, as it's not going to work. These are the
changes:
1) In set_format() of channel.c (which is called by set_read_format() and
set_write_format()), it was ignoring if ast_translator_build_path() failed and
returned NULL. It now pays attention to that case and returns a result
reflecting failure. With this change in place, the bridging code will
immediately detect a failure and end the bridge instead of proceeding to try to
bridge frames that can't be translated and making channel drivers freak out by
sending them frames in a format they weren't expecting.
2) In ast_indicate_data() of channel.c, failure of ast_playtones_start() was
ignored. It is now reflected in the return value of the function. This didn't
turn out to have any affect on the bug, but seemed like a good change to leave
in.
3) In app_dial(), when only sending a call to a single endpoint, it will
attempt to do some bridging of its own of early audio. It uses
make_compatible() when it's going to do this. However, it ignored failure from
make compatible. So, even with the fix from #1, if there was early audio going
through app_dial, there would still be a period of invalid frames passing
through. After detecting failure here, Dial() exits.
ABE-2658
........
................
................
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@296034 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r295866 | rmudgett | 2010-11-22 13:36:10 -0600 (Mon, 22 Nov 2010) | 60 lines
Merged revisions 295843 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r295843 | rmudgett | 2010-11-22 13:28:23 -0600 (Mon, 22 Nov 2010) | 53 lines
Merged revisions 295790 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r295790 | rmudgett | 2010-11-22 12:46:26 -0600 (Mon, 22 Nov 2010) | 46 lines
The channel redirect function (CLI or AMI) hangs up the call instead of redirecting the call.
To recreate the problem:
1) Party A calls Party B
2) Invoke CLI "channel redirect" command to redirect channel call leg
associated with A.
3) All associated channels are hung up.
Note that if the CLI command were done on the channel call leg associated
with B it works.
This regression was a result of the fix for issue #16946
(https://reviewboard.asterisk.org/r/740/).
The regression affects all features that use an async goto to execute the
dialplan because of an external event: Channel redirect, AMI redirect, SIP
REFER, and FAX detection.
The struct ast_channel._softhangup code is a mess. The variable is used
for several purposes that do not necessarily result in the call being hung
up. I have added doxygen comments to describe how the various _softhangup
bits are used. I have corrected all the places where the variable was
tested in a non-bit oriented manner.
The primary fix is the new AST_CONTROL_END_OF_Q frame. It acts as a weak
hangup request so the soft hangup requests that do not normally result in
a hangup do not hangup.
JIRA SWP-2470
JIRA SWP-2489
(closes issue #18171)
Reported by: SantaFox
(closes issue #18185)
Reported by: kwemheuer
(closes issue #18211)
Reported by: zahir_koradia
(closes issue #18230)
Reported by: vmarrone
(closes issue #18299)
Reported by: mbrevda
(closes issue #18322)
Reported by: nerbos
Review: https://reviewboard.asterisk.org/r/1013/
........
................
................
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@295867 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r294349 | rmudgett | 2010-11-09 10:55:32 -0600 (Tue, 09 Nov 2010) | 17 lines
Analog lines do not transfer CONNECTED LINE or execute the interception macros.
Add connected line update for sig_analog transfers and simplify the
corresponding sig_pri and chan_misdn transfer code.
Note that if you create a three-way call in sig_analog before transferring
the call, the distinction of the caller/callee interception macros make
little sense. The interception macro writer needs to be prepared for
either caller/callee macro to be executed. The current implementation
swaps which caller/callee interception macro is executed after a three-way
call is created.
Review: https://reviewboard.asterisk.org/r/996/
JIRA ABE-2589
JIRA SWP-2372
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@294351 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r294278 | jpeeler | 2010-11-08 15:59:45 -0600 (Mon, 08 Nov 2010) | 23 lines
Merged revisions 294277 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r294277 | jpeeler | 2010-11-08 15:58:13 -0600 (Mon, 08 Nov 2010) | 16 lines
Fix playback failure when using IAX with the timerfd module.
To fix this issue the alert pipe will now be used when the timerfd module is
in use. There appeared to be a race that was not solved by adding locking in the
timerfd module, but needed to be there anyway. The race was between the timer
being put in non-continuous mode in ast_read on the channel thread and the IAX
frame scheduler queuing a frame which would enable continuous mode before the
non-continuous mode event was read. This race for now is simply avoided.
(closes issue #18110)
Reported by: tpanton
Tested by: tpanton
I put tested by tpanton because it was tested on his hardware. Thanks for the
remote access to debug this issue!
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@294279 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r292704 | rmudgett | 2010-10-22 10:47:08 -0500 (Fri, 22 Oct 2010) | 19 lines
Connected line is not updated when chan_dahdi/sig_pri or chan_misdn transfers a call.
When a call is transfered by ECT or implicitly by disconnect in sig_pri or
implicitly by disconnect in chan_misdn, the connected line information is
not exchanged. The connected line interception macros also need to be
executed if defined.
The CALLER interception macro is executed for the held call.
The CALLEE interception macro is executed for the active/ringing call.
JIRA ABE-2589
JIRA SWP-2296
Patches:
abe_2589_c3bier.patch uploaded by rmudgett (license 664)
abe_2589_v1.8_v2.patch uploaded by rmudgett (license 664)
Review: https://reviewboard.asterisk.org/r/958/
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@292705 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r291581 | twilson | 2010-10-13 16:01:56 -0700 (Wed, 13 Oct 2010) | 35 lines
Merged revisions 291580 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r291580 | twilson | 2010-10-13 15:58:43 -0700 (Wed, 13 Oct 2010) | 28 lines
Merged revisions 291577 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r291577 | twilson | 2010-10-13 15:45:15 -0700 (Wed, 13 Oct 2010) | 21 lines
Don't ignore frames that have been queued when softhangup'd
When an outgoing call is answered and hung up by the far end *very* quickly, we
may not read any frames and therefor end up with a call that displays the wrong
disposition/DIALSTATUS. The reason is because ast_queue_hangup() immediately
sets the _softhangup flag on the channel and then queues the HANGUP control
frame, but __ast_read refuses to read any frames if ast_check_hangup() indicates
that a hangup request has been made (which it will if _softhangup is set). So,
we end up losing control frames.
This change makes __ast_read continue to read frames even if a soft hangup has
been requested. It queues a hangup frame to make sure that __ast_read() will
still eventually return NULL.
Much thanks to David Vossel for all of the reviews, discussion, and help!
(closes issue #16946)
Reported by: davidw
Review: https://reviewboard.asterisk.org/r/740/
........
................
................
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@291657 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r289340 | qwell | 2010-09-29 16:12:43 -0500 (Wed, 29 Sep 2010) | 22 lines
Merged revisions 289339 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r289339 | qwell | 2010-09-29 16:03:47 -0500 (Wed, 29 Sep 2010) | 15 lines
Merged revisions 289338 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r289338 | qwell | 2010-09-29 15:56:26 -0500 (Wed, 29 Sep 2010) | 8 lines
Allow a manager originate to succeed on forwarded devices.
The timeout to wait for an answer was being set to 0 when a device forwarded to another
extension. We don't always need the timeout set like this, so make it an optional
parameter, and don't use it in this case.
ABE-2544
........
................
................
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@289354 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r289099 | bbryant | 2010-09-28 14:18:02 -0400 (Tue, 28 Sep 2010) | 28 lines
Merged revisions 289095 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r289095 | bbryant | 2010-09-28 14:14:19 -0400 (Tue, 28 Sep 2010) | 21 lines
Merged revisions 289094 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r289094 | bbryant | 2010-09-28 14:10:19 -0400 (Tue, 28 Sep 2010) | 14 lines
Fixes an issue with the Newchannel AMI event during the Masquerading process.
Fixes an issue with the Newchannel AMI event during the Masquerading process,
where no Newchannel AMI event was generated for the psuedo channel used during
the masquerading process.
(closes issue #17987)
Reported by: RadicAlish
Patches:
newchannel.patch.txt uploaded by RadicAlish (license 1122)
Tested by: RadicAlish
Review: https://reviewboard.asterisk.org/r/937/
........
................
................
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@289131 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r288079 | rmudgett | 2010-09-21 15:29:51 -0500 (Tue, 21 Sep 2010) | 2 lines
Protect channel access in CONNECTED_LINE and REDIRECTING interception macro launch code.
........
r288080 | rmudgett | 2010-09-21 15:29:59 -0500 (Tue, 21 Sep 2010) | 8 lines
Simplify locking code for REDIRECTING interception macro when forwarding a call.
Simplified the locking code by using a local copy of the redirecting party
information in app_dial.c:do_forward() and app_queue.c:wait_for_answer()
for launching the REDIRECTING interception macro when a call is forwarded.
Reduced the lock time of the 'o->chan' and 'in' channels.
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@288081 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r287685 | alecdavis | 2010-09-21 11:16:45 +1200 (Tue, 21 Sep 2010) | 18 lines
ast_channel_masquerade: Avoid recursive masquerades.
Check all 4 combinations of (original/clonechan) * (masq/masqr).
Initially original->masq and clonechan->masqr were only checked.
It's possible with multiple masq's planned - and not yet executed, that
the 'original' chan could already have another masq'd into it - thus original->masqr
would be set, that masqr would lost.
Likewise for the clonechan->masq.
(closes issue #16057;#17363)
Reported by: amorsen;davidw,alecdavis
Patches:
based on bug16057.diff4.txt uploaded by alecdavis (license 585)
Tested by: ramonpeek, davidw, alecdavis
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@287756 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r287661 | alecdavis | 2010-09-21 10:21:50 +1200 (Tue, 21 Sep 2010) | 14 lines
ast_do_masquerade. Keep channels ao2_container locked while unlink and linking channels.
Previously, Masquerade would unlock 'original' and 'clonechan' and allow another masq thread to run.
End result would be corrupted memory, and the frequent report 'Bad Magic Number'.
(closes issue #17801,#17710)
Reported by: notthematrix
Patches:
Based on bug17801.diff1.txt uploaded by alecdavis (license 585)
Tested by: alecdavis
Review: https://reviewboard.asterisk.org/r/928
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@287671 f38db490-d61c-443f-a65b-d21fe96a405b
dvossel