Uncommenting the REF_DEBUG definition where it was in the source
resulted in only a small part of the astobj2 references being logged
to a file. Moving this up higher in the include list causes all references
to be logged as they should be.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@248347 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Break transmit_tone into transmit_start_tone and transmit_stop_tone as per the skinny protocol.
(closes issue #16874)
Reported by: wedhorn
Patches:
skinny-clean01.diff uploaded by wedhorn (license 30)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@248184 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r248106 | oej | 2010-02-20 23:25:42 +0100 (Lör, 20 Feb 2010) | 2 lines
Make sure we support RTCP compound messages with zero reports
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@248107 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@247915 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@247914 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@247787 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Consider the following scenario:
/-- B
A == * == Network
\-- C
Party B calls party A (EuroISDN BRI phone)
Party A puts B on hold using the HOLD/RETRIEVE messages.
Party A calls party C.
Party A puts C on hold to talk with party B again.
Party A transfers B to C by hanging up.
The call does not get the opportunity to get re-transferred into the ISDN
network by the native bridge because native bridging is not being
reexamined after the initial transfer.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@247609 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The new JabberStatus event gives a concise view of the status change to the AMI
clients. Thanks fiddur!
(closes issue #16760)
Reported by: fiddur
Patches:
244498.2.diff uploaded by fiddur (license 678)
Tested by: fiddur, phsultan
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@247500 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@247423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@247335 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Current support for regex matching was previously only available on the group.
Also, error reporting for regex failures has been added. In addition to this
feature enhancement a unit test has been written to check the regular expression
logic to ensure the count operation is working as expected.
(closes issue #16642)
Reported by: kobaz
Patches:
groupmatch2.patch uploaded by kobaz (license 834)
Review: https://reviewboard.asterisk.org/r/503/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@247295 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This feature allows for parkinglots to be created dynamically within
the dialplan. Thanks to all who were involved with getting this patch
written and tested!
(closes issue #15135)
Reported by: IgorG
Patches:
features.dynamic_park.v3.diff uploaded by IgorG (license 20)
2009090400_dynamicpark.diff.txt uploaded by mvanbaak (license 7)
dynamic_parkinglot.diff uploaded by dvossel (license 671)
Tested by: eliel, IgorG, acunningham, mvanbaak, zktech
Review: https://reviewboard.asterisk.org/r/352/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@247248 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Also includes a test for retrieving rtpqos parameters, including a NULL RTP
driver. Additionally, some further separation of the SIP internal API into
headers was necessary.
(closes issue #16652)
Reported by: kkm
Patches:
20100204__issue16652.diff.txt uploaded by tilghman (license 14)
Review: https://reviewboard.asterisk.org/r/501/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@247124 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@247076 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This test works by reading input from arrays to build a sample
dialplan. From there, patterns are attempted to be matched against
said dialplan, with the expected match given. We then search in our
example dialplan to see if we find a match and if what we find matches
what we expected it to match.
(closes issue #16809)
Reported by: lmadsen
Tested by: mmichelson
Review: https://reviewboard.asterisk.org/r/504/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@246942 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@246899 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change builds upon the recent change to menuselect to add 'touch_on_change'
as an attribute of both categories and members. This should allow only the most
invasive defines to cause a complete rebuild, while defines which only affect a
subset of modules will only cause a rebuild of that smaller set.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@246789 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@246710 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Ooops. Failed to note that we were inside a for loop and
pri_channel_bridge() needs to be executed only once.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@246669 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Code Refactoring Changes
- read_to_parts() moved to reqresp_parser.c and has been renamed as
get_name_and_number()
- get_in_brackets() moved to reqresp_parser.c
- find_closing_quotes() added to sip_utils.h
Logic Changes
- get_name_and_number() now uses parse_uri() and get_calleridname()
for parsing. Before this change only names within quotes were
found, when names not within quotes are possible.
New Unit Tests
-sip_get_name_and_number_test
-sip_get_in_brackets_test
(closes issue #16707)
Reported by: Nick_Lewis
Patches:
issue16706.diff uploaded by dvossel (license 671)
Review: https://reviewboard.asterisk.org/r/499/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@246627 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@246546 65c4cc65-6c06-0410-ace0-fbb531ad65f3