https://origsvn.digium.com/svn/asterisk/trunk
........
r252089 | twilson | 2010-03-12 16:04:51 -0600 (Fri, 12 Mar 2010) | 20 lines
Only change the RTP ssrc when we see that it has changed
This change basically reverts the change reviewed in
https://reviewboard.asterisk.org/r/374/ and instead limits the
updating of the RTP synchronization source to only those times when we
detect that the other side of the conversation has changed the ssrc.
The problem is that SRCUPDATE control frames are sent many times where
we don't want a new ssrc, including whenever Asterisk has to send DTMF
in a normal bridge. This is also not the first time that this mistake
has been made. The initial implementation of the ast_rtp_new_source
function also changed the ssrc--and then it was removed because of
this same issue. Then, we put it back in again to fix a different
issue. This patch attempts to only change the ssrc when we see that
the other side of the conversation has changed the ssrc.
It also renames some functions to make their purpose more clear.
Review: https://reviewboard.asterisk.org/r/540/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@252135 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r246899 | dvossel | 2010-02-16 11:07:41 -0600 (Tue, 16 Feb 2010) | 16 lines
fixes sample rate conversion issue with Monitor application
When using ast_seekstream with the read/write streams of a monitor,
the number of samples we are seeking must be of the same rate as the
stream or the jump calculation will be incorrect. This patch adds logic
to correctly convert the number of samples to jump to the sample rate
the read/write stream is using.
For example, if the call is G722 (16khz) and the read/write stream is
recording a 8khz wav, seeking 320 samples of 16khz audio is not the
same as seeking 320 samples of 8khz audio when performing the ast_seekstream
on the stream.
ABE-2044
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@246902 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r246546 | dvossel | 2010-02-12 17:32:33 -0600 (Fri, 12 Feb 2010) | 21 lines
Merged revisions 246545 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r246545 | dvossel | 2010-02-12 17:30:17 -0600 (Fri, 12 Feb 2010) | 16 lines
lock channel during datastore removal
On channel destruction the channel's datastores are removed and
destroyed. Since there are public API calls to find and remove
datastores on a channel, a lock should be held whenever datastores are
removed and destroyed. This resolves a crash caused by a race
condition in app_chanspy.c.
(closes issue #16678)
Reported by: tim_ringenbach
Patches:
datastore_destroy_race.diff uploaded by tim ringenbach (license 540)
Tested by: dvossel
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@246548 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r239712 | dvossel | 2010-01-13 10:31:14 -0600 (Wed, 13 Jan 2010) | 24 lines
add silence gen to wait apps
asterisk.conf's 'transmit_silence' option existed before
this patch, but was limited to only generating silence
while recording and sending DTMF. Now enabling the
transmit_silence option generates silence during wait
times as well.
To achieve this, ast_safe_sleep has been modified to
generate silence anytime no other generators are present
and transmit_silence is enabled. Wait apps not using
ast_safe_sleep now generate silence when transmit_silence
is enabled as well.
(closes issue #16524)
Reported by: kobaz
(closes issue #16523)
Reported by: kobaz
Tested by: dvossel
Review: https://reviewboard.asterisk.org/r/456/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@239714 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r235660 | jpeeler | 2009-12-18 16:51:37 -0600 (Fri, 18 Dec 2009) | 55 lines
Merged revisions 235635 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r235635 | jpeeler | 2009-12-18 16:29:51 -0600 (Fri, 18 Dec 2009) | 48 lines
Correct CDR dispositions for BUSY/FAILED
This patch is simple in that it reorders the disposition defines so that the fix
for issue 12946 works properly (the default CDR disposition was changed to
AST_CDR_NOANSWER). Also, the AST_CDR_FLAG_ORIGINATED flag was set in ast_call to
ensure all CDR records are written.
The side effects of CDR changes are scary, so I'm documenting the test cases
performed to attempt to catch any regressions. The following tests were all
performed using 1.4 rev 195881 vs head (235571) + patch:
A calls B
C calls B (busy)
Hangup C
Hangup A
(Both SIP and features)
A calls B
A blind transfers to C
Hangup C
(Both SIP and features)
A calls B
A attended transfers to C
Hangup C
A calls B
A attended transfers to C (SIP)
C blind transfers to A (features)
Hangup A
All of the test scenario CDRs matched.
The following tests were performed just with the patch to ensure proper operation
(with unanswered=yes):
exten =>s,1,Answer
exten =>s,n,ResetCDR(w)
exten =>s,n,ResetCDR(w)
exten =>s,1,ResetCDR(w)
exten =>s,n,ResetCDR(w)
(closes issue #16180)
Reported by: aatef
Patches:
bug16180.patch uploaded by jpeeler (license 325)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@235663 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r233100 | russell | 2009-12-04 11:18:22 -0600 (Fri, 04 Dec 2009) | 14 lines
Merged revisions 233092 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r233092 | russell | 2009-12-04 11:12:47 -0600 (Fri, 04 Dec 2009) | 7 lines
Only do frame payload check for HOLD frames.
This code was added for helping to debug the source of invalid HOLD frames.
However, a side effect of this is that it will incorrectly report errors for
frames that have an integer payload. Make the check for this block specific
to the HOLD frame case.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@233122 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r231927 | jpeeler | 2009-12-01 15:54:21 -0600 (Tue, 01 Dec 2009) | 19 lines
Merged revisions 231911 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r231911 | jpeeler | 2009-12-01 15:29:31 -0600 (Tue, 01 Dec 2009) | 12 lines
Fix crash with invalid frame data
The crash was happening as a result of a frame containing an invalid data
pointer, but was set with data length of zero. The few times the issue was
reproduced it _seemed_ that the frame was queued properly, that is the data
pointer was set to NULL. I never could reproduce the crash so as a last resort
the crash has been fixed, but a check in __ast_read has been added to give as
much information about the source of problematic frames in the future.
(closes issue #16058)
Reported by: atis
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@231929 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r228693 | dvossel | 2009-11-06 16:35:44 -0600 (Fri, 06 Nov 2009) | 16 lines
Merged revisions 228692 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r228692 | dvossel | 2009-11-06 16:33:27 -0600 (Fri, 06 Nov 2009) | 9 lines
fixes audiohook write crash occuring in chan_spy whisper mode.
After writing to the audiohook list in ast_write(), frames
were being freed incorrectly. Under certain conditions this
resulted in a double free crash.
(closes issue #16133)
Reported by: wetwired
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@228695 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r219139 | mnicholson | 2009-09-17 10:18:01 -0500 (Thu, 17 Sep 2009) | 17 lines
Merged revisions 219136 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r219136 | mnicholson | 2009-09-17 09:58:39 -0500 (Thu, 17 Sep 2009) | 10 lines
Prevent a potential race condition and crash when hanging up a channel by removing the channel from the channel list before begining channel tear down.
This fix may potentially cause problems with CDR backends that access the channel a CDR is associated with via the channel list. This fix makes the channel unavabile at the time when the CDR backend is invoked. This has been documented in include/asterisk/cdr.h.
(closes issue #15316)
Reported by: vmarrone
Tested by: mnicholson
Review: https://reviewboard.asterisk.org/r/362/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@219199 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r214702 | tilghman | 2009-08-28 15:14:39 -0500 (Fri, 28 Aug 2009) | 15 lines
Merged revisions 214701 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r214701 | tilghman | 2009-08-28 15:13:32 -0500 (Fri, 28 Aug 2009) | 8 lines
Modify comment to be a bit more accurate.
We have kept this comment around long enough, that it's pretty clear that we're
keeping the code, because changing the code would require a pretty fundamental
architectural shift. We've also taken criticism in some quarters, because it
was believed that it was referring to the code being nasty. No, the code isn't
nasty, just the operation itself is rather odd. Fixed for eternity (probably
not).
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@214704 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r214195 | dvossel | 2009-08-26 11:38:53 -0500 (Wed, 26 Aug 2009) | 25 lines
Merged revisions 214194 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r214194 | dvossel | 2009-08-26 11:36:42 -0500 (Wed, 26 Aug 2009) | 19 lines
ast_write() ignores ast_audiohook_write() results
In ast_write(), if a channel has a list of audiohooks, those
lists are written to and the resulting frame is what ast_write()
should continue with. The problem was the returned audiohook frame
was not being handled at all, and the original frame passed
into it did not contain the mixed audio, so essentially audio
was being lost. One result of this was chan_spy's whisper
mode no longer worked. To complicate the issue, frames
passed into ast_write may either be a single frame, or a list
of frames. So, as the list of frames is processed in the
audiohook_write, the returned frames had to be added to a new
list.
(closes issue #15660)
Reported by: corruptor
Tested by: dvossel
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@214197 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r210914 | tilghman | 2009-08-06 16:46:01 -0500 (Thu, 06 Aug 2009) | 14 lines
Merged revisions 210913 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r210913 | tilghman | 2009-08-06 16:45:01 -0500 (Thu, 06 Aug 2009) | 7 lines
Because channel information can be accessed outside of the channel thread, we must lock the channel prior to modifying it.
(closes issue #15397)
Reported by: caspy
Patches:
20090714__issue15397.diff.txt uploaded by tilghman (license 14)
Tested by: caspy
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@210916 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r208464 | kpfleming | 2009-07-23 16:57:24 -0500 (Thu, 23 Jul 2009) | 46 lines
Rework of T.38 negotiation and UDPTL API to address interoperability problems
Over the past couple of months, a number of issues with Asterisk
negotiating (and successfully completing) T.38 sessions with various
endpoints have been found. This patch attempts to address many of
them, primarily focused around ensuring that the endpoints'
MaxDatagram size is honored, and in addition by ensuring that T.38
session parameter negotiation is performed correctly according to the
ITU T.38 Recommendation.
The major changes here are:
1) T.38 applications in Asterisk (app_fax) only generate/receive IFP
packets, they do not ever work with UDPTL packets. As a result of
this, they cannot be allowed to generate packets that would overflow
the other endpoints' MaxDatagram size after the UDPTL stack adds any
error correction information. With this patch, the application is told
the maximum *IFP* size it can generate, based on a calculation using
the far end MaxDatagram size and the active error correction mode on
the T.38 session. The same is true for sending *our* MaxDatagram size
to the remote endpoint; it is computed from the value that the
application says it can accept (for a single IFP packet) combined with
the active error correction mode.
2) All treatment of T.38 session parameters as 'capabilities' in
chan_sip has been removed; these parameters are not at all like
audio/video stream capabilities. There are strict rules to follow for
computing an answer to a T.38 offer, and chan_sip now follows those
rules, using the desired parameters from the application (or channel)
that wants to accept the T.38 negotiation.
3) chan_sip now stores and forwards ast_control_t38_parameters
structures for tracking 'our' and 'their' T.38 session parameters;
this greatly simplifies negotiation, especially for pass-through
calls.
4) Since T.38 negotiation without specifying parameters or receiving
the final negotiated parameters is not very worthwhile, the
AST_CONTROL_T38 control frame has been removed. A note has been added
to UPGRADE.txt about this removal, since any out-of-tree applications
that use it will no longer function properly until they are upgraded
to use AST_CONTROL_T38_PARAMETERS.
Review: https://reviewboard.asterisk.org/r/310/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@208484 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r207361 | russell | 2009-07-20 11:36:15 -0500 (Mon, 20 Jul 2009) | 16 lines
Merged revisions 207360 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r207360 | russell | 2009-07-20 11:26:24 -0500 (Mon, 20 Jul 2009) | 9 lines
Only do the chan->fdno check in ast_read() in a developer build.
I changed this check to only happen in a dev-mode build. I also added a
comment explaining what is going on. I also made it so that detection of
this situation does not affect ast_read() operation.
(closes issue #14723)
Reported by: seadweller
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@207363 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r204948 | kpfleming | 2009-07-06 08:38:29 -0500 (Mon, 06 Jul 2009) | 7 lines
Improve handling of AST_CONTROL_T38 and AST_CONTROL_T38_PARAMETERS for non-T.38-capable channels.
This change allows applications that request T.38 negotiation on a channel that
does not support it to get the proper indication that it is not supported, rather
than thinking that negotiation was started when it was not.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@204950 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r201458 | mmichelson | 2009-06-17 15:04:12 -0500 (Wed, 17 Jun 2009) | 15 lines
Merged revisions 201450 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r201450 | mmichelson | 2009-06-17 14:59:31 -0500 (Wed, 17 Jun 2009) | 9 lines
Change the datastore traversal in ast_do_masquerade to use a safe list traversal.
It is possible for datastore fixup functions to remove the datastore from the list
and free it. In particular, the queue_transfer_fixup in app_queue does this. While
I don't yet know of this causing any crashes, it certainly could.
Found while discussing a separate issue with Brian Degenhardt.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@201460 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r201056 | kpfleming | 2009-06-16 13:54:30 -0500 (Tue, 16 Jun 2009) | 18 lines
Merged revisions 200991 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r200991 | kpfleming | 2009-06-16 12:05:38 -0500 (Tue, 16 Jun 2009) | 11 lines
Improve support for media paths that can generate multiple frames at once.
There are various media paths in Asterisk (codec translators and UDPTL, primarily)
that can generate more than one frame to be generated when the application calling
them expects only a single frame. This patch addresses a number of those cases,
at least the primary ones to solve the known problems. In addition it removes the
broken TRACE_FRAMES support, fixes a number of bugs in various frame-related API
functions, and cleans up various code paths affected by these changes.
https://reviewboard.asterisk.org/r/175/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@201096 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r198856 | dvossel | 2009-06-02 16:17:49 -0500 (Tue, 02 Jun 2009) | 10 lines
Generic call forward api, ast_call_forward()
The function ast_call_forward() forwards a call to an extension specified in an ast_channel's call_forward string. After an ast_channel is called, if the channel's call_forward string is set this function can be used to forward the call to a new channel and terminate the original one. I have included this api call in both channel.c's ast_request_and_dial() and feature.c's feature_request_and_dial(). App_dial and app_queue already contain call forward logic specific for their application and options.
(closes issue #13630)
Reported by: festr
Review: https://reviewboard.asterisk.org/r/271/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@198887 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r198072 | mnicholson | 2009-05-29 14:04:24 -0500 (Fri, 29 May 2009) | 21 lines
Merged revisions 198068 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r198068 | mnicholson | 2009-05-29 13:53:01 -0500 (Fri, 29 May 2009) | 15 lines
Use AST_CDR_NOANSWER instead of AST_CDR_NULL as the default CDR disposition.
This change also involves the addition of an AST_CDR_FLAG_ORIGINATED flag that is used on originated channels to distinguish: them from dialed channels.
(closes issue #12946)
Reported by: meral
Patches:
null-cdr2.diff uploaded by mnicholson (license 96)
Tested by: mnicholson, dbrooks
(closes issue #15122)
Reported by: sum
Tested by: sum
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@198074 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The bridge was terminating immediately after the attended transfer was
completed. The problem was because upon reentering ast_channel_bridge
nexteventts was checked to see if it was set and if so could possibly
return AST_BRIDGE_COMPLETE.
(closes issue #15183)
Reported by: andrebarbosa
Tested by: andrebarbosa, tootai, loloski
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@197145 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r194357 | mmichelson | 2009-05-13 14:42:51 -0500 (Wed, 13 May 2009) | 18 lines
Blocked revisions 194356 via svnmerge
........
r194356 | mmichelson | 2009-05-13 14:41:44 -0500 (Wed, 13 May 2009) | 13 lines
Remove an extraneous unlocking operation from ast_channel_free.
In the case that we could not remove the desired channel from the
list of channels, there was an extra call to unlock the channel list.
Since we unlock the list later on in the function anyway, this results
in the list being unlocked twice yet only being locked once.
(closes issue #15098)
Reported by: tim_ringenbach
Patches:
remove_extra_unlock.diff uploaded by tim (license 540)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@194359 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r192318 | kpfleming | 2009-05-05 12:34:19 +0200 (Tue, 05 May 2009) | 5 lines
Properly account for memory allocated for channels and datastores
As in previous commits, when channels are allocated (with ast_channel_alloc) or datastores are allocated (with ast_datastore_alloc) properly account for the memory being owned by the caller, instead of the allocator function itself.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@192354 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r191489 | jpeeler | 2009-05-01 13:09:23 -0500 (Fri, 01 May 2009) | 15 lines
Merged revisions 191488 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r191488 | jpeeler | 2009-05-01 12:40:46 -0500 (Fri, 01 May 2009) | 9 lines
Fix DTMF not being sent to other side after a partial feature match
This fixes a regression from commit 176701. The issue was that
ast_generic_bridge never exited after the feature digit timeout had elapsed,
which prevented the queued DTMF from being sent to the other side.
This issue was reported to me directly.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@191505 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r186985 | mmichelson | 2009-04-08 10:27:41 -0500 (Wed, 08 Apr 2009) | 30 lines
Merged revisions 186984 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r186984 | mmichelson | 2009-04-08 10:26:46 -0500 (Wed, 08 Apr 2009) | 24 lines
Make a couple of changes with regards to a new message printed in ast_read().
"ast_read() called with no recorded file descriptor" is a new message added
after a bug was discovered. Unfortunately, it seems there are a bunch of places
that potentially make such calls to ast_read() and trigger this error message
to be displayed. This commit does two things to help to make this message appear
less.
First, the message has been downgraded to a debug level message if dev mode is
not enabled. The message means a lot more to developers than it does to end users,
and so developers should take an effort to be sure to call ast_read only when
a channel is ready to be read from. However, since this doesn't actually cause an
error in operation and is not something a user can easily fix, we should not spam
their console with these messages.
Second, the message has been moved to after the check for any pending masquerades.
ast_read() being called with no recorded file descriptor should not interfere with
a masquerade taking place.
This could be seen as a simple way of resolving issue #14723. However, I still want
to try to clear out the existing ways of triggering this message, since I feel that
would be a better resolution for the issue.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@186987 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r186833 | mmichelson | 2009-04-07 18:50:56 -0500 (Tue, 07 Apr 2009) | 15 lines
Merged revisions 186832 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r186832 | mmichelson | 2009-04-07 18:49:49 -0500 (Tue, 07 Apr 2009) | 8 lines
Set the AST_FEATURE_WARNING_ACTIVE flag when a p2p bridge returns AST_BRIDGE_RETRY.
Without this flag set, warning sounds will not be properly played to either party
of the bridge.
(closes issue #14845)
Reported by: adomjan
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@186835 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r185772 | russell | 2009-04-01 08:48:26 -0500 (Wed, 01 Apr 2009) | 14 lines
Merged revisions 185771 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r185771 | russell | 2009-04-01 08:47:30 -0500 (Wed, 01 Apr 2009) | 6 lines
Fix a case where DTMF could bypass audiohooks.
This change fixes a situation where an audiohook that wants DTMF would not
actually get it. This is in the code path where we end DTMF digit length
emulation while handling a NULL frame.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@185774 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r184762 | kpfleming | 2009-03-27 14:10:32 -0500 (Fri, 27 Mar 2009) | 12 lines
Improve timing interface to remember which provider provided a timer
The ability to load/unload timing interfaces is nice, but it means that when a timer is allocated, it may come from provider A, but later provider B becomes the 'preferred' provider. If this happens, all timer API calls on the timer that was provided by provider A will actually be handed to provider B, which will say WTF and return an error.
This patch changes the timer API to include a pointer to the provider of the timer handle so that future operations on the timer will be forwarded to the proper provider.
(closes issue #14697)
Reported by: moy
Review: http://reviewboard.digium.com/r/211/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@184765 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r183057 | file | 2009-03-18 19:22:56 -0300 (Wed, 18 Mar 2009) | 6 lines
Fix an issue where a T38 control frame would get dropped.
If two channels were bridged together using a generic bridge the T38
control frame would get passed up instead of being indicated on the
other channel.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@183067 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r182847 | russell | 2009-03-17 21:28:55 -0500 (Tue, 17 Mar 2009) | 52 lines
Merged revisions 182810 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r182810 | russell | 2009-03-17 21:09:13 -0500 (Tue, 17 Mar 2009) | 44 lines
Fix cases where the internal poll() was not being used when it needed to be.
We have seen a number of problems caused by poll() not working properly on
Mac OSX. If you search around, you'll find a number of references to using
select() instead of poll() to work around these issues. In Asterisk, we've
had poll.c which implements poll() using select() internally. However, we
were still getting reports of problems.
vadim investigated a bit and realized that at least on his system, even
though we were compiling in poll.o, the system poll() was still being used.
So, the primary purpose of this patch is to ensure that we're using the
internal poll() when we want it to be used.
The changes are:
1) Remove logic for when internal poll should be used from the Makefile.
Instead, put it in the configure script. The logic in the configure
script is the same as it was in the Makefile. Ideally, we would have
a functionality test for the problem, but that's not actually possible,
since we would have to be able to run an application on the _target_
system to test poll() behavior.
2) Always include poll.o in the build, but it will be empty if AST_POLL_COMPAT
is not defined.
3) Change uses of poll() throughout the source tree to ast_poll(). I feel
that it is good practice to give the API call a new name when we are
changing its behavior and not using the system version directly in all cases.
So, normally, ast_poll() is just redefined to poll(). On systems where
AST_POLL_COMPAT is defined, ast_poll() is redefined to ast_internal_poll().
4) Change poll() in main/poll.c to be ast_internal_poll().
It's worth noting that any code that still uses poll() directly will work fine
(if they worked fine before). So, for example, out of tree modules that are
using poll() will not stop working or anything. However, for modules to work
properly on Mac OSX, ast_poll() needs to be used.
(closes issue #13404)
Reported by: agalbraith
Tested by: russell, vadim
http://reviewboard.digium.com/r/198/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@182946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r182553 | russell | 2009-03-17 10:22:12 -0500 (Tue, 17 Mar 2009) | 5 lines
Tweak the handling of the frame list inside of ast_answer().
This does not change any behavior, but moves the frames from the local frame
list back to the channel read queue using an O(n) algorithm instead of O(n^2).
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@182570 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r182525 | kpfleming | 2009-03-17 09:38:11 -0500 (Tue, 17 Mar 2009) | 11 lines
Improve behavior of ast_answer() to not lose incoming frames
ast_answer(), when supplied a delay before returning to the caller, use ast_safe_sleep() to implement the delay. Unfortunately during this time any incoming frames are discarded, which is problematic for T.38 re-INVITES and other sorts of channel operations.
When a delay is not passed to ast_answer(), it still delays for up to 500 milliseconds, waiting for media to arrive. Again, though, it discards any control frames, or non-voice media frames.
This patch rectifies this situation, by storing all incoming frames during the delay period on a list, and then requeuing them onto the channel before returning to the caller.
http://reviewboard.digium.com/r/196/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@182527 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r182171 | file | 2009-03-16 10:58:24 -0300 (Mon, 16 Mar 2009) | 7 lines
Fix a memory leak in the ast_answer / __ast_answer API call.
For a channel that is not yet answered this API call will wait
until a voice frame is received on the channel before returning.
It does this by waiting for frames on the channel and reading them
in. The frames read in were not freed when they should have been.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@182173 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r181424 | russell | 2009-03-11 16:49:29 -0500 (Wed, 11 Mar 2009) | 17 lines
Merged revisions 181423 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r181423 | russell | 2009-03-11 16:42:58 -0500 (Wed, 11 Mar 2009) | 9 lines
Make code that updates BRIDGEPEER variable thread-safe.
It is not safe to read the name field of an ast_channel without the channel
locked. This patch fixes some places in channel.c where this was being done,
and lead to crashes related to masquerades.
(closes issue #14623)
Reported by: guillecabeza
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@181426 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r180032 | dvossel | 2009-03-03 17:21:18 -0600 (Tue, 03 Mar 2009) | 14 lines
app_read does not break from prompt loop with user terminated empty string
In app.c, ast_app_getdata is called to stream the prompts and receive DTMF input. If ast_app_getdata() receives an empty string caused by the user inputing the end of string character, in this case '#', it should break from the prompt loop and return to app_read, but instead it cycles through all the prompts. I've added a return value for this special case in ast_readstring() which uses an enum I've delcared in apps.h. This enum is now used as a return value for ast_app_getdata().
(closes issue #14279)
Reported by: Marquis
Patches:
fix_app_read.patch uploaded by Marquis (license 32)
read-ampersanmd.patch2 uploaded by dvossel (license 671)
Tested by: Marquis, dvossel
Review: http://reviewboard.digium.com/r/177/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@180080 65c4cc65-6c06-0410-ace0-fbb531ad65f3
