Review: https://reviewboard.asterisk.org/r/2616

(closes issue ASTERISK-21542)
Reported by Matt Jordan



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392729 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This adds support for stasis/sounds and stasis/sounds/{ID} queries via
the Asterisk RESTful Interface (ARI, formerly Stasis-HTTP).

The following changes have been made to accomplish this:
* A modular indexer was created for local media.
* A new function to get an ast_format associated with a file extension
  was added.  
* Modifications were made to the built-in HTTP server so that URI
  decoding could be deferred to the URI handler when necessary.
* The Stasis-HTTP sounds JSON documentation was modified to handle
  cases where multiple languages are installed in different formats.
* Register and Unregister events for formats were added to the system
  topic.

(closes issue ASTERISK-21584)
(closes issue ASTERISK-21585)
Review: https://reviewboard.asterisk.org/r/2507/


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392700 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This patch properly packs the parameters into the send fax message so that it
actually work.

Missing a ',' between two string fields can be difficult to debug, particularly
when the actual packing succeeds. Interestingly enough, this didn't actually
crash until the JSON blob we deref'd and disposed of. Since that happened in
a different thread, it was pretty tough to track down.



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392676 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392667 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392647 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This was caused by forwarding all endpoint messages to manager which includes
channel messages that are related to the endpoint. This change causes only
the PeerStatus messages to be forwarded to manager thus eliminating the
duplicate channel messages.


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392627 65c4cc65-6c06-0410-ace0-fbb531ad65f3

By the time something extracts the pointers from ast_json_pack, the channels
will already be disposed of. This patch properly pulls the information out of
the variables and packs them into the JSON blob.


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392607 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Sorcery specific object information is now opaque and allocated with the object.
This means that modules do not need to be recompiled if the sorcery specific part
is changed. It also means that sorcery can store additional information on objects
and ensure it is freed or the reference count decreased when the object goes away.

To facilitate the above a generic sorcery allocator function has been added which
also ensures that allocated objects do not have a lock.

Extended fields have been added thanks to all of the above which allows specific fields
to be marked as extended, and thus simply stored as-is within the object. Type safety
is *NOT* enforced on these fields. A consumer of them has to query and ultimately perform
their own safety check. What does this mean? Extra modules can extend already defined
structures without having to modify them.

Tests have also been included to verify extended field functionality.

Review: https://reviewboard.asterisk.org/r/2585/


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392586 65c4cc65-6c06-0410-ace0-fbb531ad65f3

1. Security events
2. Websocket support
3. Diversion header + redirecting support
4. An anonymous endpoint identifier
5. Inbound extension state subscription support
6. PIDF notify generation
7. One touch recording support (special thanks Sean Bright!)
8. Blind and attended transfer support
9. Automatic inbound registration expiration
10. SRTP support
11. Media offer control dialplan function
12. Connected line support
13. SendText() support
14. Qualify support
15. Inband DTMF detection
16. Call and pickup groups
17. Messaging support

Thanks everyone!

Side note: I'm reminded of the song "How Far We've Come" by Matchbox Twenty.


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392565 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This patch fixes two bugs.
(1) It unlocks the channel in the framehook handlers before attempting to grab
    the peer from the bridge. The locking order for the bridging framework is
    bridge first, then channel - having the channel locked while attempting to
    obtain the bridge lock causes a locking inversion and a deadlock. This
    patch bumps the channel ref count prior to releasing the lock in the
    framehook to avoid lifetime issues.

    Note that this does expose a subtle problem in framehooks; that is,
    something could modify the framehook list while we are executing, causing
    issues in the framehook list traversal that the callback executes in.
    Fixing this is a much larger problem that is beyond the scope of this
    patch - (a) we already unlock the channel in this particular framehook
    and we haven't run into a problem yet (as modifying the framehook list
    when a channel is about to perform a fax gateway would be a very odd
    operation) and (b) migrating to an ao2 container of framehooks would be
    more invasive at this point. See the referenced ASTERISK issue for more
    information.
(2) Directly packing channel variables into a JSON object turned out to be
    unsafe. A condition existed where the strings in the JSON blob were no
    longer safe to be accessed if the channel object itself was disposed of.

(issue ASTERISK-21951)


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392564 65c4cc65-6c06-0410-ace0-fbb531ad65f3

