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.0@249907 65c4cc65-6c06-0410-ace0-fbb531ad65f3
when called from a ISDN channel, null frames prevent '#' exit.
Now only echo back VOICE and DTMF frames
(closes issue #16880)
Reported by: alecdavis
Patches:
based on echo_exit_1-6-1.diff.txt uploaded by alecdavis (license 585)
Tested by: alecdavis
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@249846 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r249538 | jpeeler | 2010-03-01 11:11:31 -0600 (Mon, 01 Mar 2010) | 18 lines
Merged revisions 249536 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r249536 | jpeeler | 2010-03-01 11:02:03 -0600 (Mon, 01 Mar 2010) | 11 lines
Modify queued frames from local channels to not set the other side to up
In this case, attended transfers were broken due to ast_feature_request_and_dial
detecting the channel being set to up before the answer frame could be read and
therefore failing to mark the channel as ready. This fix is a regression fix for
244785, which should continue to work properly as well.
(closes issue #16816)
Reported by: jamhed
Tested by: jamhed, corruptor
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@249539 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Following Q.931 5.2.4
When the user has determined that sufficient call information has been received the
user shall stop T302 and send CALL PROCEEDING to the network.
Previously timeouts were possible if the dialplan took a long time to issue any
response back to the network.
Verified that our local TELCO also does the same.
(issue #16789)
Reported by: alecdavis
Patches:
overlap_receiving_trunk.diff.txt uploaded by alecdavis (license 585)
Tested by: alecdavis
(closes issue #16789)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@249364 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r248952 | jpeeler | 2010-02-25 17:09:54 -0600 (Thu, 25 Feb 2010) | 24 lines
Merged revisions 248860 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r248860 | jpeeler | 2010-02-25 15:22:06 -0600 (Thu, 25 Feb 2010) | 18 lines
Ensure that monitor recordings are written to the correct location (again)
This is an extension to 248757. As such the dialplan test has been extended:
exten => 5040, 1, monitor(wav,tmp/jeff/monitor_test,b)
exten => 5040, n, dial(sip/5001)
exten => 5041, 1, monitor(wav,/tmp/jeff/monitor_test2,b)
exten => 5041, n, dial(sip/5001)
exten => 5042, 1, monitor(wav,monitor_test3,b)
exten => 5042, n, dial(sip/5001)
exten => 5043, 1, monitor(wav,tmp/jeff/monitor_test3,m)
exten => 5043, n, changemonitor(monitor_test4)
exten => 5043, n, dial(sip/5001)
exten => 5044, 1, monitor(wav,monitor_test4,m)
exten => 5044, n, changemonitor(tmp/jeff/monitor_test5) ; this looks to fail by design and emits a warning
exten => 5044, n, dial(sip/5001)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@248953 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.0@248862 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r248793 | jpeeler | 2010-02-25 12:37:56 -0600 (Thu, 25 Feb 2010) | 22 lines
Merged revisions 248757 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r248757 | jpeeler | 2010-02-25 12:06:54 -0600 (Thu, 25 Feb 2010) | 15 lines
Ensure that monitor recordings are written to the correct location.
Recordings should be placed in the monitor directory when a non-absolute path
is used.
Exact dialplan used for testing:
exten => 5040, 1, monitor(wav,tmp/jeff/monitor_test,b)
exten => 5040, n, dial(sip/5001)
exten => 5041, 1, monitor(wav,/tmp/jeff/monitor_test2,b)
exten => 5041, n, dial(sip/5001)
exten => 5042, 1, monitor(wav,monitor_test3,b)
exten => 5042, n, dial(sip/5001)
ABE-2101
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@248795 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
(closes issue #16470)
Reported by: kjotte
........
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.0@248008 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r247914 | rmudgett | 2010-02-19 11:33:33 -0600 (Fri, 19 Feb 2010) | 62 lines
Merged revisions 247910 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r247910 | rmudgett | 2010-02-19 11:18:49 -0600 (Fri, 19 Feb 2010) | 55 lines
Merged revision 247904 from
https://origsvn.digium.com/svn/asterisk/be/branches/C.2-...
..........
r247904 | rmudgett | 2010-02-19 10:49:44 -0600 (Fri, 19 Feb 2010) | 49 lines
Make chan_misdn DTMF processing consistent with other channel technologies.
The processing of DTMF tones on the receiving side of an ISDN channel is
inconsistent with the way it is handled in other channels, especially
DAHDI analog. This causes DTMF tones sent from an ISDN phone to be
doubled at the connected party.
We are using the following 2 options of misdn.conf
1) astdtmf=yes
2) senddtmf=yes
Option one is necessary because the asterisk DSP DTMF detection is better
than mISDN's internal DSP. Not as many false positives.
Option two is necessary to transmit DTMF tones end to end when mISDN
channels are connected to SIP channels with out of band DTMF for example.
The symptom is that DTMF tones sent by an ISDN phone are doubled on the
way through asterisk when two mISDN channels are connected with a Local
channel in between or if it is bridged to an analog channel.
The doubling of DTMF tones is because DTMF is passed inband to asterisk by
the mISDN channel and passed out of band once again after the release of
the DTMF tone. Passing it inband is wrong. Neither an analog channel nor
SIP channel passes DTMF inband if configured to inband DTMF. Analog and
SIP channels filter out the DTMF tones because they use the voice frames
returned by ast_dsp_process. But chan_misdn passes the unfiltered input
voice frames instead.
To overcome one aspect of the problem, the doubling of DTMF tones when two
mISDN channels are directly bridged, someone made an 'optimization', where
in that case the DTMF tone passed out-of-band to the peer channel is not
translated to an inband tone at the transmit side. This optimization is
bad because it does not work in general. For example, analog channels or
mISDN channels when bridged through an intermediary local channel will
generate DTMF tones from out-of-band information. Also, of course, it
must not be done when there is no inband DTMF available.
This patch fixes the issue. Now chan_misdn will filter the received
inband DTMF signal the same as other channel types.
Another change included: No need to build an extra translation path
because ast_process_dsp does it if required.
Patches:
misdn-dtmf.patch
JIRA ABE-2080
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@247922 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r247915 | dvossel | 2010-02-19 11:40:26 -0600 (Fri, 19 Feb 2010) | 7 lines
handle_request_invite revise comment, fix coding guideline issues
I'm working with this code right now trying to analyze a deadlock.
This change is just to clean up a few things before I make a more
complex patch.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@247918 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r247787 | tilghman | 2010-02-18 15:42:53 -0600 (Thu, 18 Feb 2010) | 17 lines
If the peer record is from realtime, it could be set to 0, due to MySQL not representing NULL well in integer columns.
NULL means the value is not specified for the column, which normally means
the driver uses whatever is the default value. However, on MySQL, placing
a NULL in either a float or integer column results in a retrieval of the 0
value. Hence, users get an errant error on load. This patch suppresses
that error and makes the value as if it was not there.
Note that this cannot be done in the realtime driver, because the lack of
difference between NULL and 0 can only be intepreted correctly by the
driver itself. If we did it in the realtime driver, then it would be
effectively impossible to set any realtime field to 0, because it would act
as if the field were unspecified and possibly take on a different value.
(closes issue #16683)
Reported by: wdoekes
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@247789 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r247423 | russell | 2010-02-17 22:20:11 -0600 (Wed, 17 Feb 2010) | 17 lines
Merged revisions 247422 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r247422 | russell | 2010-02-17 22:19:01 -0600 (Wed, 17 Feb 2010) | 10 lines
Tweak argument handling for wget in the sounds Makefile.
1) Fix the check to see if we are using wget to not be full of fail. The
configure script populates this variable with the absolute path to wget if
it is found, so it didn't work.
2) Allow some extra arguments to be passed in for wget. This is just a simple
change to allow our Bamboo build script to tell wget to be quiet and not fill
up our logs with download status output.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@247424 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.0@247338 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
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.0@247077 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.0@246903 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r246710 | tilghman | 2010-02-15 17:43:28 -0600 (Mon, 15 Feb 2010) | 12 lines
Merged revisions 246709 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r246709 | tilghman | 2010-02-15 17:42:33 -0600 (Mon, 15 Feb 2010) | 5 lines
Make the menuselect instructions correct by allowing 'make menuselect' to actually solve dependency problems.
(Previously, it would fail out again with the same message about running
'make menuselect', which was NOT at all helpful.)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@246711 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.0@246549 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r246070 | jpeeler | 2010-02-10 10:47:37 -0600 (Wed, 10 Feb 2010) | 22 lines
Change channel state on local channels for busy,answer,ring.
Previously local channels channel state never changed. This became problematic
when the state of the other side of the local channel was lost, for example
during a masquerade. Changing the state of the local channel allows for the
scenario to be detected when the channel state is set to ringing, but the peer
isn't ringing. The specific problem scenario is described in 164201. Although
this was noted on one of the issues, here is the tested dialplan verified to
work:
exten => 9700,1,Dial(Local/*9700@default&Local/0009700@default)
exten => *9700,1,Set(GLOBAL(TESTCHAN)=${CHANNEL:0:${MATH(${LEN(${CHANNEL})}-1):0:2}}1)
exten => *9700,n,wait(3) ;3 works, 1 did not
exten => *9700,n,Dial(SIP/5001)
exten => 0009700,1,Wait(1) ;1 works, 3 did not
exten => 0009700,n,ChannelRedirect(${TESTCHAN},parkedcalls,701,1)
(closes issue #14992)
Reported by: davidw
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@246071 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r245793 | dvossel | 2010-02-09 17:07:17 -0600 (Tue, 09 Feb 2010) | 18 lines
Merged revisions 245792 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r245792 | dvossel | 2010-02-09 16:55:38 -0600 (Tue, 09 Feb 2010) | 12 lines
Fixes iaxs and iaxsl size off by one issue.
2^15 = 32768 which is the maximum allowed iax2 callnumber.
Creating the iaxs and iaxsl array of size 32768 means the maximum
callnumber is actually out of bounds. This causes a nasty crash.
(closes issue #15997)
Reported by: exarv
Patches:
iax_fix.diff uploaded by dvossel (license 671)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@245796 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r245680 | kpfleming | 2010-02-09 10:24:52 -0600 (Tue, 09 Feb 2010) | 8 lines
Don't offer MMR or JBIG transcoding during T.38 negotiation.
After further discussion with Steve Underwood, we should not (yet) be offering
to receive MMR or JBIG transcoded streams from T.38 endpoints. A future spandsp
release will support those features, and then they can be enabled during
negotiation
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@245681 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Also remove some accidentally duplicated code, which may have been causing a memleak.
This was caused by a bad merge.
(closes issue #16579)
Reported by: kue
Patches:
0016525.patch uploaded by hokie21 (license 987)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@245627 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.0@245579 65c4cc65-6c06-0410-ace0-fbb531ad65f3
