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/trunk@254450 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Here is a cut and paste of my review request for this change:
This past weekend, Russell ran our current suite of unit tests for Asterisk
under valgrind. The PBX pattern match test caused valgrind to spew forth two
invalid read errors. This patch contains two changes that shut valgrind up and
do not cause any new memory leaks.
Change 1: In ast_context_remove_extension_callerid2, valgrind reported an
invalid read in the for loop close to the function's end. Specifically, one of
the the strcmp calls in the loop control was reading invalid memory. This was
because the caller of ast_context_remove_extension_callerid2 (__ast_context
destroy in this case) passed as a parameter a shallow copy of an ast_exten's
exten field. This same ast_exten was what was destroyed inside the for loop,
thus any iterations of the for loop beyond the destruction of the ast_exten
would result in invalid reads. My fix for this is to make a copy of the
ast_exten's exten field and pass the copy to
ast_context_remove_extension_callerid2. In addition, I have also acted
similarly with the ast_exten's matchcid field. Since in this case a NULL is
handled quite differently than an empty string, I needed to be a bit more
careful with its handling.
Change 2: In __ast_context_destroy, we iterated over a hashtab and called
ast_context_remove_extension_callerid2 on each item. Specifically, the hashtab
over which we were iterating was an ast_exten's peer_table. Inside of
ast_context_remove_extension_callerid2, we could possibly destroy this
ast_exten, which also caused the hashtab to be freed. Attempting to call
ast_hashtab_end_traversal on the hashtab iterator caused an invalid read to
occur when trying to read the iterator->tab->do_locking field since
iterator->tab had already been freed. My handling of this problem is a bit less
straightforward. With each iteration over the hashtab's contents, we set a
variable called "end_traversal" based on the return of
ast_context_remove_extension_callerid2. If 0 is ever returned, then we know
that the extension was found and destroyed. Because of this, we cannot call
ast_hashtab_end_traversal because we will be guaranteeing a read of invalid
memory. In such a case, we forego calling ast_hashtab_end_traversal and instead
call ast_free on the hashtab iterator.
Review: https://reviewboard.asterisk.org/r/585
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254362 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@254050 65c4cc65-6c06-0410-ace0-fbb531ad65f3
users expect them to work.
'core set debug' and 'core set verbose' can optionally change the
level for a specific filename; however, this is actually for a
specific source file name, not the module that source file is included
in. With examples like chan_sip, chan_iax2, chan_misdn and others
consisting of multiple source files, this will not lead to the
behavior that users expect. If they want to set the debug level for
chan_sip, they want it set for all of chan_sip, and not to have to
also set it for reqresp_parser and other files that comprise the
chan_sip module.
This patch changes this functionality to be module-name based instead
of file-name based.
To make this work, some Makefile modifications were required to ensure
that the AST_MODULE definition is present in each object file produced
for each module as well.
Review: https://reviewboard.asterisk.org/r/574/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@253917 65c4cc65-6c06-0410-ace0-fbb531ad65f3
We can have bad results when a module, upon being loaded, attempts
to reference the channels container if the container hasn't yet
been initialized. I saw this happen by trying to preload pbx_config.so
and having a hint defined which referenced a non-existent SIP peer.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@253872 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@253490 65c4cc65-6c06-0410-ace0-fbb531ad65f3
On Linux (glibc), regcomp() does not return an error for an empty string.
However, the version on OSX will return an error. The test for channel group
matching by regex now passes on the mac, as well.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@252241 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@252089 65c4cc65-6c06-0410-ace0-fbb531ad65f3
(Copied from reviewboard)
Tests the following:
1. Basic allocation and setting of string fields.
2. Shrinking a string field and re-expanding it.
3. Growing the last allocation in a string field pool.
4. Setting a string to a large value such that a new string field pool must be
allocated.
In each part, we make sure that the string field is accurate (has the correct
value in it), make sure that the 2 bytes before the string field has the correct
capacity for the field, and for tests 2-4, we make sure that the string field is
where we expect it to be in memory.
Also tested:
5. Shrinking a string field and partially re-expanding it.
6. Setting strings in such a way as to create three separate string field pools
and then removing the middle pool.
There is a bug fix in the init function, which ensures the embedded_pool is set
to NULL which is important for stack allocated structures.
Review: https://reviewboard.asterisk.org/r/185/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@251736 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@251679 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@251631 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Only chan_dahdi set a value in cdrflags. Everyone else just copied it
around the system. Noone cared about any value it may have contained.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@250565 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@249893 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@248861 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
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
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
Terry Wilson
Kevin P. Fleming
Mark Michelson
Tzafrir Cohen
Russell Bryant
Jeff Peeler
Matthew Nicholson
Alec L Davis
Tilghman Lesher
Leif Madsen
Richard Mudgett
David Vossel