Safely handle AMI connections/reload requests that occur during startup.
During asterisk startup, a lock on the list of modules is obtained by the
primary thread while each module is initialized. Issue 13778 pointed out a
problem with this approach, however. Because the AMI is loaded before other
modules, it is possible for a module reload to be issued by a connected client
(via Action: Command), causing a deadlock.
The resolution for 13778 was to move initialization of the manager to happen
after the other modules had already been lodaded. While this fixed this
particular issue, it caused a problem for users (like FreePBX) who call AMI
scripts via an #exec in a configuration file (See issue 15189).
The solution I have come up with is to defer any reload requests that come in
until after the server is fully booted. When a call comes in to
ast_module_reload (from wherever) before we are fully booted, the request is
added to a queue of pending requests. Once we are done booting up, we then
execute these deferred requests in turn.
Note that I have tried to make this a bit more intelligent in that it will not
queue up more than 1 request for the same module to be reloaded, and if a
general reload request comes in ('module reload') the queue is flushed and we
only issue a single deferred reload for the entire system.
As for how this will impact existing installations - Before 13778, a reload
issued before module initialization was completed would result in a deadlock.
After 13778, you simply couldn't connect to the manager during startup (which
causes problems with #exec-that-calls-AMI configuration files). I believe this
is a good general purpose solution that won't negatively impact existing
installations.
We were trying to reference members of a struct that had previously been freed.
This patch makes sure that we free the struct after it has been removed from
the spooler queue.
The function ast_call_forward() forwards a call to an extension specified in an ast_channel's call_forward string. After an ast_channel is called, if the channel's call_forward string is set this function can be used to forward the call to a new channel and terminate the original one. I have included this api call in both channel.c's ast_request_and_dial() and res_feature.c's feature_request_and_dial(). App_dial and app_queue already contain call forward logic specific for their application and options.
David Vossel [Tue, 2 Jun 2009 21:17:49 +0000 (21:17 +0000)]
Generic call forward api, ast_call_forward()
The function ast_call_forward() forwards a call to an extension specified in an ast_channel's call_forward string. After an ast_channel is called, if the channel's call_forward string is set this function can be used to forward the call to a new channel and terminate the original one. I have included this api call in both channel.c's ast_request_and_dial() and feature.c's feature_request_and_dial(). App_dial and app_queue already contain call forward logic specific for their application and options.
David Vossel [Tue, 2 Jun 2009 17:55:35 +0000 (17:55 +0000)]
fixes issue with channels not going down after transfer
Iax2 currently does not support native bridging if the timeoutms value is set. We check for that in iax2_bridge, but then set timeoutms to 0 by default. If the timeoutms is not provided it is set to -1. By setting timeoutms to 0 it is processed causing a bridging retry loop.
Mark Michelson [Mon, 1 Jun 2009 20:57:31 +0000 (20:57 +0000)]
Add the ability to execute connected line interception macros.
When connected line updates are received or generated in the middle
of an application call, it is now possible to execute a macro to
manipulate the connected line data. This way, phone numbers may be
manipulated to be more presentable to users, names may be changed
for...whatever reason, or whatever else needs to be done may be.
If using the old deprecated format, a reload would cause the class to disappear.
(closes issue #14759)
Reported by: lidocaineus
Patches:
20090518__issue14759.diff.txt uploaded by tilghman (license 14)
Tested by: lmadsen
........
Sean Bright [Sat, 30 May 2009 20:11:33 +0000 (20:11 +0000)]
Properly terminate the receive buffer before sending to iksemel.
aji_io_recv takes the maximum number of bytes to read (instead of the total
buffer size), so we have to subtract 1 from our buffer size. Without this, when
we receive packets that are larger than our buffer, iksemel will choke and
things get wonky.
This code was there because of the AgentCallbackLogin() application.
->loginchan[] member was only used by AgentCallbackLogin().
Agent where dumped to astdb if they where logged in using AgentCallbacklogin()
so they are not being dumper anymore.
Russell Bryant [Fri, 29 May 2009 20:06:59 +0000 (20:06 +0000)]
Resolve issues with choppy sound when using res_timing_pthread.
The situation that caused this problem was when continuous mode was being
turned on and off while a rate was set for a timing interface. A very easy
way to replicate this bug was to do a Playback() from behind a Local channel.
In this scenario, a rate gets set on the channel for doing file playback.
At the same time, continuous mode gets turned on and off about every 20 ms
as frames get queued on to the PBX side channel from the other side of the
Local channel.
Essentially, this module treated continuous mode and a set rate as mutually
exclusive states for the timer to be in. When I dug deep enough, I observed
the following pattern:
1) Set timer to tick every 20 ms.
2) Wait almost 20 ms ...
3) Continuous mode gets turned on for a queued up frame
4) Continuous mode gets turned off
5) The timer goes back to its tick per 20 ms. state but starts counting
at 0 ms.
6) Goto step 2.
Sometimes, res_timing_pthread would make it 20 ms and produce a timer tick,
but not most of the time. This is what produced the choppy sound (or sometimes
no sound at all).
Now, the module treats continuous mode and a set rate as completely independent
timer modes. They can be enabled and disabled independently of each other and
things work as expected.
(closes issue #14412)
Reported by: dome
Patches:
issue14412.diff.txt uploaded by russell (license 2)
issue14412-1.6.1.0.diff.txt uploaded by russell (license 2)
Tested by: DennisD, russell
Simplify the Makefile and avoid needing to specify each object file.
Instead of specifying every object file, use make's magic to generate
it.
This will generate less conflicts in team branches when a new file is
added in trunk.
Jeff Peeler [Fri, 29 May 2009 19:19:51 +0000 (19:19 +0000)]
New signaling module to handle analog operations in chan_dahdi
This branch splits all the analog signaling logic out of chan_dahdi.c into
sig_analog.c. Functionality in theory should not change at all. As noted
in the code, there is still some unused code remaining that will be cleaned
up in a later commit.
Use AST_CDR_NOANSWER instead of AST_CDR_NULL as the default CDR disposition.
This change also involves the addition of an AST_CDR_FLAG_ORIGINATED flag that is used on originated channels to distinguish: them from dialed channels.
Mark Michelson [Fri, 29 May 2009 15:48:04 +0000 (15:48 +0000)]
A few fixes to SIP with regards to connected line updates during transfers.
* Set the invitestate to INV_CALLING when we send a connected line reinvite.
This prevents us from potentially rapid-firing reinvites to a single peer.
* Use the astdb to store a peer's allowed methods. This prevents us from sending
an UPDATE during the interval between startup and the peer's first registration
if the peer does not support the UPDATE method.
* Handle Polycom's method of indicating allowed methods in REGISTER. Instead of
using an Allow header, they place the allowed methods in a methods= parameter
in the Contact header.
Terry Wilson [Fri, 29 May 2009 05:15:40 +0000 (05:15 +0000)]
Add some TeX docs for calendaring.
I still need to set up tests to make sure my examples are completely correct,
but I ran out of time tonight and felt that they at least would give an idea as
to how to use calendaring. I will try to test the examples and do some cleanup
on the docs tomorrow night.
Leif Madsen [Thu, 28 May 2009 22:04:00 +0000 (22:04 +0000)]
Update documentation in MixMonitor.
Updated the MixMonitor documentation for the 'b' option so that
it is more obvious that you must not optimize away the Local
channel when using this option.
Kevin P. Fleming [Thu, 28 May 2009 20:36:49 +0000 (20:36 +0000)]
Ensure that accidental calls to ast_string_field_free_memory() on embedded stringfield pools are safe.
It is possible for a stringfield manager structure (and pool) structure to be allocated
as part of a larger structure allocation (using ast_calloc_with_strinfields()); when
this is done, the stringfield pool cannot be separately freed, but users of the tructure
may not be aware (and shouldn't have to be aware) of whether the pool was embedded.
This patch modifies the behavior so that they can always call ast_string_field_free_memory()
and the function will do the right thing for both embedded and non-embedded situations.
Mark Michelson [Thu, 28 May 2009 20:17:24 +0000 (20:17 +0000)]
Treat 405 responses the same way we would a 501.
This makes sure that we mark a method as being unallowed if we
receive a 405 response so that we don't continue to try to
send that same type of message.
Terry Wilson [Thu, 28 May 2009 19:57:18 +0000 (19:57 +0000)]
Add Calendaring support for Asterisk
This commit add Calendaring support to Asterisk for iCalendar, CalDAV, and MS
Exchange calendars. Exchange support has only been tested on Exchange Server 2k3
and does not support forms-based authentication at this time (patches *very*
welcome). Exchange support is also currently missing the ability to return a
list of a meting's attendees (again, patches are very, very welcome).
Features include:
Querying a calendar for events over a specific time range
Checking a calendar's busy status via the dialplan
Writing calendar events via the dialplan (CalDAV and Exchange only)
Handling calendar event notifications through the dialplan
Use the address we already know when reloading a peer with nat=yes.
If we already have an address for a peer, and we are reloading the sip
configuration, try to use that address to contact the peer, instead of
getting it from the Contact.
Tilghman Lesher [Thu, 28 May 2009 15:35:23 +0000 (15:35 +0000)]
Eliminate several needless checks and fix a few memory leaks
(closes issue #14833)
Reported by: contactmayankjain
Patches:
all_changes.patch uploaded by contactmayankjain (license 740)
slightly modified by me
Allow for media to arrive from an alternate source when responding to a reinvite with 491.
When we receive a SIP reinvite, it is possible that we may not be able to process the
reinvite immediately since we have also sent a reinvite out ourselves. The problem is
that whoever sent us the reinvite may have also sent a reinvite out to another party,
and that reinvite may have succeeded.
As a result, even though we are not going to accept the reinvite we just received, it
is important for us to not have problems if we suddenly start receiving RTP from a new
source. The fix for this is to grab the media source information from the SDP of the
reinvite that we receive. This information is passed to the RTP layer so that it will
know about the alternate source for media.
Joshua Colp [Thu, 28 May 2009 15:23:29 +0000 (15:23 +0000)]
Fix an incorrect call to ast_string_field_free_memory which caused a crash in the logger.
Since the message structure is allocated using ast_calloc_with_stringfields we do not need to
free the memory used for the stringfields as it will get freed when the message structure is.
Add flags to chanspy audiohook so that audio stays in sync.
There are two flags being added to the chanspy audiohook here. One
is the pre-existing AST_AUDIOHOOK_TRIGGER_SYNC flag. With this set,
we ensure that the read and write slinfactories on the audiohook do
not skew beyond a certain tolerance.
In addition, there is a new audiohook flag added here,
AST_AUDIOHOOK_SMALL_QUEUE. With this flag set, we do not allow for
a slinfactory to build up a substantial amount of audio before
flushing it. For this particular issue, this means that the person
spying on the call will hear the conversations in real time with very
little delay in the audio.
Fix a bug where the flag indicating the presence of rport would get overwritten by the nat setting.
The presence of rport is now stored as a separate flag. Once the dialog is setup and authenticated
(or it passes through unauthenticated) the proper nat flag is set.
Olle Johansson [Wed, 27 May 2009 20:14:00 +0000 (20:14 +0000)]
Adding some generic handling of error codes sent to us in replys to requests.
Previously they always set hangupcause 0, which is generally wrong. With this
change, we're setting some generic hangup causes. For 5xx errors, which indicate
some sort of problem with the remote server, we're now setting CONGESTION.
Sean Bright [Wed, 27 May 2009 20:08:16 +0000 (20:08 +0000)]
Use bash explicitly when calling build_tools/mkpkgconfig from the Makefile.
Since we use bashisms in build_tools/mkpkgconfig, we should call on bash
explicitly when running from the Makefile, otherwise we get errors during a
'make install.'
Use a different determinator on whether to print the delimiter, since leading fields may be blank.
(closes issue #15208)
Reported by: ramonpeek
Patch by me, though inspired in part by a patch from ramonpeek
........
The bridge was terminating immediately after the attended transfer was
completed. The problem was because upon reentering ast_channel_bridge
nexteventts was checked to see if it was set and if so could possibly
return AST_BRIDGE_COMPLETE.
Fix handling of the 'state_interface' option of the 'queue add member' CLI
command.
This change relates to r184980, which was a backport of the state interface
changes to app_queue from trunk. trunk and all of the 1.6.x branches are not
affected.
'queue add member' allows for specifying an interface to use for device state
when adding a queue member via CLI, but the validation code was not properly
updated to reflect this optional argument.
Sean Bright [Wed, 27 May 2009 13:02:54 +0000 (13:02 +0000)]
Display an error message when chan_alsa fails to load due to a missing
or inaccessible configuration file.
Before this change, when chan_alsa failed to load due to a missing or
inaccessible configuration file, no message would be displayed. With this
change, when chan_alsa fails to load due to a missing or inaccessible
configuration file, a message will be displayed.
(closes issue #14760)
Reported by: Nick_Lewis
Patches:
chan_alsa.c-confload.patch uploaded by Nick (license 657)
Sean Bright [Tue, 26 May 2009 22:38:05 +0000 (22:38 +0000)]
Add ActionID to CoreShowChannel event.
There is inconsistency in how we handle manager responses that are lists of
items and, unfortunately, third parties have come to rely on ActionID being on
every event within those lists instead of just keeping track of the ActionID for
the current response. This change makes CoreShowChannels include the ActionID
with each CoreShowChannel event generated as a result of it being called.
(closes issue #15001)
Reported by: sum
Patches:
patchactionid2.patch uploaded by sum (license 766)
Sean Bright [Tue, 26 May 2009 20:20:08 +0000 (20:20 +0000)]
Include startup and reload date in the CoreStatus manager message.
The CoreStartupTime and CoreReloadTime name/value pairs in the CoreStatus
response message only included the time and not the date. This patch,
inspired by the reporter's patch, adds 2 new fields - CoreStartupDate and
CoreReloadDate - which contain the date portion of these values.
Russell Bryant [Tue, 26 May 2009 18:20:57 +0000 (18:20 +0000)]
Merged revisions 196826 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r196826 | russell | 2009-05-26 13:14:36 -0500 (Tue, 26 May 2009) | 9 lines
Resolve a file handle leak.
The frames here should have always been freed. However, out of luck, there was
never any memory leaked. However, after file streams became reference counted,
this code would leak the file stream for the file being read.
Sean Bright [Sat, 23 May 2009 15:16:59 +0000 (15:16 +0000)]
Fix errors in cdr_custom that cause reference errors when non-CDR variable
substitution is done.
cdr_custom was creating a ast_channel struct directly and passing it into the
core for variable substition. This was fine as long as the format string
contained only calls to the CDR() function. Doing something like ${EPOCH} on
the other hand tried to lock the channel, which would fail and throw an error
because the passed channel hadn't been allocated as an ao2 object. So now we
create the dummy channel with ast_channel_alloc, and everything works as
expected.
projects / thirdparty / asterisk.git / log
