https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r122130 | tilghman | 2008-06-12 10:11:30 -0500 (Thu, 12 Jun 2008) | 4 lines
Occasionally, the alertpipe loses its nonblocking status, so detect and correct
that situation before it causes a deadlock. (Reported and tested by ctooley
via #asterisk-dev)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@122131 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r121280 | russell | 2008-06-09 11:35:40 -0500 (Mon, 09 Jun 2008) | 10 lines
Do not attempt to do emulation if an END digit is received and the length is
less than the defined minimum digit length, and the other end only wants END
digits (SIP INFO, for example).
(closes issue #12778)
Reported by: tsearle
Patches:
12778.rev1.txt uploaded by russell (license 2)
Tested by: tsearle
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@121282 65c4cc65-6c06-0410-ace0-fbb531ad65f3
hold tracking information for mutexes. Now, the "core show locks" output
will output information about who is holding a rwlock when a thread is
waiting on it.
(closes issue #11279)
Reported by: ys
Patches:
trunk_lock_utils.v8.diff uploaded by ys (license 281)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@120064 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- make data member of the ast_frame struct a named union instead of a void
Recently the ast_queue_hangup function got a new parameter, the hangupcause
Feedback came in that this is no good and that instead a new function should be created.
This I did.
The hangupcause was stored in the seqno member of the ast_frame struct. This is not very
elegant, and since there's already a data member that one should be used.
Problem is, this member was a void *.
Now it's a named union so it can hold a pointer, an uint32 and there's a padding in case someone
wants to store another type in there in the future.
This commit is so massive, because all ast_frame.data uses have to be
altered to ast_frame.data.data
Thanks russellb and kpfleming for the feedback.
(closes issue #12674)
Reported by: mvanbaak
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@117802 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r116088 | mmichelson | 2008-05-13 18:47:49 -0500 (Tue, 13 May 2008) | 12 lines
A change to the way channel locks are handled when DEBUG_CHANNEL_LOCKS is defined.
After debugging a deadlock, it was noticed that when DEBUG_CHANNEL_LOCKS
is enabled in menuselect, the actual origin of channel locks is obscured
by the fact that all channel locks appear to happen in the function
ast_channel_lock(). This code change redefines ast_channel_lock to be a
macro which maps to __ast_channel_lock(), which then relays the proper
file name, line number, and function name information to the core lock
functions so that this information will be displayed in the case that
there is some sort of locking error or core show locks is issued.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@116089 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r114117 | mmichelson | 2008-04-14 12:41:03 -0500 (Mon, 14 Apr 2008) | 11 lines
Increase the retry count when attempting to show channels. This apparently
cleared an issue someone was seeing when attempting to show channels when
the load was high.
(closes issue #11667)
Reported by: falves11
Patches:
11677.txt uploaded by russell (license 2)
Tested by: falves11
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@114118 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r114106 | mmichelson | 2008-04-14 09:58:02 -0500 (Mon, 14 Apr 2008) | 5 lines
Save a local copy of the generate callback prior to unlocking the channel in
case the generate callback goes NULL on us after the channel is unlocked. Thanks
to Russell for pointing this need out to me.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@114107 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r113065 | mmichelson | 2008-04-07 11:08:45 -0500 (Mon, 07 Apr 2008) | 13 lines
This fix prevents a deadlock that was experienced in chan_local. There was
deadlock prevention in place in chan_local, but it would not work in a specific
case because the channel was recursively locked. By unlocking the channel prior
to calling the generator's generate callback in ast_read_generator_actions(), we
prevent the recursive locking, and therefore the deadlock.
(closes issue #12307)
Reported by: callguy
Patches:
12307.patch uploaded by putnopvut (license 60)
Tested by: callguy
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@113066 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
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r108583 | russell | 2008-03-13 16:38:16 -0500 (Thu, 13 Mar 2008) | 11 lines
Fix another issue that was causing crashes in chanspy. This introduces a new
datastore callback, called chan_fixup(). The concept is exactly like the
fixup callback that is used in the channel technology interface. This callback
gets called when the owning channel changes due to a masquerade. Before this
was introduced, if a masquerade happened on a channel being spyed on, the
channel pointer in the datastore became invalid.
(closes issue #12187)
(reported by, and lots of testing from atis)
(props to file for the help with ideas)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@108584 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r108135 | russell | 2008-03-12 14:57:42 -0500 (Wed, 12 Mar 2008) | 40 lines
(closes issue #12187, reported by atis, fixed by me after some brainstorming
on the issue with mmichelson)
- Update copyright info on app_chanspy.
- Fix a race condition that caused app_chanspy to crash. The issue was that
the chanspy datastore magic that was used to ensure that spyee channels did
not disappear out from under the code did not completely solve the problem.
It was actually possible for chanspy to acquire a channel reference out of
its datastore to a channel that was in the middle of being destroyed. That
was because datastore destruction in ast_channel_free() was done near the
end. So, this left the code in app_chanspy accessing a channel that was
partially, or completely invalid because it was in the process of being free'd
by another thread. The following sort of shows the code path where the race
occurred:
=============================================================================
Thread 1 (PBX thread for spyee chan) || Thread 2 (chanspy)
--------------------------------------||-------------------------------------
ast_channel_free() ||
- remove channel from channel list ||
- lock/unlock the channel to ensure ||
that no references retrieved from ||
the channel list exist. ||
--------------------------------------||-------------------------------------
|| channel_spy()
- destroy some channel data || - Lock chanspy datastore
|| - Retrieve reference to channel
|| - lock channel
|| - Unlock chanspy datastore
--------------------------------------||-------------------------------------
- destroy channel datastores ||
- call chanspy datastore d'tor ||
which NULL's out the ds' || - Operate on the channel ...
reference to the channel ||
||
- free the channel ||
||
|| - unlock the channel
--------------------------------------||-------------------------------------
=============================================================================
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@108137 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
be called for each thread specific object after they are allocated. Note that
there was already the ability to define a custom cleanup function. Also, if
the custom cleanup function is used, it *MUST* call free on the thread
specific object at the end. There is no way to have this magically done that
I can think of because the cleanup function registered with the pthread
implementation will only call the function back with a pointer to the
thread specific object, not the parent ast_threadstorage object.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@45623 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r45441 | russell | 2006-10-17 22:41:36 -0400 (Tue, 17 Oct 2006) | 7 lines
Don't attempt to access private data members of the pthread_mutex_t object,
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/trunk@45442 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r45408 | kpfleming | 2006-10-17 17:24:10 -0500 (Tue, 17 Oct 2006) | 3 lines
optimize the 'quick response' code a bit more... no more malloc() or memset() for each response
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/trunk@45409 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r43779 | russell | 2006-09-27 12:55:49 -0400 (Wed, 27 Sep 2006) | 50 lines
Merged revisions 43778 via svnmerge from
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/trunk@43780 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r43695 | file | 2006-09-26 16:09:41 -0400 (Tue, 26 Sep 2006) | 2 lines
Slight overhaul of the whisper support. 1. We need to duplicate the frame from ast_translate 2. We need to ensure we always have signed linear coming in for signed linear combining. 3. We need to ensure we are always feeding signed linear out. 4. Properly store and restore write format when beeping on the channel we are whispering on. 5. Properly discontinue the stream on the channel for the beep. (issue #8019 reported by timkelly1980)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@43696 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
Jeff Peeler
Tilghman Lesher
Joshua Colp
Russell Bryant
Michiel van Baak
Mark Michelson
Jason Parker
Olle Johansson
Luigi Rizzo
Kevin P. Fleming
Dwayne M. Hubbard
Steve Murphy
Paul Cadach
Matt O'Gorman