https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r111049 | mmichelson | 2008-03-26 14:22:16 -0500 (Wed, 26 Mar 2008) | 9 lines
Add a lock to the vm_state structure and use the lock around mail_open calls
to prevent concurrent access of the same mailstream. This, along with trunk's
ability to configure TCP timeouts for IMAP storage will help to prevent
crashes and hangs when using voicemail with IMAP storage.
(closes issue #10487)
Reported by: ewilhelmsen
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@111067 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
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r110628 | file | 2008-03-25 11:37:35 -0300 (Tue, 25 Mar 2008) | 4 lines
Add an option (transmit_silence) which transmits silence during both Record() and DTMF generation. The reason this is an option is that in order to transmit silence we have to setup a translation path. This may not be needed/wanted in all cases.
(closes issue #10058)
Reported by: tracinet
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@111017 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r110880 | kpfleming | 2008-03-26 09:42:35 -0700 (Wed, 26 Mar 2008) | 10 lines
Merged revisions 110869 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r110869 | kpfleming | 2008-03-26 08:53:46 -0700 (Wed, 26 Mar 2008) | 2 lines
due to licensing restrictions, we cannot distribute the source code for iLBC encoding and decoding... so remove it, and add instructions on how the user can obtain it themselves
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@110881 65c4cc65-6c06-0410-ace0-fbb531ad65f3
change, it was possible to start Asterisk with the manager interface enabled, then
either comment out the enabled option or make manager.conf unopenable and the manager
interface would still be enabled.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@110831 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r110635 | mmichelson | 2008-03-25 10:40:33 -0500 (Tue, 25 Mar 2008) | 7 lines
When reverting a commit, I accidentally left in this bit which was an experiment
to see what would happen. It passed the compile test, and I didn't notice I had
left this change in too.
So this is a revert of a revert...sort of.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@110636 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r110628 | file | 2008-03-25 11:37:35 -0300 (Tue, 25 Mar 2008) | 4 lines
Add an option (transmit_silence) which transmits silence during both Record() and DTMF generation. The reason this is an option is that in order to transmit silence we have to setup a translation path. This may not be needed/wanted in all cases.
(closes issue #10058)
Reported by: tracinet
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@110629 65c4cc65-6c06-0410-ace0-fbb531ad65f3
SIP REGISTER requests. rjain points out that RFC 3265 specifies
that the Event: header is not a valid header for REGISTER requests
and that the "registration" value is not defined at IANA.
(closes issue #12279)
Reported by: rjain
Patches:
chan_sip.c.diff uploaded by rjain (license 226)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@110621 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r110618 | mmichelson | 2008-03-24 14:17:41 -0500 (Mon, 24 Mar 2008) | 15 lines
This is a revert for revision 108288. The reason is that that revision
was not for an actual bug fix per se, and so it really should not have been in 1.4 in
the first place. Plus, people who compile with DO_CRASH are more likely
to encounter a crash due to this change. While I think the usage of DO_CRASH
in ast_sched_del is a bit absurd, this sort of change is beyond the scope of 1.4
and should be done instead in a developer branch based on trunk
so that all scheduler functions are fixed at once.
I also am reverting the change to trunk and 1.6 since they also suffer from
the DO_CRASH potential.
(closes issue #12272)
Reported by: qq12345
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@110619 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r110395 | russell | 2008-03-20 18:13:56 -0500 (Thu, 20 Mar 2008) | 9 lines
Shorten the ast_waitfor() timeout from 500 ms to 50 ms in the autoservice thread.
This really should not make a difference except in very rare cases. That case would
be that all of the channels in autoservice are not generating any frames. In that
case, this change reduces the potential amount of time that a thread waits in
ast_autoservice_stop() for the autoservice thread to wrap back around to the beginning
of its loop.
(closes issue #12266, reported by dimas)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@110396 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r110336 | russell | 2008-03-20 16:54:58 -0500 (Thu, 20 Mar 2008) | 14 lines
Merged revisions 110335 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r110335 | russell | 2008-03-20 16:53:27 -0500 (Thu, 20 Mar 2008) | 6 lines
Fix some very broken code that was introduced in 1.2.26 as a part of the security
fix. The dnsmgr is not appropriate here. The dnsmgr takes a pointer to an address
structure that a background thread continuously updates. However, in these cases,
a stack variable was passed. That means that the dnsmgr thread would be continuously
writing to bogus memory.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@110337 65c4cc65-6c06-0410-ace0-fbb531ad65f3
other than 8 kHz. The issue here is that format modules give a "whennext" sample
value, which is used to calculate when to set a timer for to retrieve the next
frame. However, the zaptel timer operates on 8 kHz samples, so this must be taken
into account.
(another part of issue #12164, reported by milazzo and jsmith, patch by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@110303 65c4cc65-6c06-0410-ace0-fbb531ad65f3
G.722 music on hold working for me.
(issue #12164, reported by milazzo and jsmith, patches by me)
res/res_musiconhold.c:
- I moved a single line so that the sample queue update happened before
ast_write(). The reason that this was a bug is that the G.722 frame
originally says it has 320 samples in it (which is correct). However,
when the frame is written to a channel that uses RTP, main/rtp.c modifies
the frame to cut the number of samples in half before it sends it on
the wire. This is to account for the stupid incorrect G.722 spec that
makes it so we have to lie about the number of samples with RTP. I should
probably go and re-work the RTP code so it doesn't modify the frame so
that a bug like this won't happen in the future. However, this change to
MOH is harmless.
main/channel.c:
- I made two fixes in regards to generator timing. Generators use samples
for timing. However, this code assumed 8 kHz samples. In one case, it was
a hard coded 160 samples, that is now written as the sample rate / 50. The
other place was dealing with timing a generator based on frames coming from
the other direction. However, that would have only worked if the sample
rates for the formats in both directions were the same. The code now takes
into account that the sample rates may differ, and scales the generator
samples accordingly.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@110268 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1) Number of digits to enter can now be configured
2) The digits can now match on both first AND last name, instead of only one or the other
(Closes issue #7151)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@110237 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r110035 | file | 2008-03-19 16:11:33 -0300 (Wed, 19 Mar 2008) | 4 lines
Add sanity checking for position resuming. We *have* to make sure that the position does not exceed the total number of files present, and we have to make sure that the position's filename is the same as previous. These values can change if a music class is reloaded and give unpredictable behavior.
(closes issue #11663)
Reported by: junky
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@110036 65c4cc65-6c06-0410-ace0-fbb531ad65f3
