There was a problem when reading a string from the websocket. It assumed the
received data had a null terminator and tried to write the data to an ast_str.
This of course could/would read past the end of the given buffer while
writing the data to the internal buffer of ast_str. Modified the the code to
correctly place a null terminator on the result string.


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

During some performance testing of Asterisk with AGI, ARI, and lots of Local
channels, we noticed that there's quite a hit in performance during channel
creation and releasing to the dialplan (ARI continue). After investigating
the performance spike that occurs during channel creation, we discovered
that we create a lot of channel snapshots that are technically unnecessary.
This includes creating snapshots during:
 * AGI execution
 * Returning objects for ARI commands
 * During some Local channel operations
 * During some dialling operations
 * During variable setting
 * During some bridging operations
And more.

This patch does the following:
 - It removes a number of fields from channel snapshots. These fields were
   rarely used, were expensive to have on the snapshot, and hurt performance.
   This included formats, translation paths, Log Call ID, callgroup, pickup
   group, and all channel variables. As a result, AMI Status,
   "core show channel", "core show channelvar", and "pjsip show channel" were
   modified to either hit the live channel or not show certain pieces of data.
   While this is unfortunate, the performance gain from this patch is worth
   the loss in behaviour.
 - It adds a mechanism to publish a cached snapshot + blob. A large number of
   publications were changed to use this, including:
   - During Dial begin
   - During Variable assignment (if no AMI variables are emitted - if AMI
     variables are set, we have to make snapshots when a variable is changed)
   - During channel pickup
   - When a channel is put on hold/unhold
   - When a DTMF digit is begun/ended
   - When creating a bridge snapshot
   - When an AOC event is raised
   - During Local channel optimization/Local bridging
   - When endpoint snapshots are generated
   - All AGI events
   - All ARI responses that return a channel
   - Events in the AgentPool, MeetMe, and some in Queue
 - Additionally, some extraneous channel snapshots were being made that were
   unnecessary. These were removed.
 - The result of ast_hashtab_hash_string is now cached in stasis_cache. This
   reduces a large number of calls to ast_hashtab_hash_string, which reduced
   the amount of time spent in this function in gprof by around 50%.

#ASTERISK-23811 #close
Reported by: Matt Jordan

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

Merged revisions 416211 from http://svn.asterisk.org/svn/asterisk/branches/12


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

ASTERISK-23673 #close
Reported by: Richard Mudgett

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

Merged revisions 416066 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

Merged revisions 416067 from http://svn.asterisk.org/svn/asterisk/branches/11
........

Merged revisions 416070 from http://svn.asterisk.org/svn/asterisk/branches/12


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

Simply establishing a TCP connection and never sending anything to the
configured HTTP port in http.conf will tie up a HTTP connection.  Since
there is a maximum number of open HTTP sessions allowed at a time you can
block legitimate connections.

A similar problem exists if a HTTP request is started but never finished.

* Added http.conf session_inactivity timer option to close HTTP
connections that aren't doing anything.  Defaults to 30000 ms.

* Removed the undocumented manager.conf block-sockets option.  It
interferes with TCP/TLS inactivity timeouts.

* AMI and SIP TLS connections now have better authentication timeout
protection.  Though I didn't remove the bizzare TLS timeout polling code
from chan_sip.

* chan_sip can now handle SSL certificate renegotiations in the middle of
a session.  It couldn't do that before because the socket was non-blocking
and the SSL calls were not restarted as documented by the OpenSSL
documentation.

* Fixed an off nominal leak of the ssl struct in
handle_tcptls_connection() if the FILE stream failed to open and the SSL
certificate negotiations failed.

The patch creates a custom FILE stream handler to give the created FILE
streams inactivity timeout and timeout after a specific moment in time
capability.  This approach eliminates the need for code using the FILE
stream to be redesigned to deal with the timeouts.

This patch indirectly fixes most of ASTERISK-18345 by fixing the usage of
the SSL_read/SSL_write operations.

ASTERISK-23673 #close
Reported by: Richard Mudgett
........

Merged revisions 415841 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

