https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r72257 | file | 2007-06-27 16:25:24 -0400 (Wed, 27 Jun 2007) | 10 lines
Merged revisions 72256 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r72256 | file | 2007-06-27 16:23:24 -0400 (Wed, 27 Jun 2007) | 2 lines
I may possibly get shot for doing this... but... defer CDR processing until after the channel has been dealt with. This should eliminate all of the issues with channels going funky (SIP/PRI) when you are posting CDRs to a database that is either slow or unavailable and do not want to enable batching.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@72258 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r70062 | murf | 2007-06-19 12:23:23 -0600 (Tue, 19 Jun 2007) | 9 lines
Merged revisions 70053 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r70053 | murf | 2007-06-19 12:07:59 -0600 (Tue, 19 Jun 2007) | 1 line
This fixes 9246, where channel variables are not available in the 'h' exten, on a 'ZOMBIE' channel. The fix is to consolidate the channel variables during a masquerade, and then copy the merged variables back onto the clone, so the zombie has the same vars that the 'original' has.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@70063 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r69010 | russell | 2007-06-12 14:13:41 -0500 (Tue, 12 Jun 2007) | 12 lines
In ast_channel_make_compatible(), just return if the channels' read and write
formats already match up. There are code paths that call this function on a
pair of channels multiple times. This made calls fail that were using g729
in some cases. The reason is that codec_g729a will unregister itself from the
list of available translators will all licenses are in use. So, the first
time the function got called, the right translation path was allocated.
However, the second time it got called, the code would not find a translation
path to/from g729 and make the call fail, even if the channel actually already
had a g729 translation path allocated.
(SPD-32)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@69011 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r67716 | russell | 2007-06-06 11:55:59 -0500 (Wed, 06 Jun 2007) | 13 lines
Merged revisions 67715 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r67715 | russell | 2007-06-06 11:40:51 -0500 (Wed, 06 Jun 2007) | 5 lines
We have some bug reports showing crashes due to a double free of a channel.
Add a sanity check to ast_channel_free() to make sure we don't go on trying
to free a channel that wasn't found in the channel list.
(issue #8850, and others...)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@67717 65c4cc65-6c06-0410-ace0-fbb531ad65f3
class in musiconhold.conf, a caller on hold may press this digit to switch
to listening to that music class.
This involved adding a new callback for generators, which allow generators
to get notified of DTMF from the channel they are running on. Then, a callback
was implemented for the music on hold generators.
(patch from bbryant)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@65505 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r63612 | russell | 2007-05-09 11:55:27 -0500 (Wed, 09 May 2007) | 5 lines
Modify ast_senddigit_begin() to use the same assumptions used elsewhere in the
code in that if a channel does not have a send_digit_begin() callback, it only
cares about DTMF END events. (pointed out by Michael Neuhauser on the
asterisk-dev list)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@63697 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r63608 | russell | 2007-05-09 11:43:50 -0500 (Wed, 09 May 2007) | 5 lines
Only call ast_senddigit_begin() in ast_senddigit() if the channel has a
send_digit_begin() callback. Checking the END_DTMF_ONLY flag was the
wrong thing to do, because that flag indicates that a *bridged* channel
only wants DTMF END events coming from this channel.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@63609 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r62942 | russell | 2007-05-03 10:23:13 -0500 (Thu, 03 May 2007) | 17 lines
Fix YADB (Yet Another DTMF Bug) ((C) Russell Bryant, 2007, TM, Patent Pending).
This set of changes came from a debugging session I had with Dwayne Hubbard.
When he called into his home FXO, ran the Echo application, and pressed a
digit, the digit would be echoed back and would never end. This is fixed,
along with a couple other little improvements.
* When chan_zap is in the middle of playing a digit to a channel, it feeds
back null frames, not voice frames. So, I have modified ast_read to check
the timing on emulated DTMF when it receives null frames, in addition to
where it was doing this on voice frames.
* Make a tweak to setting the duration on emulated DTMF digits. If there was
no duration specified, it set it to be the minimum, instead of the default.
* Instead of timing the emulated digits off of the number of samples in audio
frames that pass through, just use time values. Now there is no code in this
section that assumes 8kHz audio.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@62943 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r62789 | russell | 2007-05-02 17:59:09 -0500 (Wed, 02 May 2007) | 20 lines
Merge changes from team/russell/inband_dtmf ...
Fix some issues related to generating inband DTMF. There are two changes here:
1) The list of DTMF tones in the senddigit_begin() function explicitly
specified 100ms of the tone followed by 100ms of silence. This really
broke things with the way that Asterisk now wants complete control
over when the digit begins and ends. So, regardless of what Asterisk
really wanted to do, this was going to play out the tone at the length it
wanted to. This caused various problems like DTMF translation to inband to
be extremely unreliable.
The list of tones has been changed so that the correct DTMF tone is played
indefinitely until Asterisk tells it to stop.
2) ast_write() had to be modified to let a DTMF_END frame get processed even
when a generator is present. This is how the tone will finally get stopped.
(issues #8944, #9250, #9348, maybe others. Thanks to mdu113 from #8944 for
the testing and feedback!)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@62791 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r62689 | murf | 2007-05-02 11:10:50 -0600 (Wed, 02 May 2007) | 1 line
a)In chan_zap, set the clid, src fields in channel_alloc call. b)in the channel_alloc func, set the cid_num and name fields from the arglist[blush]. c) don't update the channel app & app data fields if you are in the 'h' extension. d)the load_module func in cdr_radius needs to return DECLINE, SUCCESS.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@62690 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r61781 | russell | 2007-04-24 14:00:06 -0500 (Tue, 24 Apr 2007) | 6 lines
Improve DTMF handling in ast_read() even more in response to a discussion on
the asterisk-dev mailing list. I changed the enforced minimum length of a
digit from 100ms to 80ms. Furthermore, I made it now enforce a gap of 45ms in
between digits. These values are not configurable in a configuration file
right now, but they can be easily changed near the top of main/channel.c.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61782 65c4cc65-6c06-0410-ace0-fbb531ad65f3
T.140/RFC 2793 is a live communication channel, originally
created for IP based text phones for hearing impaired.
Feels very much like the old Unix talk application.
This code is developed and disclaimed by John Martin of Aupix, UK.
Tested for interoperability by myself and Omnitor in Sweden,
the company that wrote most of the specifications.
A big thank you to everyone involved in this.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@54838 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r51848 | russell | 2007-01-23 18:59:58 -0600 (Tue, 23 Jan 2007) | 14 lines
Merged revisions 51843 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r51843 | russell | 2007-01-23 18:57:28 -0600 (Tue, 23 Jan 2007) | 6 lines
Fix an issue related to synchronization of recordings when using Monitor().
The bug is a miscalculation of the amount to seek the stream for writing to
disk when the number of samples coming in and out of a channel do not match up.
(issue #8298, #8887, report and patch by guillecabeza, patch files created and
testing done by whoiswes)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@51850 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r51311 | russell | 2007-01-19 11:49:38 -0600 (Fri, 19 Jan 2007) | 23 lines
Merge the changes from the /team/group/vldtmf_fixup branch.
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/trunk@51314 65c4cc65-6c06-0410-ace0-fbb531ad65f3