(closes issue ASTERISK-21489)
(closes issue ASTERISK-21503)

Review: https://reviewboard.asterisk.org/r/2601/


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392538 65c4cc65-6c06-0410-ace0-fbb531ad65f3

* Extract a useful routine from the softmix bridge technology for other
technologies.  Make other technologies use it if they can.

* Made native and 1-1 bridges write to all parties if the bridge channel
writing the frame into the bridge is NULL.  Softmix will also do the same
for frame types that make sense.

* Tweak the bridge write routine return value meaning and adjust the
bridge technologies to match.


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392514 65c4cc65-6c06-0410-ace0-fbb531ad65f3

(issue ASTERISK-21947)

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392489 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392464 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392437 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Review: https://reviewboard.asterisk.org/r/2553

(closes issue ASTERISK-21527)
Reported by Matt Jordan



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392436 65c4cc65-6c06-0410-ace0-fbb531ad65f3

The bridge frame queue functions need to return an error status if the
frame failed to be queued because of an error condition.  The main calls
that needed to return the status are:
ast_bridge_channel_queue_action_data() and
ast_bridge_channel_write_action_data().  The other return changes are
ripple effects.


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392435 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This patch updates the autosupport script to collect all information available
to the Asterisk CLI command "digium_phones". It also makes minor improvements
in options handling.

(closes issue AST-1163)
Reported by: Trey Blancher
patches:
  390347_autosupport.diff uploaded by tblancher (License 5821)
  390348_autosupport.diff uploaded by tblancher (License 5821)


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392409 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392364 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392335 65c4cc65-6c06-0410-ace0-fbb531ad65f3

When a threadpool is set to autoincrement its threadcount, an issue
may arise when multiple tasks are queued at once into the threadpool. Since
threads start active, each new task would result in autoincrementing the
thread count. So if all threads were active, and a thread's autoincrement
value were 5, then 3 new tasks would result in 15 threads being created even
though the initial autoincrement was sufficient to handle the number of tasks.

This change introduces three behavior changes:

1) New threads in the threadpool start idle instead of active.
2) When a threadpool autoincrements, one thread is activated after the growth.
3) When a threadpool's size is incremented manually, all added threads are activated.

For a more detailed explanation about the changes, please see the Review Board link
at the bottom of this commit.

Review: https://reviewboard.asterisk.org/r/2629



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392318 65c4cc65-6c06-0410-ace0-fbb531ad65f3

For about forever, our build flags for OS X have been slightly off, but
good enough to build and run. Apparently they aren't good enough any more.

Previously, we would compile with macosx-version-min unset and link with
it set. This combination, using GCC 4.8, on Mountain Lion, would create a
bad executable ("Illegal Instruction: 4", or something like that)

This patch consistently sets macosx-version-min for both compiling and
linking, which makes everything happy enough to build and run.


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392279 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This finishes moving all CEL linkedid tracking entirely within cel.c
since that is now possible with channel snapshots.

This also removes another CEL linkedid manipulation function from cel.h
that has already been internalized and is neither called nor available
to link against.

Review: https://reviewboard.asterisk.org/r/2632/


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392241 65c4cc65-6c06-0410-ace0-fbb531ad65f3

When func_cdr is used for variable substitution, there is no channel name
and hence no run-time information available for CDR variable substitution.
In that case, the correct thing to do is to use the CDR object on the channel
passed to the function. This patch checks to see if the channel passed in
has a name - if not, it uses ast_cdr_format_var instead of ast_cdr_get_var.

This allows CDR backends to continue to use variable substitution in order to
resolve ast_cdr object properties.

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392214 65c4cc65-6c06-0410-ace0-fbb531ad65f3

In r391947, the CDR function was modified such that it will return a
value for the start,answer, and end times if asked. That time will just
be 0 if it hasn't happened yet.

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392190 65c4cc65-6c06-0410-ace0-fbb531ad65f3

* Promoted some bridge construction debug messages to warnings.


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392166 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392140 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392139 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This makes ast_bridge_snapshot_to_json conform to the swagger Bridge
model by adding the two fields it required.

Review: https://reviewboard.asterisk.org/r/2583/


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392116 65c4cc65-6c06-0410-ace0-fbb531ad65f3