Merged revisions 415854 from http://svn.asterisk.org/svn/asterisk/branches/11
........

Merged revisions 415896 from http://svn.asterisk.org/svn/asterisk/branches/12


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

This change makes res_pjsip_pubsub persist inbound subscriptions in sorcery. By default
this uses the local astdb but it can also be configured to store within an outside
database. When Asterisk is started these subscriptions are recreated if they have not
expired. Notifications are sent to the devices which have subscribed and they are none
the wiser that the system has restarted.

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

Merged revisions 415766 from http://svn.asterisk.org/svn/asterisk/branches/12


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

This patch is a re-do of r414122.

When r414122 was merged, a major problem with it was uncovered. UNBRIDGE soft
hangup flags have a catastrophic effect on the pbx core if they leak out from
the bridge layer: the channel gets hung up. With the number of threads
involved in a blind transfer, and with the initial patch, it was likely that
this would occur. This caused a large number of test failures

This patch is nearly identical with the one proposed in r414122, save for the
following changes:
 - We explicitly clear the UNBRIDGE flag when setting an after goto on a
   channel in a bridge
 - Defensively, if we encounter an UNBRIDGE flag in the pbx core, we handle it

https://reviewboard.asterisk.org/r/3585/
........

Merged revisions 415443 from http://svn.asterisk.org/svn/asterisk/branches/12


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

........

Merged revisions 415427 from http://svn.asterisk.org/svn/asterisk/branches/12


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

Prior to this patch, sequential variables would be ordered in reverse
from the order specified in the manager action.

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

Merged revisions 415359 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

Merged revisions 415390 from http://svn.asterisk.org/svn/asterisk/branches/11
........

Merged revisions 415410 from http://svn.asterisk.org/svn/asterisk/branches/12


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

Split astobj2.c into the following files to improve maintainability.

astobj2.c - object primitives, object primitive misc and initialization code.
astobj2_private.h - internal object declarations needed by the containers.
astobj2_container.c - generic conainer and container misc code.
astobj2_container_hash.c - hash container specific code.
astobj2_container_rbtree.c - rbtree container specific code.
astobj2_container_private.h - generic container definitions and rtti prototypes.

https://reviewboard.asterisk.org/r/3576/
........

Merged revisions 415317 from http://svn.asterisk.org/svn/asterisk/branches/12


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

Added a websocket server client in Asterisk. Asterisk has a websocket server,
but not a client. The ability to have Asterisk be able to connect to a websocket
server can potentially be useful for future work (for instance this could allow
ARI to connect back to some external system, although more work would be needed
in order to incorporate that).

Also a couple of things to note - proxy connection support has not been
implemented and there is limited http response code handling (basically, it is
connect or not).

Also added an initial new URI handling mechanism to core.  Internet type URI's
are parsed into a data structure that contains pointers to the various parts of
the URI.

(closes issue ASTERISK-23742)
Reported by: Kevin Harwell
Review: https://reviewboard.asterisk.org/r/3541/


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

This patch adds a new channel function TALK_DETECT that, when set on a
channel, causes events indicating the start/stop of talking on a channel to be
emitted to both AMI and ARI clients. 

The function allows setting both the silence threshold (the length of silence
after which we decide no one is talking) as well as the talking threshold (the
amount of energy that counts as talking). Parameters can be updated on a channel
after talk detection has been enabled, and talk detection can be removed at
any time.

The events raised by the function use a nomenclature similar to existing AMI/ARI
events.
For AMI: ChannelTalkingStart/ChannelTalkingStop
For ARI: ChannelTalkingStarted/ChannelTalkingFinished

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

#ASTERISK-23786 #close
Reported by: Matt Jordan
........

Merged revisions 414934 from http://svn.asterisk.org/svn/asterisk/branches/12


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

