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

chan_vpb: Effectively remove native support.  Left enough bread crumbs to be able to convert later if needed.

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

(issue ASTERISK-21944)


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

chan_misdn: Effectively remove native support.  Left enough bread crumbs to be able to convert later if needed.

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

Holding bridges can allow local channel move/swap optimization to the
bridge.  However, we cannot allow it for the BridgeWait holding bridge
because the call will lose the channel roles and dialplan location as a
result.


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

........

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

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


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

Depending on certain conditions it was possible for the hashtab counting thread
to starve other threads, preventing them from executing in the expected fashion.
This change adds a sleep to allow the others to do what they need to do. While
this doesn't thrash the hashtab as much as previously, it at least works.

(closes issue ASTERISK-22276)
Reported by: Matt Jordan
........

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

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


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

Patches:
    reviewboard-2377.patch uploaded by Paul Belanger
Review: https://reviewboard.asterisk.org/r/2377/
........

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

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


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

Patches:
    reviewboard-2155.patch uploaded by Paul Belanger
Review: https://reviewboard.asterisk.org/r/2155/
........

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

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


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

This patch changes ARI bridging to allow other channel operations to
happen while the channel is bridged.

ARI channel operations are designed to queue up and execute
sequentially. This meant, though, that while a channel was bridged,
any other channel operations would queue up and execute only after the
channel left the bridge.

This patch changes ARI bridging so that channel commands can execute
while the channel is bridged. For most operations, things simply work
as expected. The one thing that ended up being a bit odd is recording.

The current recording implementation will fail when one attempts to
record a channel that's in a bridge. Note that the bridge itself may
be recording; it's recording a specific channel in the bridge that
fails. While this is an annoying limitation, channel recording is
still very useful for use cases such as voice mail, and bridge
recording makes up much of the difference for other use cases.

(closes issue ASTERISK-22084)
Review: https://reviewboard.asterisk.org/r/2726/


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

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

The debug logs added in r396528 neglected to account for suseconds_t
being an int.

See r392076 for more info.



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

These are needed by the pjsip inbound registration test suite tests.

(issue ASTERISK-21833)
(issue ASTERISK-21834)
(issue ASTERISK-21835)
(issue ASTERISK-21837)

Review: https://reviewboard.asterisk.org/r/2700/
Review: https://reviewboard.asterisk.org/r/2739/



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

These problems were all caught by a test in the Asterisk Test Suite that
originated some Local channels and attempted to move the ;2 half of the Local
channel into a bridge using the Bridge AMI action.

(1) When originating a channel, the Newchannel event is emitted quickly;
    however, the ;2 channel will not have a pbx thread assigned to it until
    after the outbound 'dialing' for the ;1 is complete. Thus, there is a period
    of time where the outside world "knows" of the channel's existence and can
    influence it but Asterisk has not yet started the dialplan execution thread.
    If a Bridge AMI action is taken on the channel, the channel appears to be a
    Dialed channel with no PBX thread; hence, the channel will be imparted into
    the Bridge by first 'yanking' the channel. At the same time, a race condition
    can occur after the yank (but before entering the bridge) when ;1 answers
    and starts a PBX on the ;2. The end result currently is an assertion failure
    in the Bridging API, as a channel with a PBX is imparted into the Bridge.

    There's no way to prevent AMI from attempting to Bridge a channel
    immediately after creation; likewise, holding the channel lock through the
    entire Dial operation is unwise (and impossible). Instead of treating the
    presence of a PBX thread as an error, we simply bail out of the adding the
    channel to the bridge through ast_bridge_impart. The Bridge action will
    then fail - but we avoid a situation where the channel is both executing
    a PBX thread and simultaneously being given a separate thread in the
    bridging system (which would be a "bad thing"). Since imparting a channel
    with a PBX *can* occur and is not a programming error, the asserts have been
    removed.

(2) When the first condition occurs, we have to take one of two actions: either
    hangup the yanked channel as it did not enter the bridge, or deref it
    because we don't own it. We can determine if we own it or not by testing
    for the presence of the PBX thread. If we hung it up directly, we'd crash.

