he doesn't cause a queue's announce file to be interrupted. Also went ahead and did the
same for the '*' key and for ending a call.
(closes issue #10528, reported by deskhack, patched by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@81120 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ringinuse=no for the queue.
(closes issue #10215, reported by Doug, repaired by me)
Special thanks to fkasumovic for pointing out the source of the problem and to bweschke for helping to come up with a solution!
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@79748 65c4cc65-6c06-0410-ace0-fbb531ad65f3
since loginstart is used after logoff. Thanks to makoto for pointing this out and suggesting the fix.
(closes issue #10178, reported and patched by makoto, with modification by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@74998 65c4cc65-6c06-0410-ace0-fbb531ad65f3
agent channel sent a digit, the digit would be played to the agent for forever.
This is because chan_agent always returned -1 from its send_digit_begin and _end
callbacks. This non-zero return value indicates to the Asterisk core that it
would like an inband DTMF generator put on the channel. However, this is the
wrong thing to do. It should *always* return 0, instead. When the digit begin
and end functions are called on the proxied channel, the underlying channel
will indicate whether inband DTMF is needed or not, and the generator will be
put on that one, and not the Agent channel.
(issue #9615, #9616, reported by jiddings and BigJimmy, and fixed by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@62218 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r54999 | file | 2007-02-16 17:13:45 -0500 (Fri, 16 Feb 2007) | 2 lines
Do not send indications through ast_indicate in chan_agent but instead go directly to the technology. This way when indications are emulated they happen on the Agent channel and do not screw up formats on the channels. (issue #8439 reported by punkgode)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@55002 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The main bug being addressed here is a problem introduced when two SIP
channels using SIP INFO dtmf have their media directly bridged. So, when a
DTMF END frame comes into Asterisk from an incoming INFO message, Asterisk
would try to emulate a digit of some length by first sending a DTMF BEGIN
frame and sending a DTMF END later timed off of incoming audio. However,
since there was no audio coming in, the DTMF_END was never generated. This
caused DTMF based features to no longer work.
To fix this, the core now knows when a channel doesn't care about DTMF BEGIN
frames (such as a SIP channel sending INFO dtmf). If this is the case, then
Asterisk will not emulate a digit of some length, and will instead just pass
through the single DTMF END event.
Channel drivers also now get passed the length of the digit to their digit_end
callback. This improves SIP INFO support even further by enabling us to put
the real digit duration in the INFO message instead of a hard coded 250ms.
Also, for an incoming INFO message, the duration is read from the frame and
passed into the core instead of just getting ignored.
(issue #8597, maybe others...)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@51311 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r42133 | bweschke | 2006-09-06 14:16:41 -0400 (Wed, 06 Sep 2006) | 6 lines
Look ma! No more deadlocks! <sic>
As posted from #7458 and others similar to it in Mantis:
p->app_lock was a mutex really designed for use with agents not in callback mode. That being the case, I've tried to code it so that when callback mode is used, the app_lock mutex will not be locked/unlocked at all. Please let me know how you make out - and if you continue to deadlock now, please reproduce the deadlock logging information and post to Mantis.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@43307 65c4cc65-6c06-0410-ace0-fbb531ad65f3
now reports AST_MODULE_LOAD_DECLINE when loading if config file
is not there, also fixed an error in res_config_pgsql where it
had a non static function when it should.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@41633 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- restructured build tree and makefiles to eliminate recursion problems
- support for embedded modules
- support for static builds
- simpler cross-compilation support
- simpler module/loader interface (no exported symbols)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@40722 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r36725 | russell | 2006-07-03 00:19:09 -0400 (Mon, 03 Jul 2006) | 4 lines
use ast_set_callerid to be more consistent and to make sure that the
"callerid" option in the conf files is always handled the same way and sets ANI
(issue #7285, gkloepfer)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@36726 65c4cc65-6c06-0410-ace0-fbb531ad65f3
More ideas for developing better video support in Asterisk?
Join the asterisk-video mailing list to help out in the
Asterisk Video Task Force!
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@35365 65c4cc65-6c06-0410-ace0-fbb531ad65f3
So, I have removed all of the uses of AST_LIST_HEAD_INIT and replaced them
with the equivalent static initializations.
- On passing, fix a memory leak in the unload_module() function of chan_agent.
The agents list mutex was never destroyed, and the elements in the agents
list were not freed.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@26990 65c4cc65-6c06-0410-ace0-fbb531ad65f3
update iax2_indicate to pass control frame payload to the connected channel
add an API call for sending an indication with payload, and use it for control frames with payload
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@26417 65c4cc65-6c06-0410-ace0-fbb531ad65f3