This patch addresses some aesthetic issues in Asterisk. These are all just
minor tweaks to improve the look of the CLI when used in a variety of
settings. Specifically:
 * A number of chatty verbose messages were removed or demoted to DEBUG
   messages. Verbose messages with a verbosity level of 5 or higher were -
   if kept as verbose messages - demoted to level 4. Several messages
   that were emitted at verbose level 3 were demoted to 4, as announcement
   of dialplan applications being executed occur at level 3 (and so the
   effects of those applications should generally be less).
 * Some verbose messages that only appear when their respective 'debug'
   options are enabled were bumped up to always be displayed.
 * Prefix/timestamping of verbose messages were moved to the verboser
   handlers. This was done to prevent duplication of prefixes when the
   timestamp option (-T) is used with the CLI.
 * Verbose magic is removed from messages before being emitted to
   non-verboser handlers. This prevents the magic in multi-line verbose
   messages (such as SIP debug traces or the output of DumpChan) from
   being written to files.
 * _Slightly_ better support for the "light background" option (-W) was
   added. This includes using ast_term_quit in the output of XML
   documentation help, as well as changing the "Asterisk Ready" prompt to
   bright green on the default background (which stands a better chance of
   being displayed properly than bright white).

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



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

Update the semantic versioning of ARI to 1.3.0 and AMI to 2.3.0 to account for
backwards compatible changes going from 12.2.0 to 12.3.0.
........

Merged revisions 414765 from http://svn.asterisk.org/svn/asterisk/branches/12


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

Simply enabling PJSIP to negotiage a video codec (e.g., h264) would leak
video RTP ports if the codec were not negotiated by an incoming call.

* Made add_sdp_streams() associate the handler with the media stream if
the handler handled the media stream.  Otherwise, when the
ast_sip_session_media object was destroyed it didn't know how to clean up
the RTP resources.

* Fixed sdp_requires_deferral() associating the handler with the media
stream when deciding if the SDP processing needs to be deferred for T.38.
Like the leaked video RTP ports, the T.38 handler needs to clean up
allocated resources from deciding if SDP processing needs to be deffered.

* Cleaned up some dead code in handle_incoming_sdp() and
sdp_requires_deferral().

ASTERISK-23721 #close
Reported by: cervajs

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

Merged revisions 414749 from http://svn.asterisk.org/svn/asterisk/branches/12


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

User events can now be generated from ARI.  Events can be signalled with
arbitrary json variables, and include one or more of channel, bridge, or
endpoint snapshots.  An application must be specified which will receive
the event message (other applications can subscribe to it).  The message
will also be delivered via AMI provided a channel is attached.  Dialplan
generated user event messages are still transmitted via the channel, and
will only be received by a stasis application they are attached to or if
the channel is subscribed to.

This change also introduces the multi object blob mechanism used to send
multiple snapshot types in a single message.  The dialplan app UserEvent
was also changed to use multi object blob, and a new stasis message type
created to handle them.

ASTERISK-22697 #close
Review: https://reviewboard.asterisk.org/r/3494/
........

Merged revisions 414405 from http://svn.asterisk.org/svn/asterisk/branches/12


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

PJSIP would never send the final 200 Notify for a blind transfer
when transferring to parking. This patch fixes that. In addition,
it fixes a reference leak when performing blind transfers to
non-bridging extensions.

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

Merged revisions 414400 from http://svn.asterisk.org/svn/asterisk/branches/12


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

This patch fixes res_corosync such that it works with Asterisk 12. This
restores the functionality that was present in previous versions of
Asterisk, and ensures compatibility with those versions by restoring the
binary message format needed to pass information from/to them.

The following changes were made in the core to support this:
 * The event system has been partially restored. All event definition and
   event types in this patch were pulled from Asterisk 11. Previously, we had
   hoped that this information would live in res_corosync; however, the
   approach in this patch seems to be better for a few reasons:
   (1) Theoretically, ast_events can be used by any module as a binary
       representation of a Stasis message. Given the structure of an ast_event
       object, that information has to live in the core to be used universally.
       For example, defining the payload of a device state ast_event in
       res_corosync could result in an incompatible device state representation
       in another module.
   (2) Much of this representation already lived in the core, and was not
       easily extensible.
   (3) The code already existed. :-)
 * Stasis message types now have a message formatter that converts their
   payload to an ast_event object.
 * Stasis message forwarders now handle forwarding to themselves. Previously
   this would result in an infinite recursive call. Now, this simply creates a
   new forwarding object with no forwards set up (as it is the thing it is
   forwarding to). This is advantageous for res_corosync, as returning NULL
   would also imply an unrecoverable error. Returning a subscription in this
   case allows for easier handling of message types that are published directly
   to an aggregate topic that has forwarders.

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

