LIST instead of an RWLIST. The way this list works makes it such that
a RWLIST provides no additional benefit. Also, a mutex is needed for
use with the thread condition.
Merged revisions 105563 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r105563 | russell | 2008-03-03 09:50:43 -0600 (Mon, 03 Mar 2008) | 24 lines
Merge in some changes from team/russell/autoservice-nochans-1.4
These changes fix up some dubious code that I came across while auditing what
happens in the autoservice thread when there are no channels currently in
autoservice.
1) Change it so that autoservice thread doesn't keep looping around calling
ast_waitfor_n() on 0 channels twice a second. Instead, use a thread condition
so that the thread properly goes to sleep and does not wake up until a
channel is put into autoservice.
This actually fixes an interesting bug, as well. If the autoservice thread
is already running (almost always is the case), then when the thread goes
from having 0 channels to have 1 channel to autoservice, that channel would
have to wait for up to 1/2 of a second to have the first frame read from it.
2) Fix up the code in ast_waitfor_nandfds() for when it gets called with no
channels and no fds to poll() on, such as was the case with the previous code
for the autoservice thread. In this case, the code would call alloca(0), and
pass the result as the first argument to poll(). In this case, the 2nd
argument to poll() specified that there were no fds, so this invalid pointer
shouldn't actually get dereferenced, but, this code makes it explicit and
ensures the pointers are NULL unless we have valid data to put there.
(related to issue #12116)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@105564 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r105560 | file | 2008-03-03 11:28:59 -0400 (Mon, 03 Mar 2008) | 7 lines
It is possible for no audio to pass between the current digit and next digit so expand logic that clears emulation to AST_FRAME_NULL.
(closes issue #11911)
Reported by: edgreenberg
Patches:
v1-11911.patch uploaded by dimas (license 88)
Tested by: tbsky
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@105561 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r100581 | russell | 2008-01-28 11:15:41 -0600 (Mon, 28 Jan 2008) | 9 lines
Make some deadlock related fixes. These bugs were discovered and reported
internally at Digium by Steve Pitts.
- Fix up chan_local to ensure that the channel lock is held before the local
pvt lock.
- Don't hold the channel lock when executing the timing function, as it can
cause a deadlock when using chan_local. This actually changes the code back
to be how it was before the change for issue #10765. But, I added some other
locking that I think will prevent the problem reported there, as well.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@100582 65c4cc65-6c06-0410-ace0-fbb531ad65f3
today on another mac. We ignore the return value of locking operations almost
everywhere in Asterisk. So, ignore these, as well, so Asterisk will actually
work on systems where this is occurring while I look into what the issue is.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@100514 65c4cc65-6c06-0410-ace0-fbb531ad65f3
as a channel variable BRIDGEPVTCALLID
This is important for call tracing in log files and CDRs, so that
the SIP callID can be traced along servers.
The CHANNEL dialplan function won't work here, since the outbound
channel is gone when we need the Call-ID.
Other channel drivers may now implement the same function :-),
but this patch only supports chan_sip.so.
Inspired by (issue #11816)
Reported by: ctooley
Patch by oej
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@99644 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r95024 | russell | 2007-12-27 15:40:02 -0600 (Thu, 27 Dec 2007) | 9 lines
Don't report a syntax error when an empty string is passed to ast_get_group.
Just return 0.
(closes issue #11540)
Reported by: tzafrir
Patches:
group_empty.diff uploaded by tzafrir (license 46)
-- slightly changed by me
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@95025 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r94767 | tilghman | 2007-12-24 13:36:59 -0600 (Mon, 24 Dec 2007) | 5 lines
Race: we need to wait to queue a NewChannel event until after the channel is
inserted into the channel list. The reason is because some manager users
immediately queue requests from the channel when they see that event and are
confused when Asterisk reports no such channel. (Closes issue #11632)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@94768 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r93625 | mmichelson | 2007-12-18 11:02:48 -0600 (Tue, 18 Dec 2007) | 6 lines
Rework deadlock avoidance used in ast_write, since it meant that agent channels which were being monitored
had one audio file recorded and one empty audio file saved.
(closes issue #11529, reported by atis patched by me)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@93626 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- Newstate event
- Now has "CalleridNum" for numeric caller id, like Newchannel
- The event does not send "<unknown>" for unknown caller IDs just an empty field
- Newstate and Newchannel events
- these have changed headers
"State" -> ChannelStateDesc Text based channel state
-> ChannelState Numeric channel state
- The events does not send "<unknown>" for unknown caller IDs just an empty field
- Newstate event
- Now has "CalleridNum" for numeric caller id, like Newchannel
- The event does not send "<unknown>" for unknown caller IDs just an empty field
- Link and Unlink events
- The "Link" and "Unlink" bridge events in channel.c are now renamed to "Bridge"
- The link state is in the bridgestate: header as "Link" or "Unlink"
- For channel.c bridges, "Bridgetype: core" is added. This opens up for
bridge events in rtp.c and channel drivers
- The "Rename" manager event has a renamed header, to use the same
terminology for the current channel as other events
- Oldname -> Channel
(Moremanager)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@91409 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r90145 | russell | 2007-11-28 18:20:34 -0600 (Wed, 28 Nov 2007) | 5 lines
This set of changes is to make some callerID handling thread-safe.
The ast_set_callerid() function needed to lock the channel. Also, the handlers
for the CALLERID() dialplan function needed to lock the channel when reading
or writing callerid values directly on the channel structure.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@90146 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r89577 | file | 2007-11-26 11:34:38 -0400 (Mon, 26 Nov 2007) | 6 lines
If channel allocation fails because the alert pipe could not be created also free the scheduler context.
(closes issue #11355)
Reported by: eliel
Patches:
main.channel.c.patch uploaded by eliel (license 64)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89578 65c4cc65-6c06-0410-ace0-fbb531ad65f3
build times - tested, there is no measureable difference before and
after this commit.
In this change:
use asterisk/compat.h to include a small set of system headers:
inttypes.h, unistd.h, stddef.h, stddint.h, sys/types.h, stdarg.h,
stdlib.h, alloca.h, stdio.h
Where available, the inclusion is conditional on HAVE_FOO_H as determined
by autoconf.
Normally, source files should not include any of the above system headers,
and instead use either "asterisk.h" or "asterisk/compat.h" which does it
better.
For the time being I have left alone second-level directories
(main/db1-ast, etc.).
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89333 65c4cc65-6c06-0410-ace0-fbb531ad65f3
through ast_mutex primitives.
To detect all occurrences, I have renamed the lock field in struct ast_channel
so it is clear that it shouldn't be used directly.
There are some uses in res/res_features.c (see details of the diff)
that are error prone as they try and lock two channels without
caring about the order (or without explaining why it is safe).
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89293 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- the *_CURRENT macros no longer need the list head pointer argument
- add AST_LIST_MOVE_CURRENT to encapsulate the remove/add operation when moving entries between lists
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89106 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r88709 | russell | 2007-11-05 14:11:04 -0600 (Mon, 05 Nov 2007) | 20 lines
Merge the last bit of changes from asterisk/team/russell/readq-1.4
The issue here is that the channel frame readq handling got broken when the
code was converted to use the linked list macros. It caused corruption of the
list head and tail pointers. So, I fixed up the usage of the linked list
macros and in passing, simplified the code. I also documented what the code
is doing, as it was a bit difficult to figure out at first.
This bug showed itself with crashes showing messed up head/tail pointers for
the readq. However, there are a couple of crashes that aren't quite as obvious,
but I think may be related. So, if your bug gets closed by this commit, but
you still have a problem, please reopen or create a new bug report.
(closes issue #10936)
(closes issue #10595)
(closes issue #10368)
(closes issue #11084)
(closes issue #10040)
(closes issue #10840)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@88710 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r88624 | russell | 2007-11-05 11:46:02 -0600 (Mon, 05 Nov 2007) | 5 lines
Fix up datastore handling in ast_do_masquerade(). The code is intended to move
any channel datastores from the old channel to the new one. However, it did
not use the linked list macros properly to accomplish the task. The existing
code would only work if there was only a single datastore on the old channel.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@88651 65c4cc65-6c06-0410-ace0-fbb531ad65f3
details and examples are in include/asterisk/stringfields.h.
Not applicable to older branches except for 1.4 which will
receive a fix for the routines that free memory pools.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@88454 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r86750 | russell | 2007-10-22 10:52:48 -0500 (Mon, 22 Oct 2007) | 8 lines
Don't leak a frame in the case that an END frame is received and the time since
the BEGIN is less than that of the defined minimum DTMF duration.
(closes issue #11051)
Reported by: casper
Patches:
channel.c.86664.diff uploaded by casper (license 55)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@86751 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r86330 | russell | 2007-10-18 13:03:10 -0500 (Thu, 18 Oct 2007) | 10 lines
The channel needs to stay locked while running timer callbacks, as they access
and modify channel data that may change elsewhere. I went through every timer
callback in the source tree to make sure that none of them did any additional
locking that could introduce deadlocks, and all is well.
(closes issue #10765)
Reported by: Ivan
Patches:
ast_1_4_11_svn_patch_channel_rc.diff uploaded by Ivan (license 229)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@86331 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r83432 | russell | 2007-09-21 09:37:20 -0500 (Fri, 21 Sep 2007) | 4 lines
gcc 4.2 has a new set of warnings dealing with cosnt pointers. This set of
changes gets all of Asterisk (minus chan_alsa for now) to compile with gcc 4.2.
(closes issue #10774, patch from qwell)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@83433 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Convert some spaces to tabs in func_volume
* Add a note in channel.h making it clear that none of the datastore API calls
lock the channel they are given, so the channel should be locked before
calling the functions that take a channel argument.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@81260 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: pj
Two of the three places ast_waitfor_nandfds could branch off to did not clear outfd and exception. If the calling function did not clear these there was a chance they could get a false positive on testing to see whether they were set.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@79379 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r77780 | russell | 2007-07-30 12:29:43 -0500 (Mon, 30 Jul 2007) | 16 lines
(closes issue #10301)
Reported by: fnordian
Patches:
asterisk-1.4.9-channel.c.patch uploaded by fnordian (license 110)
Additional changes by me
Fix some problems in channel_find_locked() which can cause an infinite loop.
The reference to the previous channel is set to NULL in some cases. These changes
ensure that the reference to the previous channel gets restored before needing
it again.
I'm not convinced that the code that is setting it to NULL is really the right
thing to do. However, I am making these changes to fix the obvious problem
and just leaving an XXX comment that it needs a better explanation that what
is there now.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@77781 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r77771 | file | 2007-07-30 12:47:52 -0300 (Mon, 30 Jul 2007) | 6 lines
(closes issue #10301)
Reported by: fnordian
Patches:
asterisk-1.4.9-channel.c.patch uploaded by fnordian (license 110)
Restore previous behavior where if we failed to lock the channel we wanted we would return to exactly the same point as if we had just reentered the function.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@77772 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r77460 | file | 2007-07-26 20:19:04 -0300 (Thu, 26 Jul 2007) | 4 lines
(closes issue #10302)
Reported by: litnialex
If a DTMF end frame comes from a channel without a begin and it is going to a technology that only accepts end frames (aka INFO) then use the minimum DTMF duration if one is not in the frame already.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@77461 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r76132 | russell | 2007-07-20 13:22:24 -0500 (Fri, 20 Jul 2007) | 6 lines
Use the define that specifies the default length of an artificially created
DTMF digit in the ast_senddigit() function. The define is set to 100ms by
default, which is the same thing that this function was using. But, using
the define lets changes take effect in this case, as well as the others where
it was already used.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@76138 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
defined in indications.h to ind_tone_zone_sound and ind_tone_zone,
to avoid conflicts with the structs with the same names
defined in tonezone.h
Hope i haven't missed any instance.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@48958 65c4cc65-6c06-0410-ace0-fbb531ad65f3
before calling it.
This allows generators to set it to NULL when they have nothing to
do there.
Later, the three copies of the code that releases a generator
should be moved to a function.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@48766 65c4cc65-6c06-0410-ace0-fbb531ad65f3
