https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r114184 | kpfleming | 2008-04-16 15:46:38 -0500 (Wed, 16 Apr 2008) | 6 lines
use the ZT_SET_DIALPARAMS ioctl properly by initializing the structure to all zeroes in case it contains fields that we don't write values into (which it does as of Zaptel 1.4.10)
(closes issue #12456)
Reported by: fnordian
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@114185 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r112599 | mmichelson | 2008-04-03 09:32:20 -0500 (Thu, 03 Apr 2008) | 9 lines
Fix the testing of the "res" variable so that it is more logically correct and
makes the correct warning and debug messages print.
(closes issue #12361)
Reported by: one47
Patches:
chan_zap_deferred_digit.patch uploaded by one47 (license 23)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@112600 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Per comments from dimas:
1. The code now generates DTMF_BEGIN frames in addition to DTMF_END ones.
2. "quelching" rewritten - now each detector (MF/DTMF/generic tone) may mark fragment of a frame for suppression (squelching, muting) with a call to mute_fragment. Actual muting happens only once at the very end of ast_dsp_process where all marked fragments are zeroed. This way every detector sees original data in the frame without any piece of a frame being zeroed by a detector which was run before.
3. DTMF detector tries to "mute" one block before and one block after the block where actual tone was detected. Muting of previois block is something new for this patch. Obviously this operation is not always possible - if current frame does not contain data for previous block - it is too late. But at least we make our best.
Muting of next block was already done by the old code but it only affects part of the next block which is in the frame being processed. New code keeps this information in state structures so it will mute proper number of samples in the next frame(s) too.
4. Removed ast_dsp_digitdetect and ast_dsp_getdigits APIs because these are not used.
5. DSP API extended a bit - ast_dsp_was_muted() function added which returns true if DSP code was muting any fragment in the last frame. chan_zap uses this function to decide it needs to turn on confmute on the channel.
This is to replace AST_FRAME_DTMF 'm'/'u' (mute/unmute) functionality.
(closes issue #11968)
Reported by: dimas
Patches:
v2-11968-dsp.patch uploaded by dimas (license 88)
v4-11968-zap.patch uploaded by dimas (license 88)
Tested by: dimas, qwell
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@111022 65c4cc65-6c06-0410-ace0-fbb531ad65f3
by Juggie while attempting to load chan_zap. Apparently this would happen
if an error were encountered while trying to process zapata.conf.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109802 65c4cc65-6c06-0410-ace0-fbb531ad65f3
(closes issue #9503)
Reported by: tzafrir
Patches:
fix_cleanups uploaded by tzafrir (license 46)
zapata_sections uploaded by tzafrir (license 46)
skipchannel_options uploaded by tzafrir (license 46)
conf_sample uploaded by tzafrir (license 46)
patches updated by me to better conform to coding guidelines and fix some problems
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@108286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r106945 | kpfleming | 2008-03-08 09:59:42 -0600 (Sat, 08 Mar 2008) | 2 lines
don't generate D-Channel "up" and "down" messages unless the channel state is actually changing; also, generate the "up" message when an implicit "up" occurs due to reception of a normal event when we thought the channel was "down"
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@106946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r106038 | kpfleming | 2008-03-05 09:32:35 -0600 (Wed, 05 Mar 2008) | 7 lines
when a PRI call must be moved to a different B channel at the request of the other endpoint, ensure that any DSP active on the original channel is moved to the new one
(closes issue #11917)
Reported by: mavetju
Tested by: mavetju
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@106040 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r104119 | russell | 2008-02-25 18:25:29 -0600 (Mon, 25 Feb 2008) | 33 lines
Merge changes from team/russell/smdi-1.4
This commit brings in a significant set of changes to the SMDI support in Asterisk.
There were a number of bugs in the current implementation, most notably being that
it was very likely on busy systems to pop off the wrong message from the SMDI message
queue. So, this set of changes fixes the issues discovered as well as introducing
some new ways to use the SMDI support which are required to avoid the bugs with
grabbing the wrong message off of the queue.
This code introduces a new interface to SMDI, with two dialplan functions. First,
you get an SMDI message in the dialplan using SMDI_MSG_RETRIEVE() and then you access
details in the message using the SMDI_MSG() function. A side benefit of this is that
it now supports more than just chan_zap.
For example, with this implementation, you can have some FXO lines being terminated
on a SIP gateway, but the SMDI link in Asterisk.
Another issue with the current implementation is that it is quite common that the
station ID that comes in on the SMDI link is not necessarily the same as the Asterisk
voicemail box. There are now additional directives in the smdi.conf configuration
file which let you map SMDI station IDs to Asterisk voicemail boxes.
Yet another issue with the current SMDI support was related to MWI reporting over
the SMDI link. The current code could only report a MWI change when the change
was made by someone calling into voicemail. If the change was made by some other
entity (such as with IMAP storage, or with a web interface of some kind), then the
MWI change would never be sent. The SMDI module can now poll for MWI changes if
configured to do so.
This work was inspired by and primarily done for the University of Pennsylvania.
(also related to issue #9260)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@104120 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: julianjm
Patches:
chan_zap.c-1.4-devicestate-v1.diff uploaded by julianjm (license 99)
Patch fixes problem of device state incorrectly reporting idle before PBX answers incoming call on FXO channel. Device status is updated now during new channel creation.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103818 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r103770 | mmichelson | 2008-02-18 10:37:31 -0600 (Mon, 18 Feb 2008) | 10 lines
Fix a linked list corruption that under the right circumstances
could lead to a looped list, meaning it will traverse forever.
(closes issue #11818)
Reported by: michael-fig
Patches:
11818.patch uploaded by putnopvut (license 60)
Tested by: michael-fig
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103771 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r96449 | russell | 2008-01-04 10:19:22 -0600 (Fri, 04 Jan 2008) | 7 lines
Make use of the temporary channel pointer while the pvt is unlocked.
(closes issue #11675)
Reported by: flefoll
Patches:
chan_zap.c.patch-store-owner-before-unlock uploaded by flefoll (license 244)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@96450 65c4cc65-6c06-0410-ace0-fbb531ad65f3
(this implementation is not very memory efficient as the parameters and their values will be duplicated for each channel that has the same settings, but we can worry about that later once it is working)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@96019 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Mark Michelson
Kevin P. Fleming
Matthew Fredrickson
Jeff Peeler
Russell Bryant
Jason Parker
Joshua Colp
Tilghman Lesher
Doug Bailey
Olle Johansson