ASTERISK-22912 #close
ASTERISK-22372 #close
........

Merged revisions 414330 from http://svn.asterisk.org/svn/asterisk/branches/12


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

The Test Suite caught a few problems, undoing until those are resolved


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

This patch fixes issues with direct media bridges that occur after a blind
transfer. These issues were caught by the (currently failing)
pjsip/transfers/blind_transfer/caller_direct_media test.

The test currently fails primarily for two reasons:
(1) When Bob and Charlie (the transfer target and the transfer destination)
    enter a bridge together, the framehook remains on the transfer target
    channel until both channels are in the bridge. As it consumes voice frames,
    the initial bridge type is a simple bridge. The framehook is removed when
    both channels are in the bridge; however, this does not currently cause the
    bridging framework to re-evaluate the bridge. This patch adds a
    AST_SOFTHANGUP_UNBRIDGE poke to the transfer target channel when a
    framehook is removed so the bridge can re-evaluate itself.

(2) When a channel leaves a native RTP bridge, it may be leaving due to being
    hung up. Sending a re-INVITE to a channel that is about to be hung up is
    not nice - in fact, there's a good chance we'll send the BYE request before
    the channel has had a chance to send back a 200 OK. To be somewhat nicer,
    this patch adds a function to channel.h that allows the bridging framework
    to query for exactly why a channel is leaving a bridge via the channel's
    soft hangup flags. This allows it to only send the re-INVITE if there's a
    chance the channel will survive the native bridging experience.

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

Merged revisions 414122 from http://svn.asterisk.org/svn/asterisk/branches/12


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

ASTERISK-23564 #close
Reported by: Patrick Laimbock
Review: https://reviewboard.asterisk.org/r/3474/
........

Merged revisions 413876 from http://svn.asterisk.org/svn/asterisk/branches/11
........

Merged revisions 413877 from http://svn.asterisk.org/svn/asterisk/branches/12


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

When overlap dialing is enabled, the lack of inband audio available
information in the SETUP_ACKNOWLEDGE events causes an interoperability
problem with SIP.  sig_pri doesn't know if there is dialtone present when
a SETUP_ACKNOWLEDGE is received so it assumes it is there and posts an
AST_CONTROL_PROGRESS frame.  The SIP channel driver then sends out a 183
Session Progress and blocks the desired 180 Ringing message when the
ALERTING message comes in.

* Made the configure script detect if the installed version of libpri
supports the SETUP_ACKNOWLEDGE enhancements.

* Using the new API, made generate an AST_CONTROL_PROGRESS frame on an
incoming SETUP_ACKNOWLEDGE message when the message indicates inband audio
is present instead of assuming that dialtone is present.

* Using the new API, made SETUP_ACKNOWLEDGE send out an inband audio
available indication only if dialtone is expected.  The change also makes
the fallback behaviour of sending the PROGRESS message better by sending
it only if dialtone is expected.

* Changed receiving a PROCEEDING message to not generate an
AST_CONTROL_PROGRESS frame if the progress indication ie indicates
non-end-to-end-ISDN.  This helps interoperability with SIP.

* Changed sending a PROCEEDING message in response to an
AST_CONTROL_PROCEEDING frame to not indicate inband audio available.  It
was silly to do so anyway because the channel driver doesn't know if
inband audio is even available.  This helps interoperability with SIP.

This patch and a corresponding change in libpri work together to allow
Asterisk to control the inband audio available progress indication ie on
the SETUP_ACKNOWLEDGE message when dialtone is present.

AST-1338 #close
Reported by: Tyler Stewart

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

Merged revisions 413714 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

Merged revisions 413765 from http://svn.asterisk.org/svn/asterisk/branches/11
........