(3) bridge_find_channel does not increase the reference count of the
    ast_bridge_channel object. The RAII_VAR usage in ast_bridge_add_channel
    thus created a ticking time bomb in whatever bridge the channel moved into,
    as the destructor for the ast_bridge_channel object would be called.

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



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

If the thread servicing the dial request isn't created successfully, the
outgoing dial lock will still be held when the function returns. This patch
unlocks the lock on this off nominal path.


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

Otherwise, it doesn't show up in the automated test failures


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

Disabling DEBUG_THREADS caused this test to fail on the 32-bit build agent.
Adding some debugging to see why it thinks the test is timing out.


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

If a dial operation fails, the pbx_outgoing_attempt routine will exit without
first having unlocked the outgoing dial lock. This would be a "bad thing".


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

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

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


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

This makes it so that we can detect failures to originate as with
earlier versions of Asterisk, which restores the Asterisk 11 behavior
for the originate manager action. This was causing the ACL tests for
SIP and IAX2 to fail since those tests expected originate failures
when ACLs would cause rejections. Also, this patch fixes crashes in
chan_sip when ACLs rejected peers during registration verification.

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


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

The lonely flag is an optional flag for bridge channels that will
make them leave a bridge when a channel leaves if only lonely
channels are in the bridge at that point. This is useful for things
like ending recording and playback channels when they cease to be
interacting with other channels in the bridge.

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


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

Add some additional markup for items that needed it, e.g.,
replaceable tags, literal tags, etc.


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

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

This code adds chan_dahdi the command 'dahdi create channels <range>'
(where <range> is a single <n>-<m> or 'new') and updates 'dahdi destroy
channel' with a similar 'dahdi destroy channels'. It allows DAHDI
channels and spans to be added after the initial channel load
(without destroying all other channels as in 'dahdi restart').

It also includes some fixes to the D-Channel / span destruction code
(r394552).

This change is intended to provide a hook for a script running from
udev once a span has been assigned ("registered") / unassigned
("unregistered") for its channels. The udev hook configures the span's
channels with dahdi_cfg -S, and can then ask Asterisk to create ethe
channels. See the scripts added to DAHDI-tools in 2.7.0.

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


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

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

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

........
Consistent memory allocation by ast_bt_get_symbols.

Always use ast_alloc/ast_free. This is handled differently in trunk (r391012).

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

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


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

* Changed ast_manager_build_bridge_state_string() to assume an empty
prefix string just like ast_manager_build_channel_state_string().

* Created ast_manager_build_bridge_state_string_prefix() to work just like
ast_manager_build_channel_state_string_prefix().

* Made BridgeMerge AMI event use To/From prefixes.


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

Writing to a file in the wav49 format performs rather inefficiently. The
procedure is approximately:
 (1) Write GSM frame to the end of the file
 (2) Seek to the end of the file
 (3) Seek to the header
 (4) Update the file size
 (5) Seek (again) to the end of the file
 (6) Repeat

This pattern negates any attempt to use the stdio buffering setup in
ast_writefile. It also results in many small writes that require a seek going
to the disk each second which translates to poor disk performance on certain
file systems, particularly when there are multiple wav49 files being written
simultaneously.

(closes issue ASTERISK-19595)
Reported by: Byron Clark
Tested by: Byron Clark
patches:
  gsm_wav_only_update_header_on_close.patch uploaded by byronclark (License 6157)


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

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

This patch does three things:
1. It provides a Surrogate channel technology with a consolidated
   "implementation detail flag" on the channel technology. This tells
   consumers of Stasis that the creation of this channel is an implementation
   detail in Asterisk and can be ignored (if they so choose). This
   consolidates the conference recorder/announcer flags as well - these flags
   had no additional meaning beyond "ignore this channel please".

2. It modifies allocation of a channel in two ways:
   (a) If a channel technology can be determined from the name, we set it
       directly in the allocation routine. This prevents the initial
       publication of the message from going out with a NULL channel technology
       where possible. This lets Stasis consumers get the right channel
       technology on the first publication.
   (b) It reorganizes allocation to make use of the 'finalized' property on the
       channel. This was already used to know that a channel had completely
       finished its construction in the masquerade routine; now we also use it
       to know whether or not the setting of certain channel properties is
       occurring during or post construction. The various set routines were
       modified accordingly as well.