The type of tv_usec is suseconds_t. On Linux, this is usually a long int, but
the specification is actually pretty lax on what it might actually be. And,
sadly, there's no printf/scanf width specifier for suseconds_t. So it could
bit an int or a long, but there's not a great way to tell which it is.

This patch fixes scanf by reading into a long temporary variable that's then
stored into the tv_usec. It fixes printf by casting the tv_usec to a long
first.

This patch also adds some missing width specifiers for some debug statements,
which would cause ".000001" to be displayed at ".1".


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392076 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392073 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392053 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392032 65c4cc65-6c06-0410-ace0-fbb531ad65f3

When a channel is originated, its application is typically set to AppDial2,
indicating that it was a dialed channel through the Dial API. Asterisk during
an originate will perform a stack execute to direct the outgoing channel to
a particular place in the dialplan or application. When the stack returns, the
previous application (AppDial2) is restored.

Unfortunately, in the case of an originated channel, the stack restore happens
after hangup. A stasis message is sent notifying everyone that the application
was restored, and this causes a NewExten event to go out after the Hangup event,
violating the basic contract consumers have of the channel lifetime. While we
could preclude the message from going out, restoring the channel's state before
it executed the next higher frame in the stack has to occur, and other places
in the code depend on this behavior.

Since we know that channel hung up (it's a ZOMBIE!), this patch simply checks
to see if the channel has been zombified before sending a NewExten event.

Note that this will fix a number of bouncing tests in the Test Suite. Go tests.

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392005 65c4cc65-6c06-0410-ace0-fbb531ad65f3

The patch for CDRs moved around a lot of content in CHANGES to try and
organize the areas that were affected. This missed some changes that went
in with a merge and removed some updates - this patch adds them back in.

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392004 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Fix build warning (which is transmogrified into an error) with my compiler due to uninitialized variable.


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391982 65c4cc65-6c06-0410-ace0-fbb531ad65f3

A stray ast_cdr_setvar was missed in cdr_mysql (silly addons). This has now
been refactored to not set the property, as the property would have been set
on a run-time object that was already dispatched to the backend. The module
simply remembers the value it wanted to set and writes it to MySQL later
in the processing.



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391964 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This patch is the initial push to update Asterisk's CDR engine for the new
bridging framework. This patch guts the existing CDR engine and builds the new
on top of messages coming across Stasis. As changes in channel state and bridge
state are detected, CDRs are built and dispatched accordingly. This
fundamentally changes CDRs in a few ways.
(1) CDRs are now *very* reflective of the actual state of channels and bridges.
    This means CDRs track well with what an actual channel is doing - which
    is useful in transfer scenarios (which were previously difficult to pin
    down). It does, however, mean that CDRs cannot be 'fooled'. Previous
    behavior in Asterisk allowed for CDR applications, channels, and other
    properties to be spoofed in parts of the code - this no longer works.
(2) CDRs have defined behavior in multi-party scenarios. This behavior will not
    be what everyone wants, but it is a defined behavior and as such, it is
    predictable.
(3) The CDR manipulation functions and applications have been overhauled. Major
    changes have been made to ResetCDR and ForkCDR in particular. Many of the
    options for these two applications no longer made any sense with the new
    framework and the (slightly) more immutable nature of CDRs.

There are a plethora of other changes. For a full description of CDR behavior,
see the CDR specification on the Asterisk wiki.

(closes issue ASTERISK-21196)

Review: https://reviewboard.asterisk.org/r/2486/



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391947 65c4cc65-6c06-0410-ace0-fbb531ad65f3

In revision 389733, mwi state allocation was placed into its
own function instead of performing the allocation in-line when
required. The issue was that in ast_publish_mwi_state_full(),
the local variable "uniqueid" was no longer being set, but it was
still being used as the topic for MWI. This meant that all MWI
publications ended up being published to the "" (empty string)
mailbox topic. Thus MWI subscriptions for specific mailboxes were
never notified of mailbox state changes.

This change fixes the issue by removing the local uniqueid variable
from ast_publish_mwi_state_full() and instead referencing the
mwi_state->uniqueid field since it has been properly set.

(closes issue ASTERISK-21913)
Reported by Malcolm Davenport



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391921 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This can happen when a REGISTER request is removing a contact.

(closes issue ASTERISK-21911)
Reported by: mdavenport


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391902 65c4cc65-6c06-0410-ace0-fbb531ad65f3