Merged revisions 413771 from http://svn.asterisk.org/svn/asterisk/branches/12


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

In the past framehooks have had no capability to determine what frame types a hook
is actually interested in consuming. This has meant that code has had to assume they
want all frames, thus preventing native bridging.

This change adds a callback which allows a framehook to be queried for whether it
is consuming a frame of a specific type. The native RTP bridging module has also
been updated to take advantange of this, allowing native bridging to occur when
previously it would not.

ASTERISK-23497 #comment Reported by: Etienne Lessard
ASTERISK-23497 #close

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

Merged revisions 413681 from http://svn.asterisk.org/svn/asterisk/branches/12


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

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

In the past framehooks have had no capability to determine what frame types a hook
is actually interested in consuming. This has meant that code has had to assume they
want all frames, thus preventing native bridging.

This change adds a callback which allows a framehook to be queried for whether it
is consuming a frame of a specific type. The native RTP bridging module has also
been updated to take advantange of this, allowing native bridging to occur when
previously it would not.

ASTERISK-23497 #comment Reported by: Etienne Lessard
ASTERISK-23497 #close

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

Merged revisions 413650 from http://svn.asterisk.org/svn/asterisk/branches/12


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

This resolves a large number of compiler warnings from GCC 4.10 which
cause the build to fail under dev mode. The vast majority are
signed/unsigned mismatches in printf-style format strings.
........

Merged revisions 413586 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

Merged revisions 413587 from http://svn.asterisk.org/svn/asterisk/branches/11
........

Merged revisions 413588 from http://svn.asterisk.org/svn/asterisk/branches/12


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

* Fixed early exit in sip_msg_send() not destroying the message iterator.

* Made ast_msg_var_iterator_next() and ast_msg_var_iterator_destroy()
tolerant of a NULL iter parameter in case ast_msg_var_iterator_init()
fails.

* Made ast_msg_var_iterator_destroy() clean up any current message data
ref.

* Made struct ast_msg_var_iterator, ast_msg_var_iterator_init(),
ast_msg_var_iterator_next(), ast_msg_var_unref_current(), and
ast_msg_var_iterator_destroy() use iter instead of i.

* Eliminated RAII_VAR usage in res_pjsip_messaging.c:vars_to_headers().
........

Merged revisions 413139 from http://svn.asterisk.org/svn/asterisk/branches/11
........

Merged revisions 413142 from http://svn.asterisk.org/svn/asterisk/branches/12


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

The original commit for spinlock was missing "destroy" implementations.
Most of them are no-ops but phtread_spin and pthread_mutex do need their
locks destroyed.
........

Merged revisions 413102 from http://svn.asterisk.org/svn/asterisk/branches/12


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

There are cases in Asterisk where it might be desirable to lock
a short critical code section but not incur the context switch
and yield penalty of a mutex or rwlock.  The primary spinlock
implementations execute exclusively in userspace and therefore
don't incur those penalties.  Spinlocks are NOT meant to be a
general replacement for mutexes.  They should be used only for
protecting short blocks of critical code such as simple compares
and assignments.  Operations that may block, hold a lock, or
cause the thread to give up it's timeslice should NEVER be
attempted in a spinlock.

The first use case for spinlocks is in astobj2 - internal_ao2_ref.
Currently the manipulation of the reference counter is done with
an ast_atomic_fetchadd_int which works fine.  When weak reference
containers are introduced however, there's an additional comparison
and assignment that'll need to be done while the lock is held.
A mutex would be way too expensive here, hence the spinlock.
Given that lock contention in this situation would be infrequent,
the overhead of the spinlock is only a few more machine instructions
than the current ast_atomic_fetchadd_int call.

ASTERISK-23553 #close
Review: https://reviewboard.asterisk.org/r/3405/
........

Merged revisions 412976 from http://svn.asterisk.org/svn/asterisk/branches/12


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

Previously multiple play actions against a bridge at one time would cause
the sounds to play simultaneously on the bridge. Now if a sound is already
playing, the play action will queue playback to occur after the completion
of other sounds currently on the queue.