3. The masquerade event is now dead, Jim. It no longer served any purpose
   whatsoever - if you perform a call pickup you'll get a Pickup event;
   if you perform an attended transfer you will still get those events; if you
   steal a channel to put it elsewhere you'll get the corresponding NewExten or
   BridgeEnter events.

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


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

Backtraces are allocated outside of the usual memory tracking performed by
MALLOC_DEBUG. This allows them to be used by the memory tracking enabled
by that build option; however, it also means that when backtraces are
disposed of they have to be done so outside of the re-defined free.

This patch undef's free prior to disposing of the allocated backtrace when
a backtrace is appended as a result of 'core show locks'.


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

This prevents unreal channel optimization during the prequalification
phase when either channel is involved in DTMF emulation. This prevents
a situation where an emulated digit would be missed because the
emulation was never completed.

Review: https://reviewboard.asterisk.org/r/2747/
(closes issue ASTERISK-22214)


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

 - Fix different issues with call transfer cancel. In case 3rd party busy or congestion call was not returned.
 - Fix displaying soft button 'Redial' in case of no redial number exists
........

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


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

Depending on when a Surrogate channel replaces an existing channel, it is
possible to get a Dial message for the Surrogate channel. When this occurs, no
CDR will exist for the channel as Surrogate channels are ignored. Safely handle
the case when a CDR doesn't exist for a Dial message.


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

The rna() routine will raise a Stasis message involving both the caller and the
agent. This doesn't work so well if we already hung up the agent channel, as
the channel doesn't quite exist. Not surprisingly, this will crash. This patch
properly runs the rna subroutine (performing all of the Ring-No-Answer logic)
prior to hanging up the agent channel.

(closes issue ASTERISK-22258)
Reported by: Kiril Valchev
Tested by: Kiril Valchev



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

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

This patch implements the controls from ARI recordings. The controls
are:

 * DELETE /recordings/live/{recordingName} - stop recording and
   discard it
 * POST /recordings/live/{recordingName}/stop - stop recording
 * POST /recordings/live/{recordingName}/pause - pause recording
 * POST /recordings/live/{recordingName}/unpause - resume recording
 * POST /recordings/live/{recordingName}/mute - mute recording (record
   silence to the file)
 * POST /recordings/live/{recordingName}/unmute - unmute recording.

Since this underlying functionality did not already exist, is was
added to app.c by a set of control frames, similar to how playback
control works. The pause/mute control frames are toggles, even though
the ARI controls are idempotent, to be consistent with the playback
control frames.

(closes issue ASTERISK-22181)
Review: https://reviewboard.asterisk.org/r/2697/


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

The Stasis changes in r395954 had an unanticipated side effect: messages
published directly to an _all topic does not get forwarded to the
corresponding caching topic.

This patch fixes that by changing how caching topics forward messages,
and how the caching pattern forwards are setup.

For the caching pattern, the all_topic is forwarded to the
all_topic_cached. This forwards messages published directly to the
all_topic to all_topic_cached.

In order to avoid duplicate messages on all_topic_cached, caching topics
were changed to no longer forward uncached messages. Subscribers to an
individual caching topic should only expect to receive cache updates,
and subscription change messages. Since individual caching topics are
new, this shouldn't be a problem.

There are a few minor changes to the pre-cache split behavior.

 * For topics changed to use the caching pattern, the all_topic_cached
   will forward snapshots in addition to cache updates. Since
   subscribers by design ignore unexpected messages, this should be
   fine.

 * Caching topics that don't use the caching pattern no longer forward
   non-cache updates. This makes no difference for the current caching
   topics.

   * mwi_topic_cached, channel_by_name_topic and
     presence_state_topic_cached have no subscribers

   * device_state_topic_cached's only subscriber only processes cache
     udpates

(issue ASTERISK-22243)
Review: https://reviewboard.asterisk.org/r/2738


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