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/branches/1.4@63612 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.4@63608 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.4@62942 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.4@62789 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.4@61781 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.4@51848 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
because this does not work on all linux systems. Instead, just access
the reentrancy field in the ast_mutex_info struct when DEBUG_THREADS is
enabled. If DEBUG_CHANNEL_LOCKS is enabled, the developer probably has
DEBUG_THREADS on as well.
(issue #8139, me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@45441 65c4cc65-6c06-0410-ace0-fbb531ad65f3
expand stringfields API a bit to allow reusing the stringfield pool on a structure when needed, and remove some unnecessary code when the structure was being freed
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@45408 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r43778 | russell | 2006-09-27 12:54:30 -0400 (Wed, 27 Sep 2006) | 42 lines
Fix a problem that occurred if a user entered a digit that matched a bridge
feature that was configured using multiple digits, and the digit that was
pressed timed out in the feature digit timeout period. For example, if blind
transfer is configured as '##', and a user presses just '#'. In this situation,
the call would lock up and no longer pass any frames.
(issue #7977 reported by festr, and issue #7982 reported by michaels and
valuable input provided by mneuhauser and kuj. Fixed by me, with testing help
and peer review from Joshua Colp).
There are a couple of issues involved in this fix:
1) When ast_generic_bridge determines that there has been a timeout, it returned
AST_BRIDGE_RETRY. Then, when ast_channel_bridge gets this result, it calls
ast_generic_bridge over again with the same timestamp for the next event.
This results in an endless loop of nothing until the call is terminated.
This is resolved by simply changing ast_generic_bridge to return
AST_BRIDGE_COMPLETE when it sees a timeout.
2) I also changed ast_channel_bridge such that if in the process of calculating
the time until the next event, it knows a timeout has already occured, to
immediately return AST_BRIDGE_COMPLETE instead of attempting to bridge the
channels anyway.
3) In the process of testing the previous two changes, I ran into a problem in
res_features where ast_channel_bridge would return because it determined
that there was a timeout. However, ast_bridge_call in res_features would
then determine by its own calculation that there was still 1 ms before the
timeout really occurs. It would then proceed, and since the bridge broke
out and did *not* return a frame, it interpreted this as the call was over
and hung up the channels.
The reason for this was because ast_bridge_call in res_features and
ast_channel_bridge in channel.c were using different times for their
calculations. channel.c uses the start_time on the bridge config, which
is the time that the feature digit was recieved. However, res_features
had another time, 'start', which was set right before calling
ast_channel_bridge. 'start' will always be slightly after start_time in the
bridge config, and sometimes enough to round up to one ms.
This is fixed by making ast_bridge_call use the same time as
ast_channel_bridge for the timeout calculation.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@43779 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r42600 | file | 2006-09-09 16:24:19 -0400 (Sat, 09 Sep 2006) | 2 lines
Only truly consider the channel in the same format if the format matches the raw format OR if a translation path already exists to translate between them. (issue #7887 reported by softins & issue #7803 reported by alvaro_palma_aste). Thanks goes to stubert for giving me access to a box and showing me a scenario where this occured.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@42601 65c4cc65-6c06-0410-ace0-fbb531ad65f3
very stupid thing to do. It ends up duplicating the frame twice, linking in
one of them and setting the tail pointer to the other one. Sorry ...
Thanks to file for pointing out the breakage!!! file rocks.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@41864 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There are some situations in Asterisk where ast_frame and/or iax_frame
structures are rapidly allocatted and freed (at least 50 times per second
for one call).
This code significantly improves the performance of ast_frame_header_new(),
ast_frdup(), ast_frfree(), iax_frame_new(), and iax_frame_free() by keeping
a thread-local cache of these structures and using frames from the cache
whenever possible instead of calling malloc/free every time.
This commit also converts the ast_frame and iax_frame structures to use the
linked list macros.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@41278 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r40994 | russell | 2006-08-24 15:41:26 -0400 (Thu, 24 Aug 2006) | 11 lines
Fix a few issues related to the handling of channel variables
- in pbx_builtin_serialize_variables(), the variable list traversal would stop
on a variables with empty name/values, which is not appropriate
- When removing the GROUP variables, use AST_LIST_REMOVE_CURRENT instead of
AST_LIST_REMOVE
- During masquerading, when copying the variables list from one channel to the
other, using AST_LIST_INSERT_TAIL is not valid for appending a whole list.
It leaves the tail pointer of the list invalid. Introduce a new macro,
AST_LIST_APPEND_LIST that appends a list properly.
(issue #7802, softins)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@40995 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- free the string fields allocation if ast_create_channel() failes to open the
alert pipe
- formatting tweaks
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@40782 65c4cc65-6c06-0410-ace0-fbb531ad65f3
