https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r282430 | twilson | 2010-08-16 12:06:37 -0500 (Mon, 16 Aug 2010) | 16 lines
Send a SRCCHANGE indication when we masquerade
Masquerading a channel means that the src of the audio is potentially
changing, so send a SRCCHANGE so that RTP-based media streams can get
a new SSRC generated to reflect the change. Original patch by addix
(along with lots of testing--thanks!).
(closes issue #17007)
Reported by: addix
Patches:
1001-reset-SSRC-original-channel.diff uploaded by addix (license 1006)
srcchange.diff uploaded by twilson (license 396)
Tested by: addix, twilson
Review: https://reviewboard.asterisk.org/r/862/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@282467 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r281911 | jpeeler | 2010-08-11 22:00:14 -0500 (Wed, 11 Aug 2010) | 20 lines
Ensure SSRC is changed when media source is changed to resolve audio delay.
This change causes the SSRC to change right before the channels are bridged,
which is what used to happen. It seems that fixes were made to attempt limiting
SSRC changes, targeted mainly at sending DTMF. DTMF is not affecting the SSRC
with this change.
There are two other control frames sent in ast_channel_bridge that probably
should also be changed to AST_CONTROL_SRCCHANGE as well, but I'm going to leave
this change up to the discretion of resolving issue #17007.
For reference - old review implementing new control frame SRCCHANGE:
https://reviewboard.asterisk.org/r/540
(closes issue #17404)
Reported by: sdolloff
Patches:
bug17404.patch uploaded by jpeeler (license 325)
Tested by: sdolloff
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@281912 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Instead, only calculate the time threshold each time ast_sched_runq() is called.
(closes issue #17742)
Reported by: schmidts
Patches:
sched.c.patch uploaded by schmidts (license 1077)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@281574 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The default values would differ depending on whether or not cdr.conf exists.
That is no longer the case.
Apply a default value to the unanswered option.
Define all default values as named constants.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@281051 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r280448 | dvossel | 2010-07-29 14:04:23 -0500 (Thu, 29 Jul 2010) | 12 lines
fixes issue with translator frame not getting freed
A translator frame even if it local storage so the translation path
can be freed. This issue prevented g729 licenses from being freed up.
(closes issue #17630)
Reported by: manvirr
Patches:
encoder_fix.diff uploaded by dvossel (license 671)
Tested by: manvirr, dvossel
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@280449 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r279945 | dvossel | 2010-07-27 15:33:40 -0500 (Tue, 27 Jul 2010) | 19 lines
remove empty audiohook write list on channel
If a channel has an audiohook write list created on it, that
list stays on the channel until the channel is destroyed. There
is no reason to keep that list on the channel if it becomes empty.
If it is empty that just means we are doing needless translating
for every ast_read and ast_write. This patch removes the audiohook
list from the channel once it is detected to be empty on either a
read or write. If a audiohook is added back to the channel after
this list is destroyed, the list just gets recreated as if it never
existed to begin with.
(closes issue #17630)
Reported by: manvirr
Review: https://reviewboard.asterisk.org/r/799/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@279946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r278708 | jpeeler | 2010-07-22 14:45:30 -0500 (Thu, 22 Jul 2010) | 16 lines
Add method for finding XML doc files for systems that don't support GLOB_BRACE.
In particular, Solaris and perhaps others do not support the above mentioned
GNU extension. In this case the paths are simply expanded without the braces
and the calls to glob are made separately.
Note: I could not explain memory allocation failures that were being reported
from within libxml itself when making calls to glob without using GLOB_NOCHECK.
This is the only reason why that flag is being used.
(closes issue #15402)
Reported by: snuffy
Patches:
bug_xmlpatt-v3.diff uploaded by snuffy (license 35),
modified by me
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@278709 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r278620 | mmichelson | 2010-07-22 09:58:01 -0500 (Thu, 22 Jul 2010) | 19 lines
Merged revisions 278618 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r278618 | mmichelson | 2010-07-22 09:55:04 -0500 (Thu, 22 Jul 2010) | 13 lines
Allow PLC to function properly when channels use SLIN for audio.
If a channel involved in a bridge was using SLIN audio, then translation
paths were not guaranteed to be set up properly since in all likelihood
the number of translation steps was only 1.
This patch enforces the transcode_via_slin behavior if transcode_via_slin
or generic_plc is enabled and one of the formats to make compatible is
SLIN.
AST-352
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@278621 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r277945 | jeang | 2010-07-19 16:07:08 -0500 (Mon, 19 Jul 2010) | 15 lines
Merged revisions 277906 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r277906 | jeang | 2010-07-19 15:16:36 -0500 (Mon, 19 Jul 2010) | 7 lines
Avoid trying to pickup a parked extension before the park operation is completed.
A crash could occur if the extension is picked up while the parking extension is
being announced. Testing pu->notquiteyet while searching for a parked extension
resolves this crash.
(ABE-2418)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@277966 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r277657 | tringenbach | 2010-07-16 18:23:15 -0500 (Fri, 16 Jul 2010) | 16 lines
Merged revisions 277625 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r277625 | tringenbach | 2010-07-16 17:43:39 -0500 (Fri, 16 Jul 2010) | 9 lines
Save and restore AST_FLAG_BRIDGE_HANGUP_DONT on attended transfer.
ast_bridge_call() clears AST_FLAG_BRIDGE_HANGUP_DONT. But during an attended
transfer, ast_bridge_call() is called for a second bridge on the same channel,
and it clears that flag, which still needs to get set for when the original
ast_bridge_call() gets control back and checks it.
Review: https://reviewboard.asterisk.org/r/741
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@277666 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r277250 | mnicholson | 2010-07-16 12:30:39 -0500 (Fri, 16 Jul 2010) | 11 lines
Merged revisions 277247 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r277247 | mnicholson | 2010-07-16 12:29:57 -0500 (Fri, 16 Jul 2010) | 4 lines
For pass through DTMF tones, measure the actual duration between the begin and end packets on the wire. If it is detected to be less than AST_MIN_DTMF_DURATION, trigger dtmf emulation.
AST-362
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@277256 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r275995 | russell | 2010-07-13 11:53:44 -0500 (Tue, 13 Jul 2010) | 21 lines
Merged revisions 275994 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r275994 | russell | 2010-07-13 11:51:18 -0500 (Tue, 13 Jul 2010) | 14 lines
Access peer->cdr directly instead of through a saved off reference.
At this point in the code, it is possible that peer_cdr may be invalid.
Specifically, in the blind transfer code, CDRs are swapped between channels.
So, peer_cdr is no longer == peer->cdr.
The scenario that exposed a crash in this code was a blind transfer that hit
the system call limit, causing the transferee channel to get destroyed after
the transfer attempt failed. Even if it succeeds and this code doesn't crash,
this code was still trying to reset a CDR on a channel that was now owned by
a different thread, which is a BadThing(tm).
(ABE-2417)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@275996 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r275682 | jpeeler | 2010-07-12 12:21:01 -0500 (Mon, 12 Jul 2010) | 18 lines
Merged revisions 275665 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r275665 | jpeeler | 2010-07-12 11:58:39 -0500 (Mon, 12 Jul 2010) | 11 lines
Change ast_write to not stop generator when called from ast_prod.
For SIP channels configured with the progressinband option on, the ringback was
being immediately stopped. This problem was due to ast_prod being moved for a
deadlock fix in 259858. Prodding the channel after setting up the generator
triggered the check in ast_write to stop the generator. The fix here should
write the frame the same as was done before the call to ast_prod was moved.
(closes issue #17372)
Reported by: tech_admin
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@275706 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r275424 | russell | 2010-07-09 16:57:21 -0500 (Fri, 09 Jul 2010) | 27 lines
Fix some issues related to dynamic feature groups in features.conf.
The bridge handling code did not properly consider feature groups when setting
parameters that would affect whether or not a native bridge would be attempted.
If DYNAMIC_FEATURES only include a feature group, a native bridge would occur
that may prevent features from working.
Fix a bug in verbose output that would show the key mapping as empty if it was
using the default mapping and not a custom mapping in the feature group.
Add feature groups to the output of "features show".
Adjust the feature execution logic to match that of the logic when executing
a feature that was not configured through a feature group.
Update features.conf.sample to show that an '=' is still required if using
the default key mapping from [applicationmap].
Finally, clean up a little bit of formatting to better coform to coding
guidelines while in the area.
(closes issue #17589)
Reported by: lmadsen
Patches:
issue_17589.rev4.txt uploaded by russell (license 2)
Tested by: russell, lmadsen
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@275425 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r274164 | mmichelson | 2010-07-06 09:31:13 -0500 (Tue, 06 Jul 2010) | 22 lines
Merged revisions 274157 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r274157 | mmichelson | 2010-07-06 09:29:23 -0500 (Tue, 06 Jul 2010) | 16 lines
Fix problem with RFC 2833 DTMF not being accepted.
A recent check was added to ensure that we did not erroneously
detect duplicate DTMF when we received packets out of order.
The problem was that the check did not account for the fact that
the seqno of an RTP stream will roll over back to 0 after hitting
65535. Now, we have a secondary check that will ensure that the
seqno rolling over will not cause us to stop accepting DTMF.
(closes issue #17571)
Reported by: mdeneen
Patches:
rtp_seqno_rollover.patch uploaded by mmichelson (license 60)
Tested by: richardf, maxochoa, JJCinAZ
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@274168 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r273054 | tilghman | 2010-06-29 17:39:22 -0500 (Tue, 29 Jun 2010) | 11 lines
Send DialPlanComplete as a response, not as a separate event.
Otherwise, it goes to all manager sessions and may exclude the current session,
if the Events mask excludes it.
(closes issue #17504)
Reported by: rrb3942
Patches:
showdialplan_patch.diff uploaded by rrb3942 (license 1003)
Tested by: rrb3942
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@273056 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r271831 | dvossel | 2010-06-22 10:46:22 -0500 (Tue, 22 Jun 2010) | 10 lines
fixes attended transfer behavior when both transferee and transferer hung up
If both the transferer and transferee of a attended transfer hangup before
the new channel picks up, the new channel should be hung up as well as it
has no endpoint to talk to. This mirrors the expected behavior used in 1.4.
(closes issue #17444)
Reported by: corruptor
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@271832 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r269822 | mmichelson | 2010-06-10 14:34:03 -0500 (Thu, 10 Jun 2010) | 25 lines
Merged revisions 269821 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r269821 | mmichelson | 2010-06-10 14:30:12 -0500 (Thu, 10 Jun 2010) | 19 lines
Fix potential crash when writing raw SLIN audio on a PLC-enabled channel.
The issue here was that the frame created when adjusting for PLC had no offset
to its audio data. If this frame were translated to another format prior to
being sent out an RTP socket, all went well because the translation code would
put an appropriate offset into the frame. However, if the SLIN audio were not
translated before being sent out the RTP socket, bad things would happen.
Specifically, the ast_rtp_raw_write makes the assumption that the frame has
at least enough of an offset that it can accommodate an RTP header. This was
not the case. As such, data was being written prior to the allocation, likely
corrupting the data the memory allocator had written. Thus when the time came
to free the data, all hell broke loose. ....Well, Asterisk crashed at least.
The fix was just what one would expect. Offset the data in the frame by a reasonable
amount. The method I used is a bit odd since the data in the frame is 16 bit integers
and not bytes. I left a big ol' comment about it. This can be improved on if someone
is interested. I was more interested in getting the crash resolved.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@269823 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r269417 | russell | 2010-06-09 16:11:43 -0500 (Wed, 09 Jun 2010) | 6 lines
Resolve an invalid memory read on an event.
Valgrind pointed out that attempting to get an IE value from an event that has
no IEs produces an invalid memory read past the end of the event. Thanks to
mmichelson for pointing the problem out to me and then testing the fix.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@269418 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r269346 | pabelanger | 2010-06-09 13:32:52 -0400 (Wed, 09 Jun 2010) | 19 lines
Merged revisions 269334 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r269334 | pabelanger | 2010-06-09 13:24:53 -0400 (Wed, 09 Jun 2010) | 12 lines
Fix Debian init script to not use -c.
When using the init script as-is currently, it could cause issues on Debian
such as high CPU usage. This fix has worked for several people so I'm
implementing the change. We now handle color displays properly.
(closes issue #16784)
Reported by: pabelanger
Patches:
20100530__issue16784__2.diff.txt uploaded by tilghman (license 14)
Tested by: pabelanger, tilghman
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@269347 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r268456 | tilghman | 2010-06-05 12:55:28 -0500 (Sat, 05 Jun 2010) | 14 lines
Fix crash in DTMF detection.
What I did not originally see in my previous commit was that even though the
next digit could be detected before the previous was considered ended, the
detection of the next digit effectively ends the detection of the previous.
Therefore, the length moves in lockstep with the digit, and no separate counter
is needed for the length alone.
(closes issue #17371)
Reported by: alecdavis
(closes issue #17474)
Reported by: kenner
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@268457 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r267303 | russell | 2010-06-02 16:41:54 -0500 (Wed, 02 Jun 2010) | 6 lines
Ensure the -Wno-strict-aliasing flag makes it, even if ASTCFLAGS has been specified.
When ASTCFLAGS was specified with the make command, Makefile.rules was using
the specified value from the command line and not the one here, making it so this
flag would go missing.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@267304 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r266682 | tilghman | 2010-06-01 11:41:00 -0500 (Tue, 01 Jun 2010) | 16 lines
Eliminate stale manager events after a set interval, even if AMI clients don't query for them.
Actions (or failures to act) by external clients should not cause memory leaks
in Asterisk, especially when those continued leaks could cause Asterisk to
misbehave later.
(closes issue #17234)
Reported by: mav3rick
Patches:
20100510__issue17234.diff.txt uploaded by tilghman (license 14)
20100517__issue17234__trunk.diff.txt uploaded by tilghman (license 14)
Tested by: mav3rick, davidw
(closes issue #17365)
Reported by: davidw
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@266683 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r266592 | tilghman | 2010-06-01 10:18:59 -0500 (Tue, 01 Jun 2010) | 18 lines
Merged revisions 266585 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r266585 | tilghman | 2010-06-01 10:17:46 -0500 (Tue, 01 Jun 2010) | 11 lines
Prevent CLI prompt from distorting output of lines shorter than the prompt.
Uses the VT100 method of clearing the line from the cursor position to the
end of the line: Esc-0K
(closes issue #17160)
Reported by: coolmig
Patches:
20100531__issue17160.diff.txt uploaded by tilghman (license 14)
Tested by: coolmig
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@266598 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r266146 | tilghman | 2010-05-26 16:17:46 -0500 (Wed, 26 May 2010) | 21 lines
Merged revisions 266142 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r266142 | tilghman | 2010-05-26 16:11:44 -0500 (Wed, 26 May 2010) | 14 lines
Use sigaction for signals which should persist past the initial trigger, not signal.
If you call signal() in a Solaris signal handler, instead of just resetting
the signal handler, it causes the signal to refire, because the signal is not
marked as handled prior to the signal handler being called. This effectively
causes Solaris to immediately exceed the threadstack in recursive signal
handlers and crash.
(closes issue #17000)
Reported by: rmcgilvr
Patches:
20100526__issue17000.diff.txt uploaded by tilghman (license 14)
Tested by: rmcgilvr
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@266154 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r265320 | twilson | 2010-05-24 14:06:40 -0500 (Mon, 24 May 2010) | 14 lines
Add the FullyBooted AMI event
It is possible to connect to the manager interface before all Asterisk modules
are loaded. To ensure that an application does not send AMI actions that might
require a module that has not yet loaded, the application can listen for the
FullyBooted manager event. It will be sent upon connection if all modules have
been loaded, or as soon as loading is complete. The event:
Event: FullyBooted
Privilege: system,all
Status: Fully Booted
Review: https://reviewboard.asterisk.org/r/639/
........
r265467 | twilson | 2010-05-24 17:21:58 -0500 (Mon, 24 May 2010) | 1 line
Merge the rest of the FullyBooted patch
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@265521 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r264997 | mmichelson | 2010-05-21 11:44:27 -0500 (Fri, 21 May 2010) | 38 lines
Merged revisions 264996 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r264996 | mmichelson | 2010-05-21 11:28:34 -0500 (Fri, 21 May 2010) | 32 lines
Allow ast_safe_sleep to defer specific frames until after the sleep has concluded.
From reviewboard
Background:
A Digium customer discovered a somewhat odd bug. The setup is that parties A
and B are bridged, and party A places party B on hold. While party B is
listening to hold music, he mashes a bunch of DTMF. Party A takes party
B off hold while this is happening, but party B continues to hear hold
music. I could reproduce this about 1 in 5 times.
The issue:
When DTMF features are enabled and a user presses keys, the channel that
the DTMF is streamed to is placed in an ast_safe_sleep for 100 ms, the
duration of the emulated tone. If an AST_CONTROL_UNHOLD frame is read
from the channel during the sleep, the frame is dropped. Thus the
unhold indication is never made to the channel that was originally placed
on hold.
The fix:
Originally, I discussed with Kevin possible ways of fixing the specific
problem reported. However, we determined that the same type of problem
could happen in other situations where ast_safe_sleep() is used. Using
autoservice as a model, I modified ast_safe_sleep_conditional() to
defer specific frame types so they can be re-queued once the sleep has
finished. I made a common function for determining if a frame should
be deferred so that there are not two identical switch blocks to
maintain.
Review: https://reviewboard.asterisk.org/r/674/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@264998 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r264828 | rmudgett | 2010-05-20 18:29:43 -0500 (Thu, 20 May 2010) | 13 lines
Merged revisions 264820 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r264820 | rmudgett | 2010-05-20 18:23:21 -0500 (Thu, 20 May 2010) | 6 lines
ast_callerid_parse() had a path that left name uninitialized.
Several callers of ast_callerid_parse() do not initialize the name
parameter before calling thus there is the potential to use an
uninitialized pointer.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@264829 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r264452 | mmichelson | 2010-05-19 16:29:08 -0500 (Wed, 19 May 2010) | 86 lines
Fix transcode_via_sln option with SIP calls and improve PLC usage.
From reviewboard:
The problem here is a bit complex, so try to bear with me...
It was noticed by a Digium customer that generic PLC (as configured in
codecs.conf) did not appear to actually be having any sort of benefit when
packet loss was introduced on an RTP stream. I reproduced this issue myself
by streaming a file across an RTP stream and dropping approx. 5% of the
RTP packets. I saw no real difference between when PLC was enabled or disabled
when using wireshark to analyze the RTP streams.
After analyzing what was going on, it became clear that one of the problems
faced was that when running my tests, the translation paths were being set
up in such a way that PLC could not possibly work as expected. To illustrate,
if packets are lost on channel A's read stream, then we expect that PLC will
be applied to channel B's write stream. The problem is that generic PLC can
only be done when there is a translation path that moves from some codec to
SLINEAR. When I would run my tests, I found that every single time, read
and write translation paths would be set up on channel A instead of channel
B. There appeared to be no real way to predict which channel the translation
paths would be set up on.
This is where Kevin swooped in to let me know about the transcode_via_sln
option in asterisk.conf. It is supposed to work by placing a read translation
path on both channels from the channel's rawreadformat to SLINEAR. It also
will place a write translation path on both channels from SLINEAR to the
channel's rawwriteformat. Using this option allows one to predictably set up
translation paths on all channels. There are two problems with this, though.
First and foremost, the transcode_via_sln option did not appear to be working
properly when I was placing a SIP call between two endpoints which did not
share any common formats. Second, even if this option were to work, for PLC
to be applied, there had to be a write translation path that would go from
some format to SLINEAR. It would not work properly if the starting format
of translation was SLINEAR.
The one-line change presented in this review request in chan_sip.c fixed the
first issue for me. The problem was that in sip_request_call, the
jointcapability of the outbound channel was being set to the format passed to
sip_request_call. This is nativeformats of the inbound channel. Because of this,
when ast_channel_make_compatible was called by app_dial, both channels already
had compatibly read and write formats. Thus, no translation path was set up at
the time. My change is to set the jointcapability of the sip_pvt created during
sip_request_call to the intersection of the inbound channel's nativeformats and
the configured peer capability that we determined during the earlier call to
create_addr. Doing this got the translation paths set up as expected when using
transcode_via_sln.
The changes presented in channel.c fixed the second issue for me. First and
foremost, when Asterisk is started, we'll read codecs.conf to see the value of
the genericplc option. If this option is set, and ast_write is called for a
frame with no data, then we will attempt to fill in the missing samples for
the frame. The implementation uses a channel datastore for maintaining the
PLC state and for creating a buffer to store PLC samples in. Even when we
receive a frame with data, we'll call plc_rx so that the PLC state will have
knowledge of the previous voice frame, which it can use as a basis for when
it comes time to actually do a PLC fill-in.
So, reviewers, now I ask for your help. First off, there's the one line change
in chan_sip that I have put in. Is it right? By my logic it seems correct, but
I'm sure someone can tell me why it is not going to work. This is probably the
change I'm least concerned about, though. What concerns me much more is the
set of changes in channel.c. First off, am I even doing it right? When I run
tests, I can clearly see that when PLC is activated, I see a significant increase
in RTP traffic where I would expect it to be. However, in my humble opinion, the
audio sounds kind of crappy whenever the PLC fill-in is done. It sounds worse to
me than when no PLC is used at all. I need someone to review the logic I have used
to be sure that I'm not misusing anything. As far as I can see my pointer arithmetic
is correct, and my use of AST_FRIENDLY_OFFSET should be correct as well, but I'm
sure someone can point out somewhere where I've done something incorrectly.
As I was writing this review request up, I decided to give the code a test run under
valgrind, and I find that for some reason, calls to plc_rx are causing some invalid
reads. Apparently I'm reading past the end of a buffer somehow. I'll have to dig around
a bit to see why that is the case. If it's obvious to someone reviewing, speak up!
Finally, I have one other proposal that is not reflected in my code review. Since
without transcode_via_sln set, one cannot predict or control where a translation
path will be up, it seems to me that the current practice of using PLC only when
transcoding to SLINEAR is not useful. I recommend that once it has been determined
that the method used in this code review is correct and works as expected, then
the code in translate.c that invokes PLC should be removed.
Review: https://reviewboard.asterisk.org/r/622/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@264453 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r264400 | dvossel | 2010-05-19 15:30:33 -0500 (Wed, 19 May 2010) | 11 lines
fixes infinite loop during udptl.c's decode_open_type
When decode_length returns the length there is a check to see if that
length is negative, if so the decode loop breaks as this means the
limit has been reached. The problem here is that length is an
unsigned int, so length can never be negative. This resulted in
an infinite loop.
(issue #17352)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@264405 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r264114 | dvossel | 2010-05-19 09:38:02 -0500 (Wed, 19 May 2010) | 13 lines
fixes crash during dtmf
During the processing of Cisco dtmf the dtmf samples were
not being calculated correctly. In an attempt to determine
what sample rate was being used, a NULL frame was processed
which caused a crash. This patch resolves this.
(closes issue #17248)
Reported by: falves11
Patches:
issue_17248.diff uploaded by dvossel (license 671)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@264115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r263640 | mmichelson | 2010-05-17 17:08:01 -0500 (Mon, 17 May 2010) | 16 lines
Merged revisions 263639 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r263639 | mmichelson | 2010-05-17 17:00:28 -0500 (Mon, 17 May 2010) | 10 lines
Fix logic error when checking for a devstate provider.
When using strsep, if one of the list of specified separators is not found,
it is the first parameter to strsep which is now NULL, not the pointer returned
by strsep.
This issue isn't especially severe in that the worst it is likely to do is waste
some cycles when a device with no '/' and no ':' is passed to ast_device_state.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@263642 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r263457 | lmadsen | 2010-05-17 09:37:35 -0500 (Mon, 17 May 2010) | 19 lines
Recorded merge of revisions 263456 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r263456 | lmadsen | 2010-05-17 09:35:18 -0500 (Mon, 17 May 2010) | 11 lines
Manager cookies are not compatible with RFC2109.
The Version field in the cookies we're setting contain quotes around the version
number which is not compatible with RFC2109 and breaks some implementations.
(closes issue #17231)
Reported by: ecarruda
Patches:
manager_rfc2109-trunk-v1.patch uploaded by ecarruda (license 559)
manager_rfc2109-1.6.2-v1.patch uploaded by ecarruda (license 559)
Tested by: ecarruda, russell
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@263458 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r261496 | russell | 2010-05-06 08:58:07 -0500 (Thu, 06 May 2010) | 40 lines
Fix handling of removing nodes from the middle of a heap.
This bug surfaced in 1.6.2 and does not affect code in any other released
version of Asterisk. It manifested itself as SIP qualify not happening when
it should, causing peers to go unreachable. This was debugged down to scheduler
entries sometimes not getting executed when they were supposed to, which was in
turn caused by an error in the heap code.
The problem only sometimes occurs, and it is due to the logic for removing an entry
in the heap from an arbitrary location (not just popping off the top). The scheduler
performs this operation frequently when entries are removed before they run (when
ast_sched_del() is used).
In a normal pop off of the top of the heap, a node is taken off the bottom,
placed at the top, and then bubbled down until the max heap property is restored
(see max_heapify()). This same logic was used for removing an arbitrary node
from the middle of the heap. Unfortunately, that logic is full of fail. This
patch fixes that by fully restoring the max heap property when a node is thrown
into the middle of the heap. Instead of just pushing it down as appropriate, it
first pushes it up as high as it will go, and _then_ pushes it down.
Lastly, fix a minor problem in ast_heap_verify(), which is only used for
debugging. If a parent and child node have the same value, that is not an
error. The only error is if a parent's value is less than its children.
A huge thanks goes out to cappucinoking for debugging this down to the scheduler,
and then producing an ast_heap test case that demonstrated the breakage. That
made it very easy for me to focus on the heap logic and produce a fix. Open source
projects are awesome.
(closes issue #16936)
Reported by: ib2
Tested by: cappucinoking, crjw
(closes issue #17277)
Reported by: cappucinoking
Patches:
heap-fix.rev2.diff uploaded by russell (license 2)
Tested by: cappucinoking, russell
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@261498 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r261095 | tilghman | 2010-05-04 18:51:52 -0500 (Tue, 04 May 2010) | 18 lines
Merged revisions 261093-261094 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r261093 | tilghman | 2010-05-04 18:36:53 -0500 (Tue, 04 May 2010) | 7 lines
Protect against overflow, when calculating how long to wait for a frame.
(closes issue #17128)
Reported by: under
Patches:
d.diff uploaded by under (license 914)
........
r261094 | tilghman | 2010-05-04 18:47:08 -0500 (Tue, 04 May 2010) | 2 lines
Add a tiny corner case to the previous commit
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@261098 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r254450 | kpfleming | 2010-03-25 10:27:31 -0500 (Thu, 25 Mar 2010) | 49 lines
Improve handling of T.38 re-INVITEs that arrive before a T.38-capable
application is executing on a channel.
This patch addresses an issue found during working with end-users
using res_fax. If an incoming call is answered in the dialplan, or
jumps to the 'fax' extension due to reception of a CNG tone (with
faxdetect enabled), and then the remote endpoint sends a T.38
re-INVITE, it is possible for the channel's T.38 state to be
'T38_STATE_NEGOTIATING' when the application starts up. Unfortunately,
even if the application wants to use T.38, it can't respond to the
peer's negotiation request, because the AST_CONTROL_T38_PARAMETERS
control frame that chan_sip sent originally has been lost, and the
application needs the content of that frame to be able to formulate a
reply.
This patch adds a new 'request' type to AST_CONTROL_T38_PARAMETERS,
AST_T38_REQUEST_PARMS. If the application sends this request, chan_sip
will re-send the original control frame (with
AST_T38_REQUEST_NEGOTIATE as the request type), and the application
can respond as normal. If this occurs within the five second timeout
in chan_sip, the automatic cancellation of the peer reinvite will be
stopped, and the application will 'own' the negotiation process from
that point onwards.
This also improves the code path in chan_sip to allow sip_indicate(),
when called for AST_CONTROL_T38_PARAMETERS, to be able to return a
non-zero response, which should have been in place before since the
control frame *can* fail to be processed properly. It also modifies
ast_indicate() to return whatever result the channel driver returned
for this control frame, rather than converting all non-zero results
into '-1'. Finally, the new request type intentionally returns a
positive value, so that an application that sends
AST_T38_REQUEST_PARMS can know for certain whether the channel driver
accepted it and will be replying with a control frame of its own, or
whether it was ignored (if the sip_indicate()/ast_indicate() path had
properly supported failure responses before, this would not be
necessary).
This patch also modifies res_fax to take advantage of the new request.
In addition, this patch makes sip_t38_abort() actually lock the
private structure before doing its work... bad programmer, no donut.
This patch also enhances chan_sip's 'faxdetect' support to allow
triggering on T.38 re-INVITEs received as well as CNG tone detection.
Review: https://reviewboard.asterisk.org/r/556/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@260884 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r260292 | tilghman | 2010-04-30 01:19:35 -0500 (Fri, 30 Apr 2010) | 13 lines
Don't allow file descriptors to go above 64k, when we're closing them in a fork(2).
This saves time, when, even though the system allows the process limit to be
that high, the practical limit is much lower.
(closes issue #17223)
Reported by: dbackeberg
Patches:
20100423__issue17223.diff.txt uploaded by tilghman (license 14)
Tested by: dbackeberg
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@260303 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r260050 | dvossel | 2010-04-29 10:33:27 -0500 (Thu, 29 Apr 2010) | 21 lines
Merged revisions 260049 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r260049 | dvossel | 2010-04-29 10:31:02 -0500 (Thu, 29 Apr 2010) | 14 lines
Fixes crash in audiohook_write_list
The middle_frame in the audiohook_write_list function was
being freed if a audiohook manipulator returned a failure.
This is incorrect logic. This patch resolves this and
adds detailed descriptions of how this function should work
and why manipulator failures must be ignored.
(closes issue #17052)
Reported by: dvossel
Tested by: dvossel
(closes issue #16196)
Reported by: atis
Review: https://reviewboard.asterisk.org/r/623/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@260051 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r259870 | dvossel | 2010-04-28 16:20:03 -0500 (Wed, 28 Apr 2010) | 39 lines
Merged revisions 259858 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r259858 | dvossel | 2010-04-28 16:16:03 -0500 (Wed, 28 Apr 2010) | 33 lines
resolves deadlocks in chan_local
Issue_1.
In the local_hangup() 3 locks must be held at the same time... pvt, pvt->chan,
and pvt->owner. Proper deadlock avoidance is done when the channel to hangup
is the outbound chan_local channel, but when it is not the outbound channel we
have an issue... We attempt to do deadlock avoidance only on the tech pvt, when
both the tech pvt and the pvt->owner are locked coming into that loop. By
never giving up the pvt->owner channel deadlock avoidance is not entirely possible.
This patch resolves that by doing deadlock avoidance on both the pvt->owner and the pvt
when trying to get the pvt->chan lock.
Issue_2.
ast_prod() is used in ast_activate_generator() to queue a frame on the channel
and make the channel's read function get called. This function is used in
ast_activate_generator() while the channel is locked, which mean's the channel
will have a lock both from the generator code and the frame_queue code by the
time it gets to chan_local.c's local_queue_frame code... local_queue_frame
contains some of the same crazy deadlock avoidance that local_hangup requires,
and this recursive lock prevents that deadlock avoidance from happening correctly.
This patch removes ast_prod() from the channel lock so only one lock is held during
the local_queue_frame function.
(closes issue #17185)
Reported by: schmoozecom
Patches:
issue_17185_v1.diff uploaded by dvossel (license 671)
issue_17185_v2.diff uploaded by dvossel (license 671)
Tested by: schmoozecom, GameGamer43
Review: https://reviewboard.asterisk.org/r/631/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@259899 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r259439 | qwell | 2010-04-27 16:13:01 -0500 (Tue, 27 Apr 2010) | 5 lines
Add gar to the check for AR for those silly OSes (Solaris) that don't have ar.
autoconf2.13 couldn't handle AC_PROG_GREP, so I removed it. This is fine,
since we don't need to use anything that the configure script doesn't.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@259486 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r259023 | mmichelson | 2010-04-26 16:13:35 -0500 (Mon, 26 Apr 2010) | 19 lines
Merged revisions 259018 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r259018 | mmichelson | 2010-04-26 16:03:08 -0500 (Mon, 26 Apr 2010) | 13 lines
Prevent Newchannel manager events for dummy channels.
No Newchannel manager event will be fired for channels that are
allocated to not match a registered technology type. Thus bogus
channels allocated solely for variable substitution or CDR
operations do not result in a Newchannel event.
(closes issue #16957)
Reported by: atis
Review: https://reviewboard.asterisk.org/r/601
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@259103 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
For 1.6.2, only merge the bug fixes, not the unit test.
........
r258632 | russell | 2010-04-22 16:06:53 -0500 (Thu, 22 Apr 2010) | 22 lines
Add ast_event subscription unit test and fix some ast_event API bugs.
This patch introduces another test in test_event.c that exercises most of the
subscription related ast_event API calls. I made some minor additions to the
existing event allocation test to increase API coverage by the test code.
Finally, I made a list in a comment of API calls not yet touched by the test
module as a to-do list for future test development.
During the development of this test code, I discovered a number of bugs in
the event API.
1) subscriptions to AST_EVENT_ALL were not handled appropriately in a couple
of different places. The API allows a subscription to all event types,
but with IE parameters, just as if it was a subscription to a specific
event type. However, the parameters were being ignored. This affected
ast_event_check_subscriber() and event distribution to subscribers.
2) Some of the logic in ast_event_check_subscriber() for checking subscriptions
against query parameters was wrong.
Review: https://reviewboard.asterisk.org/r/617/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@258672 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r257947 | qwell | 2010-04-19 16:49:30 -0500 (Mon, 19 Apr 2010) | 6 lines
Don't consider a missing indications.conf to be a critical error.
There were many changes in revision 176627 which would avoid the error that a
missing config would have caused. Other than this, there are no other config
files (including asterisk.conf, surprisingly) that are required.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@257948 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r257262 | tilghman | 2010-04-14 17:57:35 -0500 (Wed, 14 Apr 2010) | 15 lines
Yet another issue where the conversion of the application delimiter to comma caused an issue.
Application arguments within the feature map could possibly contain a comma,
which conflicts with the syntax of the features.conf configuration file. This
patch allows the argument to be wrapped in parentheses or quoted, to allow the
application arguments to be interpreted as a single configuration parameter.
(closes issue #16646)
Reported by: pinga-fogo
Patches:
20100414__issue16646.diff.txt uploaded by tilghman (license 14)
Tested by: tilghman
Review: https://reviewboard.asterisk.org/r/547/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@257265 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r257146 | mnicholson | 2010-04-13 13:10:30 -0500 (Tue, 13 Apr 2010) | 16 lines
Merged revisions 257070 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r257070 | mnicholson | 2010-04-13 11:46:30 -0500 (Tue, 13 Apr 2010) | 9 lines
Add an option to restore past broken behavor of the Events manager action
Before r238915, certain values for the EventMask parameter of the Events action would result in no response being returned. This patch adds an option to restore that broken behavior. Also while fixing this bug I discovered that passing an empty EventMasks parameter would also result in no response being returned, this has been fixed as well while being preserved when the broken behavior is requested.
(closes issue #17023)
Reported by: nblasgen
Review: https://reviewboard.asterisk.org/r/602/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@257184 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r254454 | mmichelson | 2010-03-25 11:04:48 -0500 (Thu, 25 Mar 2010) | 50 lines
Recorded merge of revisions 254452 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r254452 | mmichelson | 2010-03-25 10:59:56 -0500 (Thu, 25 Mar 2010) | 44 lines
Several fixes regarding RFC2833 DTMF detection.
Here is a copy and paste of the details from my request on
reviewboard that dealt with these changes:
Fix 1. The first change in place is to fix Mantis issue 15811, which deals with a situation where Asterisk will incorrectly interpret out of order RFC2833 frames as duplicate DTMF digits. For instance, we would receive a sequence like:
seqno 1: DTMF 1
seqno 2: DTMF 1
seqno 3: DTMF 1
seqno 4: DTMF 1
seqno 6: DTMF 1 (end)
seqno 5: DTMF 1
seqno 7: DTMF 1 (end)
seqno 8: DTMF 1 (end)
Prior to this patch when we received the frame with seqno 5, we would interpret this as a new DTMF 1. With this patch, we will check the seqno of the incoming digit and not process the frame if the seqno is lower than the last recorded seqno. Note that we do not record the seqno of the dropped DTMF frame for future processing. While the above situation is what was designed to be fixed, the patch is written in such a way that the following would also be fixed too:
seqno 9: DTMF 1
seqno 10: DTMF 1 (end)
seqno 11: DTMF 1 (end)
seqno 13: DTMF 2
seqno 12: DTMF 1 (end)
seqno 14: DTMF 2
seqno 15: DTMF 2 (end)
seqno 16: DTMF 2 (end)
seqno 17: DTMF 2 (end)
In this second situation, the beginning of the DTMF 2 arrives before the final end frame of the DTMF 1. With the patch, seqno 12 is no processed and thus we properly interpret the DTMF.
Fix 2. The second change in place is to fix an issue like the following:
seqno 1: DTMF 1
seqno 2: DTMF 1
seqno 3: DTMF 1 (end) *packet lost*
seqno 4: DTMF 1 (end) *packet lost*
seqno 5: DTMF 1 (end) *packet lost*
seqno 6: DTMF 2
When we receive seqno 6, we had code in place that was supposed to properly end the previously unended DTMF 1. The problem was that the code was essentially a no-op. The code would set up an end frame for the DTMF 1 but would immediately overwrite the frame with the begin for DTMF 2. I changed process_dtmf_rfc2833() so that instead of returning a single frame, it is given as an output parameter a list of frames. Each frame that needs to be returned is appended to this list.
Fix 3. The final change is a minor one where an AST_CONTROL_SRCCHANGE frame could get lost. If we process a cisco DTMF or an RFC 3389 frame and no frame was returned, then we would return &ast_null_frame. The problem is that earlier in the function, we may have generated an AST_CONTROL_SRCCHANGE frame and put it in the list of frames we wish to return. This frame would be lost in such a case. The patch fixes this problem
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@254482 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r254050 | jpeeler | 2010-03-23 16:17:23 -0500 (Tue, 23 Mar 2010) | 14 lines
Exit native bridging early for greater timing accuracy with warnings
This changes native bridging to break one millisecond early so that the more
accurate timeval calculations done in the generic bridge can be performed using
the bridge config. Currently the time between exiting native bridging slightly
late can sometimes cause a large enough discrepancy for warnings to be missed.
For the record, 1.4 does not attempt to native bridge at all when warnings are
enabled.
(closes issue #15815)
Reported by: adomjan
Review: https://reviewboard.asterisk.org/r/577/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@254068 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r253490 | alecdavis | 2010-03-19 20:37:00 +1300 (Fri, 19 Mar 2010) | 19 lines
prevent segfault if bad magic number is encountered.
internal_ao2_ref uses INTERNAL_OBJ which mzy report 'bad magic number', but
internal_ao2_ref continues on, causing segfault.
Although AO2_MAGIC number is checked by INTERNAL_OBJ before internal_ao2_ref is
called, A02_MAGIC is being destroyed (or a wrong pointer) by the time
internal_ao2_ref uses INTERNAL_OBJ.
internal_ao2_ref now returns -1 if INTERNAL_OBJ encouters a bad magic number.
(issue #17037)
Reported by: alecdavis
Patches:
bug17037.diff.txt uploaded by alecdavis (license 585)
Tested by: alecdavis
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@253492 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.2@252137 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r251679 | jpeeler | 2010-03-10 14:51:23 -0600 (Wed, 10 Mar 2010) | 13 lines
Fix ParkAndAnnounce not respecting parking options.
The patch ensures that if a peer does not exist, parking settings are read from
the channel. A unit test has been written to ensure proper operation for both
standard parking and parking using masquerades.
(closes issue #16592)
Reported by: mwyres
Patches:
bug_16592.diff uploaded by snuffy (license 35)
Review: https://reviewboard.asterisk.org/r/539/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@251685 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r251631 | jpeeler | 2010-03-10 12:25:18 -0600 (Wed, 10 Mar 2010) | 14 lines
Fix jitterbuffer logging not creating logfiles.
Three changes made here:
1) Do not fail if a previous log does not exist (in fact, this is probably
expected).
2) Ensure that the file descriptor to write to gets assigned properly. I am at
a loss as to why assigning safe_fd outside the if fixes this, but it makes
the if statement slightly less complicated anyway.
3) Move up the failure message so that the errno of the failure is not
overwritten by fclose.
(closes issue #16917)
Reported by: Artem
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@251632 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r251262 | tilghman | 2010-03-07 23:12:55 -0600 (Sun, 07 Mar 2010) | 2 lines
Change needed to make Mac OS X 10.6 happy
........
r251263 | tilghman | 2010-03-07 23:15:01 -0600 (Sun, 07 Mar 2010) | 2 lines
Remove portions that weren't meant to be committed for the OS X compat fix
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@251268 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r249893 | dvossel | 2010-03-02 13:08:38 -0600 (Tue, 02 Mar 2010) | 11 lines
fixes adaptive jitterbuffer configuration
When configuring the adaptive jitterbuffer, the target_extra
value not only could not be set from the configuration, but was
not even being set to its proper default. This value is required
in order for the adaptive jitterbuffer to work correctly. To resolve
this a config option has been added to expose this value to the conf
files, and a default value is provided when no config specific value
is present.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@249895 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r248861 | tilghman | 2010-02-25 15:22:39 -0600 (Thu, 25 Feb 2010) | 22 lines
Merged revisions 248859 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r248859 | tilghman | 2010-02-25 15:21:05 -0600 (Thu, 25 Feb 2010) | 15 lines
Some platforms clear /var/run at boot, which makes connecting a remote console... difficult.
Previously, we only created the default /var/run/asterisk directory at install
time. While we could create it in the init script, that would not work for
those who start asterisk manually from the command line. So the safest thing
to do is to create it as part of the Asterisk boot process. This also changes
the ownership of the directory, because the pid and ctl files are created after
we setuid/setgid.
(closes issue #16802)
Reported by: Brian
Patches:
20100224__issue16802.diff.txt uploaded by tilghman (license 14)
Tested by: tzafrir
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@248864 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r228798 | tilghman | 2009-11-09 01:37:52 -0600 (Mon, 09 Nov 2009) | 14 lines
Fix various problems detected with Valgrind.
* chan_console accessed pvts after deallocation.
* The module loader did not check usecount on shutdown, which led to chan_iax2
reading a timer that was already unloaded.
(closes issue #16062)
Reported by: alexanderheinz
Patches:
20091109__issue16062.diff.txt uploaded by tilghman (license 14)
Tested by: tilghman
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@248011 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r247335 | mmichelson | 2010-02-17 15:22:40 -0600 (Wed, 17 Feb 2010) | 20 lines
Fix two problems in ast_str functions found while writing a unit test.
1. The documentation for ast_str_set and ast_str_append state that
the max_len parameter may be -1 in order to limit the size of the
ast_str to its current allocated size. The problem was that the max_len
parameter in all cases was a size_t, which is unsigned. Thus a -1 was
interpreted as UINT_MAX instead of -1. Changing the max_len parameter
to be ssize_t fixed this issue.
2. Once issue 1 was fixed, there was an off-by-one error in the case
where we attempted to write a string larger than the current allotted
size to a string when -1 was passed as the max_len parameter. When trying
to write more than the allotted size, the ast_str's __AST_STR_USED was
set to 1 higher than it should have been. Thanks to Tilghman for quickly
spotting the offending line of code.
Oh, and the unit test that I referenced in the top line of this commit
will be added to reviewboard shortly. Sit tight...
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@247337 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r247076 | mmichelson | 2010-02-16 17:44:33 -0600 (Tue, 16 Feb 2010) | 12 lines
Add va_end calls to __ast_str_helper.
According to the man page for stdarg(3),
"Each invocation of va_copy() must be matched by a
corresponding invocation of va_end() in the same
function."
There were several cases in __ast_str_helper where
va_copy was not matched with a corresponding call
to va_end.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@247079 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.2@246900 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.2@246547 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r245578 | tilghman | 2010-02-08 16:31:40 -0600 (Mon, 08 Feb 2010) | 12 lines
Actually use _ASTLDFLAGS in the main/ and channels/ Makefiles.
They were previously passed correctly, but they simply weren't used. This
caused issues with various platforms whose builds needed to pass special
linker flags via the configure script.
(closes issue #16596)
Reported by: pprindeville
Patches:
asterisk-1.6-astldflags.patch uploaded by pprindeville (license 347)
Tested by: tilghman
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@245581 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r244505 | tilghman | 2010-02-03 12:34:29 -0600 (Wed, 03 Feb 2010) | 8 lines
The chanvar= setting should inherit the entire list of variables, not just the first one.
(closes issue #16359)
Reported by: raarts
Patches:
dahdi-setvars.diff uploaded by raarts (license 937)
Tested by: raarts
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@244508 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Conditional expanded to check for hooks before aborting manager event
processing. The other two changes are just optimizations.
(closes issue #16455)
Reported by: atis
Patches:
manager_hooks_16.patch uploaded by atis (license 242)
Tested by: atis
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@243989 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r243244 | jpeeler | 2010-01-26 12:07:57 -0600 (Tue, 26 Jan 2010) | 12 lines
Fix crash resulting from frames with invalid data pointers.
In ast_frdup the frame data union does not get set to point to malloced memory
if the datalen is zero, so make sure to handle the same case in ast_frisolate
appropriately.
(closes issue #16058)
Reported by: atis
Patches:
bug16058-fix.patch uploaded by jpeeler (license 325)
Tested by: atis
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@243247 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Terry Wilson
Jeff Peeler
Russell Bryant
Tilghman Lesher
David Vossel
Mark Michelson
Jean Galarneau
Tim Ringenbach
Matthew Nicholson
Sean Bright
Kevin P. Fleming
Paul Belanger
Richard Mudgett
Leif Madsen
Jason Parker
Alec L Davis
Olle Johansson