(closes issue ASTERISK-22677)
Reported by: John Bigelow
Review: https://reviewboard.asterisk.org/r/3379/
........

Merged revisions 412639 from http://svn.asterisk.org/svn/asterisk/branches/12


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

* Restore the reason value set by pbx_outgoing_attempt() to use
AST_CONTROL_xxx values as all the consumers were expecting rather than
cause codes.

* Fixed the dial routines to set cause codes for more than just
ast_request() so pbx_outgoing_attempt() reason codes will function.

* Fix inconsistent locked_channel return status in pbx_outgoing_attempt().
The chanel may not have been locked or the channel may have been a stale
pointer.

* Fixed the OutgoingSpoolFailed channel to run dialplan whenever the
dialing fails for an originate exten and 1 < synchronous.

* Fix incorrect ast_cond_wait() usage in pbx_outgoing_attempt().
Indroduced by issue ASTERISK-22212 patch.

* Made struct pbx_outgoing use the ao2 lock instead of its own lock for
the cond wait mutex.  No sense in having two locks associated with the
same struct when only one is needed.

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

Merged revisions 412581 from http://svn.asterisk.org/svn/asterisk/branches/12


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

Adds a tones URI type to the playback resource. The tone can be specified by
name (from indications.conf) or by a tone pattern. In addition, tonezone can
be specified in the URI (by appending ;tonezone=<zone>). Tones must be
stopped manually in order for a stasis control to move on from playback of
the tone. Tones may be paused, resumed, restarted, and stopped. They may
not be rewound or fast forwarded (tones can't be controlled in a way that
lets you skip around from note to note and pausing and resuming will also
restart the tone from the beginning). Tests are currently in development
for this feature (https://reviewboard.asterisk.org/r/3428/).

(closes issue ASTERISK-23433)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3427/
........

Merged revisions 412535 from http://svn.asterisk.org/svn/asterisk/branches/12


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

This function returns an ast_bridge without a refcount bump and the
caller must increment the count if it intends to hold the pointer.

(closes issue ASTERISK-23588)
Review: https://reviewboard.asterisk.org/r/3450/
Reported by: Matt Jordan
........

Merged revisions 412439 from http://svn.asterisk.org/svn/asterisk/branches/12


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

Add an option to enable a periodic beep to be played into a call if it
is being recorded.  If enabled, it uses the PERIODIC_HOOK() function
internally to play the 'beep' prompt into the call at a specified
interval.  This option is provided for both Monitor() and
MixMonitor().

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


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

The failing assertion ensures that the final snapshot gets generated so
CDR records can get finalized.  The only place where a channel staging
snapshot flag could be left set is in chan_sip.c:handle_request_bye().
The function could return before clearing the flag because the channel
could dissappear while the function had to have the channel unlocked.

* Fixed handle_request_bye() channel snapshot staging coverage area to not
have a return in the middle of it and be unable to clear the staging flag.

* Pushed the channel snapshot staging coverage area into
ast_rtp_instance_set_stats_vars() to ensure that the staging is not
interrutped.

* Made callers of ast_rtp_instance_set_stats_vars() not call it with any
channels or channel driver private locks held to eliminate the deadlock
potential.  The callers must hold references to the passed in channel and
rtp objects.

* Eliminated sip_hangup() trying to get the bridge peer.  It is futile at
this point because the channel could never be in a bridge.

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

Merged revisions 412385 from http://svn.asterisk.org/svn/asterisk/branches/12


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

While the vast majority of bridge snapshot creation is locked properly,
there are currently some instances that are not. This adds the missing
locking to ensure bridge state is not malleable during snapshot
creation.

(closes issue ASTERISK-22904)
Review: https://reviewboard.asterisk.org/r/3415/
Reported by: Matt Jordan
........

Merged revisions 412193 from http://svn.asterisk.org/svn/asterisk/branches/12


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

This patch does the following:
(1) It makes REF_DEBUG a meneselect item. Enabling REF_DEBUG now enables
    REF_DEBUG globally throughout Asterisk.
(2) The ref debug log file is now created in the AST_LOG_DIR directory.
    Every run will now blow away the previous run (as large ref files
    sometimes caused issues). We now also no longer open/close the file
    on each write, instead relying on fflush to make sure data gets written
    to the file (in case the ao2 call being performed is about to cause a
    crash)
(3) It goes with a comma delineated format for the ref debug file. This
    makes parsing much easier. This also now includes the thread ID of the
    thread that caused ref change.
(4) A new python script instead for refcounting has been added in the
    contrib/scripts folder.
(5) The old refcounter implementation in utils/ has been removed.

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

Merged revisions 412114 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

Merged revisions 412115 from http://svn.asterisk.org/svn/asterisk/branches/11
........

Merged revisions 412153 from http://svn.asterisk.org/svn/asterisk/branches/12


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

The masquerade supertest frequently fails because either the local channel
chain doesn't completely optimize out or the DTMF handshake doesn't
completely get accross.  Local channel optimization requires frames
flowing to trigger when optimization can happen.  When optimization
happens the media frame that triggered the optimization is dropped.
Sending DTMF requires frames to flow in the other direction for timing
purposes while sending nothing.  If internal timing is not enabled when
MOH is playing, Asterisk switches to received timing when an audio frame
is received.  With optimization dropping media frames and MOH not sending
frames unless it receives frames, occasionaly there are no more frames
being passed and the test fails.

* The asterisk command line -I option and the asterisk.conf
internal_timing option are removed.  Asterisk now always uses internal
timing when needed if any timing module is loaded.  The issue
ASTERISK-14861 did this quite awhile ago in v1.4 but effectively is broken
if other internal timing modules besides DAHDI are used.  The
ast_read_generator_actions() now only does received timing if it has no
choice for frame generators like MOH, silence, and playback streaming.

* Cleaned up some code dealing with frame generators in
ast_deactivate_generator(), generator_write_format_change(),
ast_activate_generator(), and ast_channel_stop_silence_generator().

* Removed ast_internal_timing_enabled(), AST_OPT_FLAG_INTERNAL_TIMING, and
ast_opt_internal_timing.

ASTERISK-22846 #close
Reported by: Matt Jordan

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

Merged revisions 411715 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

Merged revisions 411716 from http://svn.asterisk.org/svn/asterisk/branches/11
........

Merged revisions 411717 from http://svn.asterisk.org/svn/asterisk/branches/12


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

This commit contains several changes to sorcery:

1) Application of sorcery configuration based on module name is automatically performed
when sorcery is opened for a module.
2) Sorcery will not attempt to apply the same wizard to an object type more than once.
3) Sorcery gives more exact results when attempting to apply a wizard, whether as the
default or based on configuration.

