| Age | Commit message (Collapse) | Author |
|---|
|
- Convert the last part of channel.c over to use the timing API. This would
not have made a difference when using the dahdi timing module. I noticed
it when trying to use another timing source. Oops. :)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@122923 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
- Convert chan_iax2 to use the timing API
- Convert usage of timing in the core to use the timing API instead of
using DAHDI directly
- Make a change to the timing API to add the set_rate() function
- change the timing core to use a rwlock
- merge a timing implementation, res_timing_dahdi
Basic testing was successful using res_timing_dahdi
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@122523 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Configuration file and dialplan backwards compatability has been put in place where appropiate. Release announcement to follow.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@122234 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
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
........
r121861 | tilghman | 2008-06-11 13:18:16 -0500 (Wed, 11 Jun 2008) | 3 lines
Make calls to ast_assert() actually test something, so that the error message
printed is not nonsensical (reported by mvanbaak via #asterisk-bugs).
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@121867 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r121442 | file | 2008-06-10 09:52:06 -0300 (Tue, 10 Jun 2008) | 4 lines
Update BRIDGEPEER variable before we do a generic bridge in case we just broke out of a native bridge and fell through to generic.
(closes issue #12815)
Reported by: ramonpeek
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@121444 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(closes issue #12824)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@121285 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(closes issue #12824)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@121284 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
|
|
(issue #12674)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@117212 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r116463 | russell | 2008-05-14 16:32:00 -0500 (Wed, 14 May 2008) | 4 lines
Add ast_assert(), which can be used to handle fatal errors. It is only compiled
in if dev-mode is enabled, and only aborts if DO_CRASH is defined.
(inspired by issue #12650)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@116469 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
|
|
(closes issue #10540)
Reported by: spendergrass
Patches:
20080417__bug10540.diff.txt uploaded by Corydon76 (license 14)
Tested by: blitzrage
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@115076 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(closes issue #11328)
Reported by: rain
Patches:
20071207__pass_cause_in_hangup_control_frame.diff.txt uploaded by Corydon76 (license 14)
brought up-to-date to trunk by me
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@114637 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@114548 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(closes issue #12444)
Reported by: IgorG
Patches:
channel_c_debug.diff uploaded by IgorG (license 20)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@114131 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
|
|
to be played upon completion of an attended transfer.
(closes issue #9239)
Reported by: sunder
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@110631 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
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r108031 | russell | 2008-03-12 11:59:07 -0500 (Wed, 12 Mar 2008) | 4 lines
Destroy the channel lock after the channel datastores.
(inspired by issue #12187)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@108032 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r107102 | russell | 2008-03-10 12:13:17 -0500 (Mon, 10 Mar 2008) | 2 lines
Resolve a compiler warning.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@107103 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r107099 | russell | 2008-03-10 11:58:57 -0500 (Mon, 10 Mar 2008) | 3 lines
Fix a race condition where the generator can go away
(closes issue #12175, reported by edantie, patched by me)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@107100 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r106788 | file | 2008-03-07 15:32:00 -0400 (Fri, 07 Mar 2008) | 4 lines
Ignore source update control frame.
(closes issue #12168)
Reported by: plack
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@106789 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r106552 | tilghman | 2008-03-07 00:36:33 -0600 (Fri, 07 Mar 2008) | 6 lines
Safely use the strncat() function.
(closes issue #11958)
Reported by: norman
Patches:
20080209__bug11958.diff.txt uploaded by Corydon76 (license 14)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@106553 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r106235 | file | 2008-03-05 18:32:10 -0400 (Wed, 05 Mar 2008) | 4 lines
Add a control frame to indicate the source of media has changed. Depending on the underlying technology it may need to change some things.
(closes issue #12148)
Reported by: jcomellas
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@106239 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@105840 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
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103832 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
been seeing (unreported?) with file playback not working.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103831 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r103801 | file | 2008-02-18 19:56:48 -0400 (Mon, 18 Feb 2008) | 10 lines
Ensure that emulated DTMFs do not get interrupted by another begin frame.
(closes issue #11740)
Reported by: gserra
Patches:
v1-11740.patch uploaded by dimas (license 88)
(closes issue #11955)
Reported by: tsearle
(closes issue #10530)
Reported by: xmarksthespot
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103802 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
channel. This uses control frames (so they can even pass across IAX2) to negotiate T38 and provided a way of getting the current status of T38 using queryoption. This should by no means cause any issues and if it does I will take responsibility for it.
(closes issue #11873)
Reported by: dimas
Patches:
v4-t38-api.patch uploaded by dimas (license 88)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103799 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
And ... it works!
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103772 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(closes issue #11268)
Reported by: moy
Patches:
chantrace-datastored-encapsulated-rev94934.patch uploaded by moy (license 222)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103754 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(closes issue #11996)
Patches:
bug_11996_doxygen.diff uploaded by snuffy (license 35)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103723 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
enabled. The RTP bridging could already handle this, it just needed to be enabled in the main bridging code.
(issue #10647)
Reported by: samdell3
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103314 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
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@100533 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
- Make a few little formatting changes
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@100532 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
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@100095 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@100094 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
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@99008 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
