https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r75403 | russell | 2007-07-17 15:01:12 -0500 (Tue, 17 Jul 2007) | 12 lines
(closes issue #10209)
Reported by: juggie
Patches:
10209-trunk-2.patch uploaded by juggie
Tested by: juggie, blitzrage
In ast_pbx_run(), mark a channel as hung up after an application returned -1,
or when it runs out of extensions to execute. This is so that code can detect
that this channel has been hung up for things like making sure DeadAGI is used
on actual dead channels, and is beneficial for other things, like making sure
someone doesn't try to start spying on a channel that is about to go away.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75404 65c4cc65-6c06-0410-ace0-fbb531ad65f3
in a consistent way. This is meant to replace the custom code
which is repeated all over the place in the various files when
parsing config files, CLI entries and other string information.
Right now the code supports parsing int32, uint32 and sockaddr_in with
optional default values and bound checks. It contains minimal error
checking, but that can be easily extended as the need arises.
Being a new API i am introducing this only in trunk, though I believe
that once the interface has been ironed out it might become a
worthwhile addition to 1.4 as well - basically, the first time
we will need to fix a piece of argument parsing code, we might as
well bring in this change and use the new API instead.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75379 65c4cc65-6c06-0410-ace0-fbb531ad65f3
sockets other than RTP ones.
The main change is a new API function in main/rtp.c (see there
for a description)
int ast_stun_request(int s, struct sockaddr_in *dst,
const char *username, struct sockaddr_in *answer)
which can be used to send an STUN request on a socket, and
optionally wait for a reply and store the STUN_MAPPED_ADDRESS
into the 'answer' argument (obviously, the version that
waits for a reply is blocking, but this is no different
from DNS resolutions).
Internally there are minor modifications to let stun_handle_packet()
be somewhat configurable on how to parse the body of responses.
At the moment i am not committing any change to the clients,
but adding STUN client support is extremely simple, e.g. chan_sip.c
could do something like this:
+ add a variable to store the stun server address;
static struct sockaddr_in stunaddr = { 0, }; /*!< stun server address */
+ add code to parse a config file of the form "stunaddr=my.stun.server.org:3478"
(not shown for brevity);
+ right after binding the main sip socket, talk to the stun server to
determine the externally visible address
if (stunaddr.sin_addr.s_addr != 0)
ast_stun_request(sipsock, &stunaddr, NULL, &externip);
so now 'externip' is set with the externally visible address.
so it is really trivial.
Similarly ast_stun_request could be called when creating the RTP
socket (possibly adding a struct sockaddr_in field in the struct
ast_rtp to store the externalip).
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75034 65c4cc65-6c06-0410-ace0-fbb531ad65f3
+ mark a potentially dangerous write-past-end-of-buffer
+ localize some variables in the block generating stun replies.
As before, not ready yet for a merge to 1.4
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@74850 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ast_rtp_new_with_bindaddr():
1. add comments to the logic of the main loop;
2. use a common exit point on failure so the cleanup is done only in one place;
3. handle failures in rtp_socket() in the main loop of the function;
No functional changes except for #3 above, so it is not yet
worthwhile merging this and other changes to 1.4
Once the cleanup work on this file will be complete (which among
other things should include some extensions to the stun support)
it might be a good thing to push all the changes to 1.4
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@74813 65c4cc65-6c06-0410-ace0-fbb531ad65f3
(which is very little, at the moment).
Eventually, when the functionality is extended, the changes can be merged
back to 1.4. At the moment this is pointless.
Note, this change is whitespace only.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@74571 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
(closes issue #10133)
................
r74374 | qwell | 2007-07-10 13:39:30 -0500 (Tue, 10 Jul 2007) | 13 lines
Merged revisions 74373 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r74373 | qwell | 2007-07-10 13:37:23 -0500 (Tue, 10 Jul 2007) | 5 lines
Use res_ndestroy on systems that have it. Otherwise, use res_nclose.
This prevents a memleak on NetBSD - and possibly others.
Issue 10133, patch by me, reported and tested by scw
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@74375 65c4cc65-6c06-0410-ace0-fbb531ad65f3
for extracting application, function, manager, and agi documentation is the wrong
one to take. The most severe problem is that the output depends on which modules
are loaded as well as compile time options, which both determine which parts are
available.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@72986 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r72933 | murf | 2007-07-02 14:16:31 -0600 (Mon, 02 Jul 2007) | 1 line
support for floating point numbers added to ast_expr2 $\[...\] exprs. Fixes bug 9508, where the expr code fails with fp numbers. The MATH function returns fp numbers by default, so this fix is considered necessary.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@72940 65c4cc65-6c06-0410-ace0-fbb531ad65f3
*must* write the file to the FILE *, and not the raw fd. Otherwise, it breaks
TLS support.
Thanks to rizzo for catching this!
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@72738 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Use weaker error checking because we have some automatically generated
files. However just mask out -Werror, because other warnings below:
-Wundef -Wstrict-prototypes -Wmissing-declarations
-Wmissing-prototypes
may actually be important and spot out real bugs.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@72727 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Handle transferring large files from the built-in http server. Previously, the
code attempted to malloc a block as large as the file itself. Now it uses the
sendfile() system call so that the file isn't copied into userspace at all if
it is available. Otherwise, it just uses a read/write of small chunks at a time.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@72701 65c4cc65-6c06-0410-ace0-fbb531ad65f3
check dependencies for libraries.
Because these targets (e.g. minimime/libmmime.a) are real ones,
declaring them .PHONY would cause them to be rebuilt every time
(see e.g. SVN 64355).
As a workaround I am using the following CHECK_SUBDIR target:
CHECK_SUBDIR: # do nothing, just make sure that we recurse in the subdir/
minimime/libmmime.a: CHECK_SUBDIR
@cd minimime && $(MAKE) libmmime.a
which seems to do a better job than .PHONY (probably because
.PHONY forces the rebuild even if the recursive make does not think
it is necessary).
If this turns out to be the correct approach, we can then
merge it back into 1.4
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@72700 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r72383 | bbryant | 2007-06-27 18:29:14 -0500 (Wed, 27 Jun 2007) | 11 lines
Merged revisions 72373 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r72373 | bbryant | 2007-06-27 18:22:13 -0500 (Wed, 27 Jun 2007) | 3 lines
Reinstating patch. This actually fixes the problem, however I was running a development branch without it and mistakenly thought it wasn't fixed.
Fixes issue #10010, and #9654: 100% CPU usage caused by an asterisk console losing it's controlling terminal.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@72384 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r72257 | file | 2007-06-27 16:25:24 -0400 (Wed, 27 Jun 2007) | 10 lines
Merged revisions 72256 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r72256 | file | 2007-06-27 16:23:24 -0400 (Wed, 27 Jun 2007) | 2 lines
I may possibly get shot for doing this... but... defer CDR processing until after the channel has been dealt with. This should eliminate all of the issues with channels going funky (SIP/PRI) when you are posting CDRs to a database that is either slow or unavailable and do not want to enable batching.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@72258 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r71063 | murf | 2007-06-22 08:10:24 -0600 (Fri, 22 Jun 2007) | 1 line
My conditions for merging amaflags info was naive; DOCUMENTATION is the default, although null is possible; theft of user-settable fields is not good. Just copy them, leave them alone.
This is for bug 10016. (plus a small fix to rtp, to elim a compiler warning (dev mode))
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@71093 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r71066 | bbryant | 2007-06-22 09:53:08 -0500 (Fri, 22 Jun 2007) | 18 lines
Merged revisions 71064 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r71064 | bbryant | 2007-06-22 09:39:34 -0500 (Fri, 22 Jun 2007) | 10 lines
Fixed infinite loop when controlling terminal was lost
and return value of input function wasn't checked for
errors. This would cause 100% cpu to be taken up.
(closes issue #9654, issue #10010)
Reported by: mnicholson, and eserra
Idea for the patch from mnicholson, patched by me
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@71067 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Also adds a new "reporting" permission for manager, since it can be incredibly spammy.
This permission was discussed on the -dev mailing list some months back.
Issue 8613, patch by johann8384, with some minor changes by me.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@70961 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r70949 | murf | 2007-06-21 16:34:41 -0600 (Thu, 21 Jun 2007) | 9 lines
Merged revisions 70948 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r70948 | murf | 2007-06-21 16:29:50 -0600 (Thu, 21 Jun 2007) | 1 line
This little fix is in response to bug 10016, but may not cure it. The code is wrong, clearly. In a situation where you set the CDR's amaflags, and then ForkCDR, and then set the new CDR's amaflags to some other value, you will see that all CDRs have had their amaflags changed. This is not good. So I fixed it.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@70951 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r70062 | murf | 2007-06-19 12:23:23 -0600 (Tue, 19 Jun 2007) | 9 lines
Merged revisions 70053 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r70053 | murf | 2007-06-19 12:07:59 -0600 (Tue, 19 Jun 2007) | 1 line
This fixes 9246, where channel variables are not available in the 'h' exten, on a 'ZOMBIE' channel. The fix is to consolidate the channel variables during a masquerade, and then copy the merged variables back onto the clone, so the zombie has the same vars that the 'original' has.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@70063 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r69470 | qwell | 2007-06-14 18:22:51 -0500 (Thu, 14 Jun 2007) | 12 lines
Merged revisions 69469 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r69469 | qwell | 2007-06-14 18:21:45 -0500 (Thu, 14 Jun 2007) | 4 lines
Fix an issue where the line number in an unterminated comment block error message would show the wrong line number.
"Reported" to me on #asterisk (somebody posted an error message, and I happened to catch it)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@69471 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r69010 | russell | 2007-06-12 14:13:41 -0500 (Tue, 12 Jun 2007) | 12 lines
In ast_channel_make_compatible(), just return if the channels' read and write
formats already match up. There are code paths that call this function on a
pair of channels multiple times. This made calls fail that were using g729
in some cases. The reason is that codec_g729a will unregister itself from the
list of available translators will all licenses are in use. So, the first
time the function got called, the right translation path was allocated.
However, the second time it got called, the code would not find a translation
path to/from g729 and make the call fail, even if the channel actually already
had a g729 translation path allocated.
(SPD-32)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@69011 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Tilghman Lesher
Steve Murphy
Russell Bryant
Luigi Rizzo
Kevin P. Fleming
Joshua Colp
Jason Parker
Brett Bryant
Dwayne M. Hubbard