(e.g. chan_sip.c in a subsequent commit).
Obviously exposing the internals of a data structure is far from ideal
(especially in a case like this where the implementation is very
inefficient and will need to be changed at some point).
On the other hand, it was also unclear what additional APIs should
we provide instead, and because exposing the stucture has no impact
on source and binary compatibility, this seemed to me the best option at
this time.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@76034 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
use the \retval tag for documenting return values, fixing various warnings
when generating the documentation, and various other things.
(closes issue #10203, snuffy)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75164 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
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
Reported by: julien23
Patches submitted by: julien23
Add the ability to disable recording the input or output streams in res_monitor.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@74164 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If the call is answered by another phone, other phones won't display the call as "missed".
You can also add an option to the dial command so that you can have a "followme"
scenario and not count the calls as "missed" when you cancel the call.
Thanks to Ramon and Frank for feedback on this feature.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@74024 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
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
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
........
r69702 | russell | 2007-06-18 11:35:02 -0500 (Mon, 18 Jun 2007) | 6 lines
To prevent 92138749238754 more reports of "I have unixodbc installed, but
still can't build *_odbc.so!", check for ltdl directly, instead of just listing
it as another library to include in the unixodbc check in the configure script.
This also makes ltdl show up as a dependency in menuselect so people know what
to go install. (related to issue #9989, patch by me)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@69703 65c4cc65-6c06-0410-ace0-fbb531ad65f3
the beginning of the file. Also, add a channel variable that indicates
the location in the file where the Playback was stopped.
(closes issue #7655, patch from sharkey)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@68502 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r67993 | oej | 2007-06-07 11:00:44 +0200 (Thu, 07 Jun 2007) | 6 lines
Issue #9738 - Make sure we can unload res_jabber. Patch by phsultan - thanks!
Due to a bug in the iksemel library, this will not work if you are using GTLS
in the connection. That's being investigated. If you figure out a way to handle
that without us having to patch iksemel, let us know in the bug report. Thanks.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@68026 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r67716 | russell | 2007-06-06 11:55:59 -0500 (Wed, 06 Jun 2007) | 13 lines
Merged revisions 67715 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r67715 | russell | 2007-06-06 11:40:51 -0500 (Wed, 06 Jun 2007) | 5 lines
We have some bug reports showing crashes due to a double free of a channel.
Add a sanity check to ast_channel_free() to make sure we don't go on trying
to free a channel that wasn't found in the channel list.
(issue #8850, and others...)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@67717 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r67492 | russell | 2007-06-05 15:53:28 -0500 (Tue, 05 Jun 2007) | 16 lines
This bug has been hanging over my head ever since I wrote this SLA code.
Every time I tried to go debug it by adding some debug output, the behavior
would change. It turns out I wasn't crazy. I had the following piece of code:
if (remove)
AST_LIST_REMOVE_CURRENT(...);
Well, AST_LIST_REMOVE_CURRENT was not wrapped in braces, so my conditional
statement didn't do much good at all. It always ran at least all of the
macro minus the first statement, so I was seeing list entries magically
disappear when they weren't supposed to.
After many hours of debugging, I have come to this extremely irritating fix. :)
(issues #9581, #9497)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@67493 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r67308 | russell | 2007-06-05 10:51:53 -0500 (Tue, 05 Jun 2007) | 5 lines
When shutting down "gracefully", go through and run the unload() callbacks for
all of the modules. "stop now" is considered a non-graceful shutdown and will
not go through this process.
(issue #9804, reported by chrisost, patch by me)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@67310 65c4cc65-6c06-0410-ace0-fbb531ad65f3
places that cared about device states were app_queue and the hint code in pbx.c.
The changes include converting it to use the Asterisk event system, as well as
other efficiency improvements.
* app_queue: This module used to register a callback into devicestate.c to
monitor device state changes. Now, it is just a subscriber to Asterisk
events with the type, device state.
* pbx.c hints: Previously, the device state processing thread in devicestate.c
would call ast_hint_state_changed() each time the state of a device changed.
Then, that code would go looking for all the hints that monitor that device,
and call their callbacks. All of this blocked the device state processing
thread. Now, the hint code is a subscriber of Asterisk events with the
type, device state. Furthermore, when this code receives a device state
change event, it queues it up to be processed by another thread so that it
doesn't block one of the event processing threads.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@66958 65c4cc65-6c06-0410-ace0-fbb531ad65f3