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
(closes issue #14771)
Tested by: lmadsen, twilson, Shivaprakash
Review: https://reviewboard.asterisk.org/r/58
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@197738 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r197537 | mmichelson | 2009-05-28 09:49:13 -0500 (Thu, 28 May 2009) | 21 lines
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.
(closes issue #13745)
Reported by: geoffs
Patches:
13745.patch uploaded by mmichelson (license 60)
Tested by: snblitz
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@197543 65c4cc65-6c06-0410-ace0-fbb531ad65f3
'channel originate ... application <app>' CLI command.
(And yeah, I cleaned up some whitespace in res_clioriginate.c... big whoop,
wanna fight about it!?)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@196758 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A new xml element was created to manage the AMI actions documentation,
using AstXML.
To register a manager action using XML documentation it is now possible
using ast_manager_register_xml().
The CLI command 'manager show command' can be used to show the parsed
documentation.
Example manager xml documentation:
<manager name="ami action name" language="en_US">
<synopsis>
AMI action synopsis.
</synopsis>
<syntax>
<xi:include xpointer="xpointer(...)" /> <-- for ActionID
<parameter name="header1" required="true">
<para>Description</para>
</parameter>
...
</syntax>
<description>
<para>AMI action description</para>
</description>
<see-also>
...
</see-also>
</manager>
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@196308 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds 'const' tags to a number of Asterisk APIs where they are appropriate (where the API already demanded that the function argument not be modified, but the compiler was not informed of that fact). The list includes:
- CLI command handlers
- CLI command handler arguments
- AGI command handlers
- AGI command handler arguments
- Dialplan application handler arguments
- Speech engine API function arguments
In addition, various file-scope and function-scope constant arrays got 'const' and/or 'static' qualifiers where they were missing.
Review: https://reviewboard.asterisk.org/r/251/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@196072 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r195881 | mnicholson | 2009-05-21 10:25:50 -0500 (Thu, 21 May 2009) | 13 lines
This commit prevents cdr records with AST_CDR_FLAG_ANSLOCKED and AST_CDR_FLAG_LOCKED from being updated in certain cases.
This is accomplished by adding two functions to update the answer time and disposition of calls that checks for the proper lock flags. These functions are used in the ast_bridge_call() function so that ForkCDR(A) calls are respected.
This patch also modifies the way ast_bridge_call() chooses the cdr record to base the bridged_cdr on. Previously the first unlocked cdr record would be chosen, now instead the first cdr record is chosen and forked cdr records are moved to the bridge_cdr. This allows the original cdr record and any forked cdr records to be properly updated with answer and end times.
(closes issue #13797)
Reported by: sh0t
Tested by: sh0t
(closes issue #14744)
Reported by: deepesh
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@195882 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds the ability for modules to dynamically create logger levels for their own use; these are named levels just like the built-in levels, and can be directed to any destination that the logger can send any level to, by including their names in logger.conf.
Review: https://reviewboard.asterisk.org/r/244/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@194610 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit adds an API call that can be used to allocate a structure along with this stringfield storage in a single allocation.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@192362 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Under some conditions, the memory allocation for stringfields and ao2 objects would not have supplied valid file/function names for MALLOC_DEBUG tracking, so this commit corrects that.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@192357 65c4cc65-6c06-0410-ace0-fbb531ad65f3
As in previous commits, when channels are allocated (with ast_channel_alloc) or datastores are allocated (with ast_datastore_alloc) properly account for the memory being owned by the caller, instead of the allocator function itself.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@192318 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit modifies the stringfield pool allocator to remember the 'owner' of the stringfield manager the pool is being allocated for, and ensures that pools allocated in the future when fields are populated are owned by that file/function.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@192279 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit ensures that all astobj2 allocated objects are properly accounted for in MALLOC_DEBUG mode by passing down the file/function/line information from the module/function that actually called the astobj2 allocation function.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@192059 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch add a new payload type for information elements, a set
of bit flags. The payload is transported as a 32-bit unsigned integer
but when matching is performed between events and subscribers,
the matching is done by using a bitwise AND instead of numeric value
comparison.
Review: http://reviewboard.asterisk.org/r/242/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@191919 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In discussions today at the Europe Asterisk Developer Meet-Up, we determined that
the event_log was used in only 9 places in the entire tree, and really was not needed
at all. The users have been converted to use LOG_NOTICE, or the messages have been
removed since other messages were already in place that provided the same information.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@191785 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Adds ability for CHANNEL() dialplan function, when used on DAHDI channels,
to temporarily change the number of buffers and/or the buffer policy, and also
to enable, disable, or switch the echo canceller between FAX/data and voice
modes.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@191411 65c4cc65-6c06-0410-ace0-fbb531ad65f3
chan_sip allows for outbound TLS connections, but does not allow the user to specify what protocol to use (default was SSLv2, and still is if this new option is not specified). This patch lets the user pick the SSL/TLS client method for outbound connections in sip.
(closes issue #14770)
Reported by: TheOldSaint
(closes issue #14768)
Reported by: TheOldSaint
Review: http://reviewboard.digium.com/r/240/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@191177 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This branch adds additional methods to dialplan functions, whereby the result
buffers are now dynamic buffers, which can be expanded to the size of any
result. No longer are variable substitutions limited to 4095 bytes of data.
In addition, the common case of needing buffers much smaller than that will
enable substitution to only take up the amount of memory actually needed.
The existing variable substitution routines are still available, but users
of those API calls should transition to using the dynamic-buffer APIs.
Reviewboard: http://reviewboard.digium.com/r/174/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@191140 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ast_tls_read_conf() is a new api call for handling SSL/TLS options across all conf files. Before this change, SSL/TLS options were not consistent. http.conf and manager.conf required the 'ssl' prefix while sip.conf used options with the 'tls' prefix. While the options had different names in different conf files, they all did the exact same thing. Now, instead of mixing 'ssl' or 'tls' prefixes to do the same thing depending on what conf file you're in, all SSL/TLS options use the 'tls' prefix. For example. 'sslenable' in http.conf and manager.conf is now 'tlsenable' which matches what already existed in sip.conf. Since this has the potential to break backwards compatibility, previous options containing the 'ssl' prefix still work, but they are no longer documented in the sample.conf files. The change is noted in the CHANGES file though.
Review: http://reviewboard.digium.com/r/237/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@191028 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r190721 | kpfleming | 2009-04-27 14:29:46 -0500 (Mon, 27 Apr 2009) | 7 lines
Fix 'inconsistent line endings' when autoconf 2.63 is used
Attempt to make configure script regeneration 'safe' using autoconf 2.63, which embeds a bare CR into the script, thus making Subversion complain about inconsistent line endings
This commit changes the MIME type of the configure script to be 'binary' thus making Subversion no longer inspect line endings, and as a bonus 'svn diff' will no longer try to generate diff output for it, which is not generally useful anyway.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190725 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Adds option to specify a private key .pem file when configuring TLS or SSL in AMI, HTTP, and SIP. Before this, the certificate file was used for both the public and private key. It is possible for this file to hold both, but most configurations allow for a separate private key file to be specified. Clarified in .conf files how these options are to be used. The current conf files do not explain how the private key is handled at all, so without knowledge of Asterisk's TLS implementation, it would be hard to know for sure what was going on or how to set it up.
Review: http://reviewboard.digium.com/r/234/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190545 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There seems to be a bug with old versions of g++ that doesn't allow a structure
member to use the name list. Rename list member to group_list in ast_group_info
and change the few places it is used.
(closes issue #14790)
Reported by: stuarth
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190057 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r189601 | dbailey | 2009-04-21 09:00:55 -0500 (Tue, 21 Apr 2009) | 3 lines
Add check in configure script to check for GLOB_NOMAGIC and GLOB_BRACE in glob.h
This allows config.c to compile when linked against uclibc that does not support these parameters
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@189629 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is the companion commit to libpri r732. Service messages are now supported
for switch types 4ess/5ess. A new option service_message_support has been added
to chan_dahdi.conf and is noted in the sample config file. The service message
support is turned off by default. The current implementation relies on AstDB
to keep track of channel state, which allows the statuses to be preserved
across Asterisk restarts. Below is a description of the storage format.
The state and reason for the service state are in the form <state>:<reason>,
where:
<state> ::= { 'O' } // 'O' – Out Of Service
<reason> ::= { '0' | '1' | '2' | '3' }, where:
'0' – No reason (backwards compatibility)
'1' – NEAR END
'2' – FAR END
'3' – both NEAR and FAR END
The new CLI commands to handle channel service state are:
pri service disable channel <chan>
pri service enable channel <chan>
Many people contributed to the development of this functionality. Because I
entered at the very end I do not know the exact history. Special thanks to
all who moved the bug forward one way or another:
cmaj, PCadach, markster, mattf, drmac, MikeJ, serge-v, murf, kanelbullar, Seb7,
tilghman, lmadsen, and especially dhubbard (he answered lots of my questions
and did a large portion of the work)
(closes issue #3450)
Reported by: cmaj
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@188342 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The F option to app_dial has been modified to accept no parameters and perform
the above functionality. I don't see anywhere else that is doing function
overloading, but this really is the best place for this operation because:
- It makes it close to the 'g' option in the argument list which provides
similar functionality.
- The existing code to support the current F option provides a very
convienient location to add this new feature.
(closes issue #12381)
Reported by: michael-fig
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@187491 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This was accomplished using a set of options and the setoption channel callback.
The core calls into the channel driver using these options and the channel driver
either returns success or failure.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@187360 65c4cc65-6c06-0410-ace0-fbb531ad65f3
(inspired by this evening's Toronto Asterisk Users Group meeting and previous dicussions amongst various community members)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@187269 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The biggest change done here was elimination of the backup_config for use with
features. Previously, the bridging code upon detecting a feature would set the
start time of the bridge to the start time of the feature. Then after the
feature had either expired or timed out the start time would be reset to the
true bridge start time from the backup_config. Now, the time differences are
calculated with respect to the newly added feature_start_time timeval instead.
There should be no behavior changes from the previous functionality aside from
the bridge timing being unaffected by either valid or partial feature matches.
Previously the timing would be increased by the length of time configured for
featuredigittimeout, which was probably never noticed.
(closes issue #14503)
Reported by: KNK
Tested by: jpeeler
Review: http://reviewboard.digium.com/r/179/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@187211 65c4cc65-6c06-0410-ace0-fbb531ad65f3
doxyref.h was created to hold miscellaneous documentation that was not specific
to a part of the code. This file has grown quite a bit so I decided to start
splitting parts of it out into new files. Now, you can drop a new file into
include/asterisk/doxygen/ and it will be processed by doxygen.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@186953 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The channel drivers which have been most heavily tested with these enhancements are
chan_sip and chan_misdn. Further work is being done to add Q.SIG support and will be
introduced in a later commit. chan_skinny has code added to it here, but according
to user pj, the support on chan_skinny is not working as of now. This will be fixed in
a later commit.
A special thanks goes out to bugtracker user gareth for getting the ball rolling and
providing the initial support for this work. Without his initial work on this, this would
not have been nearly as painless as it was.
This functionality has been tested by Digium's product quality department, as well as a
customer site running thousands of calls every day. In addition, many many many many bugtracker
users have tested this, too.
(closes issue #8824)
Reported by: gareth
Review: http://reviewboard.digium.com/r/201
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@186525 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This API call now waits for a special frame from the underlying channel driver to
indicate success or failure. This allows the return value to truly convey whether
the transfer worked or not. In the case of the Transfer() dialplan application this
means the value of the TRANSFERSTATUS dialplan variable is actually true.
(closes issue #12713)
Reported by: davidw
Tested by: file
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@186382 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This API provides a generic way for multiple RTP stacks to be
integrated into Asterisk. Right now there is only one present, res_rtp_asterisk,
which is the existing Asterisk RTP stack. Functionality wise this commit
performs the same as previously. API documentation can be viewed in the
rtp_engine.h header file.
Review: http://reviewboard.digium.com/r/209/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@186078 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch provides a number of optimizations to the stringfields API, focused around saving (not wasting) memory whenever possible. Thanks to Mark Michelson for inspiring this work and coming up with the first two optimizations that are represented here:
Changes:
- Cleanup of some code, fix incorrect doxygen comments
- When a field is emptied or replaced with a new allocation, decrease the amount of 'active' space in the pool it was held in; if that pool reaches zero active space, and is not the current pool, then free it as it is no longer in use
- When allocating a pool, try to allocate a size that will fit in a 'standard' malloc() allocation without wasting space
- When allocating space for a field, store the amount of space in the two bytes immediately preceding the field; this eliminates the need to call strlen() on the field when overwriting it, and more importantly it 'remembers' the amount of space the field has available, even if a shorter string has been stored in it since it was allocated
- Don't automatically double the size of each successive pool allocated; it's wasteful
http://reviewboard.digium.com/r/165/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@185581 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The doxygen documentation has now been updated to state explicitly that I want
punctuation atthe end of the first sentence in a commit message. :).
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@184798 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The ability to load/unload timing interfaces is nice, but it means that when a timer is allocated, it may come from provider A, but later provider B becomes the 'preferred' provider. If this happens, all timer API calls on the timer that was provided by provider A will actually be handed to provider B, which will say WTF and return an error.
This patch changes the timer API to include a pointer to the provider of the timer handle so that future operations on the timer will be forwarded to the proper provider.
(closes issue #14697)
Reported by: moy
Review: http://reviewboard.digium.com/r/211/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@184762 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When dvossel and I were doing some load testing last week, we noticed that we
could make Asterisk trunk lock up instantly when we started generating a bunch
of calls. The backtraces of locked threads were bizarre, and many were stuck
on an _unlock_ of an rwlock.
The changes are:
1) Fix a number of places where a backtrace would be loaded into an invalid
index of the backtrace array. It's an off by one error, which ends up
writing over the rwlock itself.
2) Ensure that in the array of held locks, we NULL out an index once it is
not being used so that it's not confusing when analyzing its contents.
3) Remove a bunch of logging referring to an rwlock operating being done
with "deep reentrancy". It is normal for _many_ threads to hold a
read lock on an rwlock.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@184531 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This code comes from svn/asterisk/team/russell/event_performance/.
Here is a summary of the changes that have been made, in order of both
invasiveness and performance impact, from smallest to largest.
1) Asterisk 1.6.1 introduces some additional logic to be able to handle
distributed device state. This functionality comes at a cost.
One relatively minor change in this patch is that the extra processing
required for distributed device state is now completely bypassed if
it's not needed.
2) One of the things that I noticed when profiling this code was that a
_lot_ of time was spent doing string comparisons. I changed the way
strings are represented in an event to include a hash value at the front.
So, before doing a string comparison, we do an integer comparison on the
hash.
3) Finally, the code that handles the event cache has been re-written.
I tried to do this in a such a way that it had minimal impact on the API.
I did have to change one API call, though - ast_event_queue_and_cache().
However, the way it works now is nicer, IMO. Each type of event that
can be cached (MWI, device state) has its own hash table and rules for
hashing and comparing objects. This by far made the biggest impact on
performance.
For additional details regarding this code and how it was tested, please see the
review request.
(closes issue #14738)
Reported by: russell
Review: http://reviewboard.digium.com/r/205/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@184339 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r183386 | dvossel | 2009-03-19 14:40:07 -0500 (Thu, 19 Mar 2009) | 6 lines
Cleaning up a few things in detect disconnect patch
Initialized ast_call_feature in detect_disconnect to avoid accessing uninitialized memory. Cleaned up /param tags in features.h. No longer send dynamic features in ast_feature_detect.
issue #11583
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@183436 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r183126 | dvossel | 2009-03-19 11:15:16 -0500 (Thu, 19 Mar 2009) | 17 lines
Allow disconnect feature before a call is bridged
feature.conf has a disconnect option. By default this option is set to '*', but it could be anything. If a user wishes to disconnect a call before the other side answers, only '*' will work, regardless if the disconnect option is set to something else. This is because features are unavailable until bridging takes place. The default disconnect option, '*', was hardcoded in app_dial, which doesn't make any sense from a user perspective since they may expect it to be something different. This patch allows features to be detected from outside of the bridge, but not operated on. In this case, the disconnect feature can be detected before briding and handled outside of features.c.
(closes issue #11583)
Reported by: sobomax
Patches:
patch-apps__app_dial.c uploaded by sobomax (license 359)
11583.latest-patch uploaded by murf (license 17)
detect_disconnect.diff uploaded by dvossel (license 671)
Tested by: sobomax, dvossel
Review: http://reviewboard.digium.com/r/195/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@183172 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r182810 | russell | 2009-03-17 21:09:13 -0500 (Tue, 17 Mar 2009) | 44 lines
Fix cases where the internal poll() was not being used when it needed to be.
We have seen a number of problems caused by poll() not working properly on
Mac OSX. If you search around, you'll find a number of references to using
select() instead of poll() to work around these issues. In Asterisk, we've
had poll.c which implements poll() using select() internally. However, we
were still getting reports of problems.
vadim investigated a bit and realized that at least on his system, even
though we were compiling in poll.o, the system poll() was still being used.
So, the primary purpose of this patch is to ensure that we're using the
internal poll() when we want it to be used.
The changes are:
1) Remove logic for when internal poll should be used from the Makefile.
Instead, put it in the configure script. The logic in the configure
script is the same as it was in the Makefile. Ideally, we would have
a functionality test for the problem, but that's not actually possible,
since we would have to be able to run an application on the _target_
system to test poll() behavior.
2) Always include poll.o in the build, but it will be empty if AST_POLL_COMPAT
is not defined.
3) Change uses of poll() throughout the source tree to ast_poll(). I feel
that it is good practice to give the API call a new name when we are
changing its behavior and not using the system version directly in all cases.
So, normally, ast_poll() is just redefined to poll(). On systems where
AST_POLL_COMPAT is defined, ast_poll() is redefined to ast_internal_poll().
4) Change poll() in main/poll.c to be ast_internal_poll().
It's worth noting that any code that still uses poll() directly will work fine
(if they worked fine before). So, for example, out of tree modules that are
using poll() will not stop working or anything. However, for modules to work
properly on Mac OSX, ast_poll() needs to be used.
(closes issue #13404)
Reported by: agalbraith
Tested by: russell, vadim
http://reviewboard.digium.com/r/198/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@182847 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r182808 | kpfleming | 2009-03-17 20:55:22 -0500 (Tue, 17 Mar 2009) | 5 lines
Improve the build system to *properly* remove unnecessary symbols from the runtime global namespace. Along the way, change the prefixes on some internal-only API calls to use a common prefix.
With these changes, for a module to export symbols into the global namespace, it must have *both* the AST_MODFLAG_GLOBAL_SYMBOLS flag and a linker script that allows the linker to leave the symbols exposed in the module's .so file (see res_odbc.exports for an example).
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@182826 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ast_answer(), when supplied a delay before returning to the caller, use ast_safe_sleep() to implement the delay. Unfortunately during this time any incoming frames are discarded, which is problematic for T.38 re-INVITES and other sorts of channel operations.
When a delay is not passed to ast_answer(), it still delays for up to 500 milliseconds, waiting for media to arrive. Again, though, it discards any control frames, or non-voice media frames.
This patch rectifies this situation, by storing all incoming frames during the delay period on a list, and then requeuing them onto the channel before returning to the caller.
http://reviewboard.digium.com/r/196/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@182525 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit introduces official support for R2 signaling in chan_dahdi. The
modifications to chan_dahdi, and the supporting library, LibOpenR2, were both
written by Moises Silva.
Many users are using this code, or a variant of it, in Asterisk 1.2, 1.4 and 1.6
in Brazil, México and Argentina. An unknown number of users (but at least 1)
are using it in each of the following countries: Colombia, Nepal, Thailand,
Venezuela, Perú, and probably others.
To use this code, LibOpenR2 must be installed from http://www.libopenr2.org/.
Information about configuration can be found in configs/chan_dahdi.conf.sample.
The code committed is the most up to date version, which was being maintained
in svn/asterisk/team/moy/mfcr2/.
I would also like to include a Thank You to the many others that tested this
code beyond those listed in this commit message. These are the names that I
could find in the mantis issue.
(closes issue #12509)
Reported by: moy
Patches:
chan_zap-mfr2.patch uploaded by moy (license 222)
Tested by: moy, korihor, viniciusfontes, Skarmeth, loloski, asbestoshead, titogarrido, heliocoelhojr, konsultex, ncorrare, ecarruda, rtorresduque, PTorres, ychen
Review: http://reviewboard.digium.com/r/40/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@182355 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The main problem here was that cstdlib was undefining free thereby causing the
proper debug macros to not be used. ast_h323.cxx has been changed to call
ast_free instead to avoid the issue.
A few other issues were addressed:
- There were a few instances of functions improperly passing ast_free instead
of ast_free_ptr.
- Some clean up was done to avoid the debug macros intentionally being redefined.
(copied below from Kevin's commit, appreciate the help)
- disable astmm.h from doing anything when STANDALONE is defined, which is used
by the tools in the utils/ directory that use parts of Asterisk header files in
hackish ways; also ensure that utils/extconf.c and utils/conf2ael.c are
compiled with STANDALONE defined.
(closes issue #13593)
Reported by: pj
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@181135 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Copied from my review board description:
This is a continuation of the API changes documentation started for describing
changes between releases. Most of the API changes were pretty simple needing
only to be brought to attention via the new "Asterisk API Changes" list.
However, if you see anything that needs further explanation feel free to
supplement what is there. The current method of documenting is to add (in the
header file): \version <ver number> <description of changes> and then to add
the function to the change list in doxyref.h on the AstAPIChanges page. I also
made sure all the functions that were newly added were tagged with \since
1.6.1. I think this is a good habit to start both for the historical aspect as
well as for the future ability to easily add a "New Asterisk API" page.
Review: http://reviewboard.digium.com/r/190/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@180719 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r180372 | kpfleming | 2009-03-05 12:22:16 -0600 (Thu, 05 Mar 2009) | 9 lines
Fix problems when RTP packet frame size is changed
During some code analysis, I found that calling ast_rtp_codec_setpref() on an ast_rtp session does not work as expected; it does not adjust the smoother that may on the RTP session, in fact it summarily drops it, even if it has data in it, even if the current format's framing size has not changed. This is not good.
This patch changes this behavior, so that if the packetization size for the current format changes, any existing smoother is safely updated to use the new size, and if no smoother was present, one is created. A new API call for smoothers, ast_smoother_reconfigure(), was required to implement these changes.
Review: http://reviewboard.digium.com/r/184/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@180373 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit brings in the bridging core, bridging technologies,
and the ConfBridge application.
For usage information on the ConfBridge application please see
the output of "core show application ConfBridge" from the CLI.
For API documentation please see the doxygen page describing the
architecture and the documentation for each API call.
Review: http://reviewboard.digium.com/r/93/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@180369 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In app.c, ast_app_getdata is called to stream the prompts and receive DTMF input. If ast_app_getdata() receives an empty string caused by the user inputing the end of string character, in this case '#', it should break from the prompt loop and return to app_read, but instead it cycles through all the prompts. I've added a return value for this special case in ast_readstring() which uses an enum I've delcared in apps.h. This enum is now used as a return value for ast_app_getdata().
(closes issue #14279)
Reported by: Marquis
Patches:
fix_app_read.patch uploaded by Marquis (license 32)
read-ampersanmd.patch2 uploaded by dvossel (license 671)
Tested by: Marquis, dvossel
Review: http://reviewboard.digium.com/r/177/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@180032 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r176701 | jpeeler | 2009-02-17 15:54:34 -0600 (Tue, 17 Feb 2009) | 17 lines
Modify bridging to properly evaluate DTMF after first warning is played
The main problem is currently if the Dial flag L is used with a warning sound,
DTMF is not evaluated after the first warning sound. To fix this, a flag has
been added in ast_generic_bridge for playing the warning which ensures that if
a scheduled warning is missed, multiple warrnings are not played back (due to a
feature evaluation or waiting for digits). ast_channel_bridge was modified to
store the nexteventts in the ast_bridge_config structure as that information
was lost every time ast_channel_bridge was reentered, causing a hangup due to
incorrect time calculations.
(closes issue #14315)
Reported by: tim_ringenbach
Reviewed on reviewboard:
http://reviewboard.digium.com/r/163/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@176708 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1) Add module use count handling so that timing modules can be unloaded.
2) Implement unload_module() functions for the timing interface modules.
3) Allow multiple timing modules to be loaded, and use the one with the
highest priority value.
4) Report which timing module is being use in the "timing test" CLI command.
(closes issue #14489)
Reported by: russell
Review: http://reviewboard.digium.com/r/162/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@176666 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch includes a number of changes to the indications API. The primary
motivation for this work was to improve stability. The object management
in this API was significantly flawed, and a number of trivial situations could
cause crashes.
The changes included are:
1) Remove the module res_indications. This included the critical functionality
that actually loaded the indications configuration. I have seen many people
have Asterisk problems because they accidentally did not have an
indications.conf present and loaded. Now, this code is in the core,
and Asterisk will fail to start without indications configuration.
There was one part of res_indications, the dialplan applications, which did
belong in a module, and have been moved to a new module, app_playtones.
2) Object management has been significantly changed. Tone zones are now
managed using astobj2, and it is no longer possible to crash Asterisk by
issuing a reload that destroys tone zones while they are in use.
3) The API documentation has been filled out.
4) The API has been updated to follow our naming conventions.
5) Various bits of code throughout the tree have been updated to account
for the API update.
6) Configuration parsing has been mostly re-written.
7) "Code cleanup"
The code is from svn/asterisk/team/russell/indications/.
Review: http://reviewboard.digium.com/r/149/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@176627 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r176216 | kpfleming | 2009-02-16 15:10:38 -0600 (Mon, 16 Feb 2009) | 3 lines
fix a flaw in the ast_string_field_build() family of API calls; these functions made no attempt to reuse the space already allocated to a field, so every time the field was written it would allocate new space, leading to what appeared to be a memory leak.
........
r176254 | kpfleming | 2009-02-16 15:41:46 -0600 (Mon, 16 Feb 2009) | 3 lines
correct a logic error in the last stringfields commit... don't mark additional space as allocated if the string was built using already-allocated space
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@176255 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1) It had numerous coding guidelines violations with regards to formatting.
2) It allocated memory using ast_calloc() that was never freed.
3) It didn't check for failure from the allocation.
4) It used sprintf() and strcat() to build the result, doing zero checking to
prevent writing past the end of the provided buffer.
The function also lacks API documentation, but that has not been addressed in
this commit.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@175829 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds passthrough, file recording and file playback support for the codecs listed above, with negotiation over SIP/SDP supported. Due to Asterisk's current limitation of treating a codec/bitrate combination as a unique codec, only G.722.1 at 32 kbps and G.722.1C at 48 kbps are supported.
Along the way, some related work was done:
1) The rtpPayloadType structure definition, used as a return result for an API call in rtp.h, was moved from rtp.c to rtp.h so that the API call was actually usable. The only previous used of the API all was chan_h323.c, which had a duplicate of the structure definition instead of doing it the right way.
2) The hardcoded SDP sample rates for various codecs in chan_sip.c were removed, in favor of storing these sample rates in rtp.c along with the codec definitions there. A new API call was added to allow retrieval of the sample rate for a given codec.
3) Some basic 'a=fmtp' parsing for SDP was added to chan_sip, because chan_sip *must* decline any media streams offered for these codecs that are not at the bitrates that we support (otherwise Bad Things (TM) would result).
Review: http://reviewboard.digium.com/r/158/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@175508 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Core show locks information involving an ao2_trylock did not
show the function that called ao2_trylock, but would instead
show ao2_trylock as the source of the lock. This is not useful
when trying to debug locking issues.
One bizarre note is that this logic is already in 1.4 but somehow
did not get merged to trunk or the 1.6.X branches.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@175121 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The 'd' option would not work for channel types which use RTP to transport
DTMF digits. The only way to allow for this to work was to answer the channel
if we saw that this option was enabled.
I realized that this may cause issues with CDRs, specifically with giving false
dispositions and answer times. I therefore modified ast_answer to take another
parameter which would tell if the CDR should be marked answered.
I also extended this to the Answer application so that the channel may be answered
but not CDRified if desired.
I also modified app_dictate and app_waitforsilence to only answer the channel if it
is not already up, to help not allow for faulty CDR answer times.
All of these changes are going into Asterisk trunk. For 1.6.0 and 1.6.1, however, all
the changes except for the change to the Answer application will go in since we do
not introduce new features into stable branches
(closes issue #14164)
Reported by: DennisD
Patches:
14164.patch uploaded by putnopvut (license 60)
Tested by: putnopvut
Review: http://reviewboard.digium.com/r/145
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@174945 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit expands the Asterisk scheduler API to include a common implementation
of a scheduler context being processed by a dedicated thread. chan_iax2 has been
updated to use this new code. Also, as a result, this resolves some race
conditions related to the previous chan_iax2 scheduler handling.
Related to rev 171452 which resolved the same issues in 1.4.
Code from team/russell/sched_thread2
Review: http://reviewboard.digium.com/r/129/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@173858 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r173211 | jpeeler | 2009-02-03 15:57:01 -0600 (Tue, 03 Feb 2009) | 17 lines
Parking attempts made to one end of a bridge no longer will hang up due to a
parking failure.
Parking attempts made using either one-touch, or doing either a blind or
assisted transfer to the parking extension now keep up the bridge instead of
hanging up the attempted parked party. Normal causes for the parking attempt
to fail includes the specific specified extension (via PARKINGEXTEN) not being
available or if all the parking spaces are currently in use. To avoid having
to reverse a masquerade park_space_reserve was made to provide foresight if
a parking attempt will succeed and if so reserve the parking space.
(closes issue #13494)
Reported by: mdu113
Reviewed by Russell: http://reviewboard.digium.com/r/133/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@173500 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2. Use curl to download sound files, as curl is installed natively on OS X,
whereas wget and fetch are not.
(closes issue #14332)
Reported by: oej
Tested by: Corydon76
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@173130 65c4cc65-6c06-0410-ace0-fbb531ad65f3
to be used within the dial app, before a call is bridged.
Many thanks to sobomax for submitting this patch.
Quoting from bug 11582:
"So the goal of the patch was to use the user configured feature code during the
call setup phase. The original ast_feature_interpret() function is not well suited
for this purpose as it uses much call bridge specific data and doesn't separate a
detection of feature from a feature handler call. So a new function ast_feature_detect()
has been extracted off the ast_feature_interpret() function but keeping the original
logic intact except some insignificant changes to locking.
"Having created the ast_feature_detect() function the possibility to use feature detection
in almost any place of the asterisk code. So a call to this function has been added to
wait_for_answer() function of app_dial.so module. This code doesn't call the feature handler
however and uses old call leg disconnect logic to make the changes as small and simple as
possible to prevent unexpected problems. A disconnect feature currently is the only one
supported during call setup as other features as call parking and call transfer don't make much
sense during call setup. However if need in some of the features would arise it is much easier to
implement as the infrastructure changes are already in place with this patch."
I have cleaned up the patch somewhat, and verified that the existing functionality is not
harmed, and that the new functionality works. Terry has committed his stuff, and there were
no conflicts (see 14274).
(closes issue #11583)
Reported by: sobomax
Patches:
patch-apps__app_dial.c uploaded by sobomax (license 359)
patch-include__asterisk__features.h uploaded by sobomax (license 359)
patch-res__res_features.c uploaded by sobomax (license 359)
enable-features-during-call-setup.diff uploaded by sobomax (license 359)
11583.newdiff uploaded by murf (license 17)
enable-features-during-call-setup-1.diff uploaded by sobomax (license 359)
11583.latest-patch uploaded by murf (license 17)
Tested by: sobomax, murf
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172890 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172517 | twilson | 2009-01-30 11:47:41 -0600 (Fri, 30 Jan 2009) | 37 lines
Fix feature inheritance with builtin features
When using builtin features like parking and transfers, the AST_FEATURE_* flags
would not be set correctly for all instances when either performing a builtin
attended transfer, or parking a call and getting the timeout callback. Also,
there was no way on a per-call basis to specify what features someone should
have on picking up a parked call (since that doesn't involve the Dial() command).
There was a global option for setting whether or not all users who pickup a
parked call should have AST_FEATURE_REDIRECT set, but nothing for DISCONNECT,
AUTOMON, or PARKCALL.
This patch:
1) adds the BRIDGE_FEATURES dialplan variable which can be set either in the
dialplan or with setvar in channels that support it. This variable can be set
to any combination of 't', 'k', 'w', and 'h' (case insensitive matching of the
equivalent dial options), to set what features should be activated on this
channel. The patch moves the setting of the features datastores into the
bridging code instead of app_dial to help facilitate this.
2) adds global options parkedcallparking, parkedcallhangup, and
parkedcallrecording to be similar to the parkedcalltransfers option for
globally setting features.
3) has builtin_atxfer call builtin_parkcall if being transfered to the parking
extension since tracking everything through multiple masquerades, etc. is
difficult and error-prone
4) attempts to fix all cases of return calls from parking and completed builtin
transfers not having the correct permissions
(closes issue #14274)
Reported by: aragon
Patches:
fix_feature_inheritence.diff.txt uploaded by otherwiseguy (license 396)
Tested by: aragon, otherwiseguy
Review http://reviewboard.digium.com/r/138/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172580 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Also, implement a private cause code (as suggested by Tilghman). This works with
chan_sip, but doesn't propagate through chan_local.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172318 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- Also, change a function in app.c to return a userful value instead of always returning 0.
Patch by fnordian, changed by Corydon76 and myself.
This does not close the bug report, as fnordian had an additional change we're still discussing.
(related to issue #14059)
Reported by: fnordian
Patches:
chan_sip_hfield.patch uploaded by fnordian (license 110)
20090116__bug14059.diff.txt uploaded by Corydon76 (license 14)
Tested by: fnordian, Corydon76, oej
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172268 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172030 | murf | 2009-01-28 11:51:16 -0700 (Wed, 28 Jan 2009) | 46 lines
This patch fixes h-exten running misbehavior in manager-redirected
situations.
What it does:
1. A new Flag value is defined in include/asterisk/channel.h,
AST_FLAG_BRIDGE_HANGUP_DONT, which used as a messenge to the
bridge hangup exten code not to run the h-exten there (nor
publish the bridge cdr there). It will done at the pbx-loop
level instead.
2. In the manager Redirect code, I set this flag on the channel
if the channel has a non-null pbx pointer. I did the same for the
second (chan2) channel, which gets run if name2 is set...
and the first succeeds.
3. I restored the ending of the cdr for the pbx loop h-exten
running code. Don't know why it was removed in the first place.
4. The first attempt at the fix for this bug was to place code
directly in the async_goto routine, which was called from a
large number of places, and could affect a large number of
cases, so I tested that fix against a fair number of transfer
scenarios, both with and without the patch. In the process,
I saw that putting the fix in async_goto seemed not to affect
any of the blind or attended scenarios, but still, I was
was highly concerned that some other scenarios I had not tested
might be negatively impacted, so I refined the patch to
its current scope, and jmls tested both. In the process, tho,
I saw that blind xfers in one situation, when the one-touch
blind-xfer feature is used by the peer, we got strange
h-exten behavior. So, I inserted code to swap CDRs and
to set the HANGUP_DONT field, to get uniform behavior.
5. I added code to the bridge to obey the HANGUP_DONT flag,
skipping both publishing the bridge CDR, and running
the h-exten; they will be done at the pbx-loop (higher)
level instead.
6. I removed all the debug logs from the patch before committing.
7. I moved the AUTOLOOP set/reset in the h-exten code in res_features
so it's only done if the h-exten is going to be run. A very
minor performance improvement, but technically correct.
(closes issue #14241)
Reported by: jmls
Patches:
14241_redirect_no_bridgeCDR_or_h_exten_via_transfer uploaded by murf (license 17)
Tested by: murf, jmls
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172063 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When the second part of this macro is written as 0[a] instead of a[0], it will
force a failure if the macro is used on a C++ object that overloads the []
operator.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@170943 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r169943 | tilghman | 2009-01-21 18:43:31 -0600 (Wed, 21 Jan 2009) | 9 lines
AST_RWLOCK_INIT_VALUE is always defined. What we really wanted to ask is
whether autoconf detected a static initializer value. This fixes rwlocks
on all such platforms (mainly, Mac OS X).
(closes issue #13767)
Reported by: jcovert
Patches:
20090121__bug13767.diff.txt uploaded by Corydon76 (license 14)
Tested by: jcovert, Corydon76
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@169944 65c4cc65-6c06-0410-ace0-fbb531ad65f3
along the way fix some minor coding style issues in strings.h and add some attribute_pure annotations to functions in the ast_str API
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@169438 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
In order to merge this 1.4 patch into trunk,
I had to resolve some conflicts and wait for
Russell to make some changes to res_agi.
I re-ran all the tests; 39 calls in all, and
made fairly careful notes and comparisons: I
don't want this to blow up some aspect of
asterisk; I completely removed the KEEPALIVE
from the pbx.h decls. The first 3 scenarios
involving feature park; feature xfer to 700;
hookflash park to Park() app call all behave
the same, don't appear to leave hung channels,
and no crashes.
........
r166093 | murf | 2008-12-19 15:30:32 -0700 (Fri, 19 Dec 2008) | 131 lines
This merges the masqpark branch into 1.4
These changes eliminate the need for (and use of)
the KEEPALIVE return code in res_features.c;
There are other places that use this result code
for similar purposes at a higher level, these appear
to be left alone in 1.4, but attacked in trunk.
The reason these changes are being made in 1.4, is
that parking ends a channel's life, in some situations,
and the code in the bridge (and some other places),
was not checking the result code properly, and dereferencing
the channel pointer, which could lead to memory corruption
and crashes.
Calling the masq_park function eliminates this danger
in higher levels.
A series of previous commits have replaced some parking calls
with masq_park, but this patch puts them ALL to rest,
(except one, purposely left alone because a masquerade
is done anyway), and gets rid of the code that tests
the KEEPALIVE result, and the NOHANGUP_PEER result codes.
While bug 13820 inspired this work, this patch does
not solve all the problems mentioned there.
I have tested this patch (again) to make sure I have
not introduced regressions.
Crashes that occurred when a parked party hung up
while the parking party was listening to the numbers
of the parking stall being assigned, is eliminated.
These are the cases where parking code may be activated:
1. Feature one touch (eg. *3)
2. Feature blind xfer to parking lot (eg ##700)
3. Run Park() app from dialplan (eg sip xfer to 700)
(eg. dahdi hookflash xfer to 700)
4. Run Park via manager.
The interesting testing cases for parking are:
I. A calls B, A parks B
a. B hangs up while A is getting the numbers announced.
b. B hangs up after A gets the announcement, but
before the parking time expires
c. B waits, time expires, A is redialed,
A answers, B and A are connected, after
which, B hangs up.
d. C picks up B while still in parking lot.
II. A calls B, B parks A
a. A hangs up while B is getting the numbers announced.
b. A hangs up after B gets the announcement, but
before the parking time expires
c. A waits, time expires, B is redialed,
B answers, A and B are connected, after
which, A hangs up.
d. C picks up A while still in parking lot.
Testing this throroughly involves acting all the permutations
of I and II, in situations 1,2,3, and 4.
Since I added a few more changes (ALL references to KEEPALIVE in the bridge
code eliimated (I missed one earlier), I retested
most of the above cases, and no crashes.
H-extension weirdness.
Current h-extension execution is not completely
correct for several of the cases.
For the case where A calls B, and A parks B, the
'h' exten is run on A's channel as soon as the park
is accomplished. This is expected behavior.
But when A calls B, and B parks A, this will be
current behavior:
After B parks A, B is hung up by the system, and
the 'h' (hangup) exten gets run, but the channel
mentioned will be a derivative of A's...
Thus, if A is DAHDI/1, and B is DAHDI/2,
the h-extension will be run on channel
Parked/DAHDI/1-1<ZOMBIE>, and the
start/answer/end info will be those
relating to Channel A.
And, in the case where A is reconnected to
B after the park time expires, when both parties
hang up after the joyful reunion, no h-exten
will be run at all.
In the case where C picks up A from the
parking lot, when either A or C hang up,
the h-exten will be run for the C channel.
CDR's are a separate issue, and not addressed
here.
As to WHY this strange behavior occurs,
the answer lies in the procedure followed
to accomplish handing over the channel
to the parking manager thread. This procedure
is called masquerading. In the process,
a duplicate copy of the channel is created,
and most of the active data is given to the
new copy. The original channel gets its name
changed to XXX<ZOMBIE> and keeps the PBX
information for the sake of the original
thread (preserving its role as a call
originator, if it had this role to begin
with), while the new channel is without
this info and becomes a call target (a
"peer").
In this case, the parking lot manager
thread is handed the new (masqueraded)
channel. It will not run an h-exten
on the channel if it hangs up while
in the parking lot. The h exten will
be run on the original channel instead,
in the original thread, after the bridge
completes.
See bug 13820 for our intentions as
to how to clean up the h exten behavior.
Review: http://reviewboard.digium.com/r/29/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@166665 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch introduces a function to do careful writes on a file stream which
will handle timeouts and partial writes. It is currently used in AMI to
address the issue that has been reported. However, there are probably a few
other places where this could be used.
(closes issue #13546)
Reported by: srt
Tested by: russell
http://reviewboard.digium.com/r/104/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@166282 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This function is being added as a method to allow for
an audiohook to move to a new channel during a channel
masquerade. The most obvious use for such a facility is
for MixMonitor when a transfer is performed. Prior to
the addition of this functionality, if a channel
running MixMonitor was transferred by another party, then
the recording would stop once the transfer had completed.
By using AUDIOHOOK_INHERIT, you can make MixMonitor
continue recording the call even after the transfer
has completed.
It has also been determined that since this is seen
by most as a bug fix and is not an invasive change,
this functionality will also be backported to 1.4 and
merged into the 1.6.0 branches, even though they are
feature-frozen.
(closes issue #13538)
Reported by: mbit
Patches:
13538.patch uploaded by putnopvut (license 60)
Tested by: putnopvut
Review: http://reviewboard.digium.com/r/102/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@166092 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This documents the recommended outline to use for commit message. It also
covers information on special tags that can be used in commit messages, as well
as the template functionality that is available on bugs.digium.com.
Review: http://reviewboard.digium.com/r/96/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@165883 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is part of an effort to completely remove AST_PBX_KEEPALIVE and other
similar return codes from the source. While this usage was perfectly safe,
there are others that are problematic. Since we know ahead of time that
we do not want to PBX to destroy the channel, the PBX API has been changed
so that information can be provided as an argument, instead, thus removing
the need for the KEEPALIVE return value.
Further changes to get rid of KEEPALIVE and related code is being done by
murf. There is a patch up for that on review 29.
Review: http://reviewboard.digium.com/r/98/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@165723 65c4cc65-6c06-0410-ace0-fbb531ad65f3
access 'struct ast_str' members, but this must only be used inside the API implementation.
(closes issue #14098)
Reported by: eliel
Patches:
ast_str.patch uploaded by eliel (license 64)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@165502 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r164736 | russell | 2008-12-16 11:06:29 -0600 (Tue, 16 Dec 2008) | 14 lines
Fix memory leak and invalid reporting issues with DEBUG_THREADLOCALS.
One issue was that the ast_mutex_* API was being used within the context of the
thread local data destructors. We would go off and allocate more thread local data
while the pthread lib was in the middle of destroying it all. This led to a memory
leak.
Another issue was an invalid argument being provided to the the object_add
API call.
(closes issue #13678)
Reported by: ys
Tested by: Russell
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@164737 65c4cc65-6c06-0410-ace0-fbb531ad65f3
on a 64-bit machine running ubuntu server 8.10,
and gcc-4.3.2:
[CXXi] chan_vpb.ii -> chan_vpb.oo
cc1plus: warnings being treated as errors
In file included from /home/murf/asterisk/trunk/include/asterisk/utils.h:671,
from chan_vpb.cc:46:
/home/murf/asterisk/trunk/include/asterisk/strings.h: In function ‘char* ast_str_truncate(ast_str*, ssize_t)’:
/home/murf/asterisk/trunk/include/asterisk/strings.h:479: error: comparison between signed and unsigned integer expressions
make[1]: *** [chan_vpb.oo] Error 1
make: *** [channels] Error 2
which this fix silences
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@164415 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r163448 | russell | 2008-12-12 07:44:08 -0600 (Fri, 12 Dec 2008) | 26 lines
Resolve issues that could cause DTMF to be processed out of order.
These changes come from team/russell/issue_12658
1) Change autoservice to put digits on the head of the channel's frame readq
instead of the tail. If there were frames on the readq that autoservice
had not yet read, the previous code would have resulted in out of order
processing. This required a new API call to queue a frame to the head
of the queue instead of the tail.
2) Change up the processing of DTMF in ast_read(). Some of the problems
were the result of having two sources of pending DTMF frames. There
was the dtmfq and the more generic readq. Both were used for pending
DTMF in various scenarios. Simplifying things to only use the frame
readq avoids some of the problems.
3) Fix a bug where a DTMF END frame could get passed through when it
shouldn't have. If code set END_DTMF_ONLY in the middle of digit emulation,
and a digit arrived before emulation was complete, digits would get
processed out of order.
(closes issue #12658)
Reported by: dimas
Tested by: russell, file
Review: http://reviewboard.digium.com/r/85/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@163449 65c4cc65-6c06-0410-ace0-fbb531ad65f3
After the nightly update of the documentation on asterisk.org, I'll post
an update to asterisk-dev with a pointer to the changes. This covers some
release branch and commit policy information. None of this should be a
surprise, since it's just documenting what we have already been doing.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@162418 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r162413 | russell | 2008-12-09 16:17:39 -0600 (Tue, 09 Dec 2008) | 8 lines
Remove the test_for_thread_safety() function completely.
The test is not valid. Besides, if we actually suspected that recursive
mutexes were not working, we would get a ton of LOG_ERROR messages when
DEBUG_THREADS is turned on.
(inspired by a discussion on the asterisk-dev list)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@162414 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r162013 | murf | 2008-12-09 09:31:55 -0700 (Tue, 09 Dec 2008) | 45 lines
(closes issue #14019)
Reported by: ckjohnsonme
Patches:
14019.diff uploaded by murf (license 17)
Tested by: ckjohnsonme, murf
This crash was the result of a few small errors that
would combine in 64-bit land to result in a crash.
32-bit land might have seen these combine to mysteriously
drop the args to an application call, in certain
circumstances.
Also, in trying to find this bug, I spotted
a situation in the flex input, where, in passing
back a 'word' to the parser, it would allocate
a buffer larger than necessary. I changed the
usage in such situations, so that strdup was
not used, but rather, an ast_malloc, followed
by ast_copy_string.
I removed a field from the pval struct, in
u2, that was never getting used, and set in
one spot in the code. I believe it was an
artifact of a previous fix to make switch
cases work invisibly with extens.
And, for goto's I removed a '!' from
before a strcmp, that has been there
since the initial merging of AEL2, that
might prevent the proper target of a
goto from being found. This was pretty
harmless on its own, as it would just
louse up a consistency check for users.
Many thanks to ckjohnsonme for providing
a simplified and complete set of information
about the bug, that helped considerably in
finding and fixing the problem.
Now, to get aelparse up and running again
in trunk, and out of its "horribly broken" state,
so I can run the regression suite!
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@162079 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Terry Wilson
Mark Michelson
Kevin P. Fleming
Russell Bryant
Sean Bright
Eliel C. Sardanons
Matthew Nicholson
Tilghman Lesher
David Vossel
Richard Mudgett
Jeff Peeler
Doug Bailey
Joshua Colp
Leif Madsen
Olle Johansson
Michiel van Baak
Steve Murphy
Matthew Fredrickson