Sorcery unit tests still pass for me after making these changes.

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

Merged revisions 411159 from http://svn.asterisk.org/svn/asterisk/branches/12


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

This patch adds the following:
(1) A new module, res_hep, which implements a generic packet capture agent for
the Homer Encapsulation Protocol (HEP) version 3. Note that this code is based
on a patch provided by Alexandr Dubovikov; I basically just wrapped it up,
added configuration via the configuration framework, and threw in a
taskprocessor.
(2) A new module, res_hep_pjsip, which forwards all SIP message traffic that
passes through the res_pjsip stack over to res_hep for encapsulation and
transmission to a HEPv3 capture server.

Much thanks to Alexandr for his Asterisk patch for this code and for a *lot*
of patience waiting for me to port it to 12/trunk. Due to some dithering on
my part, this has taken the better part of a year to port forward (I still
blame CDRs for the delay).

ASTERISK-23557 #close

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

Merged revisions 411534 from http://svn.asterisk.org/svn/asterisk/branches/12


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

This patch does the following:
 * It updates the AMI version to 2.2.0 to indicate backwards compatible
   changes have been made since the last release
 * It updates the ARI version to 1.2.0 to indicate backwards compatible
   changes have been made since the last release
 * It updates the UPGRADE/CHANGES files with changes that were not
   mentioned
........

Merged revisions 411529 from http://svn.asterisk.org/svn/asterisk/branches/12


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