This patch sets the protocols container provided by res_http_websocket to NULL
when the module gets unloaded and adds the necessary checks when adding/
removing a websocket protocol. This prevents some FRACKing on an invalid
pointer to the disposed container if a module that uses res_http_websocket is
unloaded after it.



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

This patch does the following:
 * A new Stasis payload has been defined for multi-channel messages. This
   payload can store multiple ast_channel_snapshot objects along with a single
   JSON blob. The payload object itself is opaque; the snapshots are stored
   in a container keyed by roles. APIs have been provided to query for and
   retrieve the snapshots from the payload object.
 * The Dial AMI events have been refactored onto Stasis. This includes dial
   messages in app_dial, as well as the core dialing framework. The AMI events
   have been modified to send out a DialBegin/DialEnd events, as opposed to
   the subevent type that was previously used.
 * Stasis messages, types, and other objects related to channels have been
   placed in their own file, stasis_channels. Unit tests for some of these
   objects/messages have also been written.



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

This is the API that binds the Stasis dialplan application to external
Stasis applications. It also adds the beginnings of WebSocket
application support.

This module registers a dialplan function named Stasis, which is used
to put a channel into the named Stasis app. As a channel enters and
leaves the Stasis diaplan application, the Stasis app receives a
'stasis-start' and 'stasis-end' events.

Stasis apps register themselves using the stasis_app_register and
stasis_app_unregister functions. Messages are sent to an application
using stasis_app_send.

Finally, Stasis apps control channels through the use of the
stasis_app_control object, and the family of stasis_app_control_*
functions.

Other changes along for the ride are:
 * An ast_frame_dtor function that's RAII_VAR safe
 * Some common JSON encoders for name/number, timeval, and
   context/extension/priority

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


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

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


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

The initial report was that the "nat" setting in the [general] section was not
having any effect in overriding the default setting.  Upon confirming that this
was happening and looking into what was causing this, it was discovered that
other default settings would not be overriden as well.

This patch works similar to what occurs in build_peer().  We create a temporary
ast_flags structure and using a mask, we override the default settings with
whatever is set in the [general] section.

In the bug report, the reporter who helped to test this patch noted that the
directmedia settings were being overriden properly as well as the nat settings.

This issue is also present in Asterisk 1.8 and a separate patch will be applied
to it.

(issue ASTERISK-21225)
Reported by: Alexandre Vezina
Tested by: Alexandre Vezina, Michael L. Young
Patches:
  asterisk-21225-handle-options-default-prob_v4.diff
						Michael L. Young (license 5026)

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

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


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

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

(issue ASTERISK-21151)


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

The new inband_on_proceeding option causes Asterisk to assume inband audio
may be present when a PROCEEDING message is received.

Q.931 Section 5.1.2 says the network cannot assume that the CPE side has
attached to the B channel at this time without explicitly sending the
progress indicator ie informing the CPE side to attach to the B channel
for audio.  However, some non-compliant ISDN switches send a PROCEEDING
without the progress indicator ie indicating inband audio is available and
assume that the CPE device has connected the media path for listening to
ringback and other messages.

ASTERISK-17834 which causes this issue was dealing with a non-compliant
network switch.

(closes issue ASTERISK-21151)
Reported by: Gianluca Merlo
Tested by: rmudgett
........

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

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


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

Document that you can read/write the 'accountcode' and 'amaflags' on a channel.
........

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

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


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

OBJ_PARTIAL_KEY searching a rbtree did not find all possible matches if
the container did not accept duplicates.

Added matching node bias to indicate which matching node is being searched
for: first, last, any.


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

func_version.so was being rebuilt every time, because build.h was
changing every build, because of the cleantest dependency that was
added in r384410 to fix parallel make bugs.

Now build.h will only be created if it does not exist, which was the
original behavior of the Makefile.
........

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

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


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

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

Sorry folks. ',' are still greater than '|'.

Thanks for playing along :-)

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

When r383579 was committed, it made Jansson a required dependency.

While libjansson-dev and jansson-devel are available on recent
distros, some older (but still supported) distros don't have
it. There's a pull request[1] to get it into repoforge, but that still
doesn't help everyone. (And helps no one until the pull request is
merged and packages are built).

This patch adds Jansson install from source to the install_unpackaged()
function. There are a few gotcha's, which makes this change not
completely trivial.

 * Since Jansson may be installed by a package, don't install from
   source if a package installation can be found
   * libresample may also be installed via package, so I added a
     similar check to that.
 * Since Jansson installs into /usr/local, this patch also adds
   /usr/local/lib to /etc/ld.so.conf.d so that the library can be
   found.
   * The alternative was to install into /usr, but then it gets
     complicated having to deal with EL's /usr/lib{32,64} shenanigans.

 [1]: https://github.com/repoforge/rpms/pull/250

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


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

This patch fixes a bug introduced in r76703, wherein Asterisk could only parse
arguments in the so-called 'recommended' way, e.g., NoOp(foo,bar). The proper
syntax of NoOp,foo|bar is now parsed correctly.


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

........

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


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

This patch fixes an issue of message ordering that occurs when
multiple topics are forwarded to an aggregator topic (such as
ast_channel_topic_all()).

It is (very reasonably) expected that the rules governing message
dispatch order still apply, so long as the messages start from the
same thread, and are received by the same subscription. Because the
existing code had an additional layer of dispatching via the Stasis
thread pool for forwards, those promises couldn't be kept.

Forwarding subscriptions no longer have their own mailbox, and now
dispatch directly from the forwarding topic's stasis_publish()
call. This means that the topic's lock is held for the duration of not
only a message's dispatch, but the dispatch of all the forwards. This
shouldn't be a problem right now, but if an aggregator topic had many
subscribers, it could become a problem. But I figure we can write more
clever code when the time comes, if necessary.

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


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

Occasionally, make -j would fail due to missing includes, or other
unusual errors.

This was due to the 'cleantest' target, which was designed to force a
make clean when some change in the code would cause the typical
depedency checking to fail. Several targets in the main Makefile did
not depend upon cleantest, hence would run in parallel to it. By
adding the dependency, make -j runs happily now.

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

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

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


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

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

This patch migrates the TestEvent AMI events to first be dispatched over the
Stasis-Core message bus. This helps to preserve the ordering of the events
with other events in the AMI system, such as the various channel related
events.



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

At least one call to run_externnotify provides a NULL context parameter and
because the snprintf statement doesn't account for a NULL context parameter,
it simply writes '(null)' to the arguments string instead. This patch makes
it write two quotes back to back for that argument instead in the event of
a NULL context.

(closes issue ASTERISK-18207)
Reported by: Barry L. Kline
Patches:
	modified from patch-20130306 uploaded by Karsten Wemheuer (License 5930)
........

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

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


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

* Updated test_uuid.c to test the new API call.

* Made system use the new API call to eliminate "10's of lines" where
used.

* Fixed untested ast_strdup() return in stasis_subscribe() by eliminating
the need for it.  struct stasis_subscription now contains the uniqueid[]
string.

* Fixed some issues in exchangecal_write_event():
  Create uid with enough space for a UUID string to avoid a realloc.
  Fix off by one error if the calendar event provided a UUID string.
  There is no need to check for NULL before calling ast_free().


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

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

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

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

........

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

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


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

While looking at the security vulnerability in ASTERISK-20967, Walter noticed
a file descriptor leak and some other issues in off nominal code paths. This
patch corrects them.

Note that this patch is not related to the vulnerability in ASTERISK-20967,
but the patch was placed on that issue.

(closes issue ASTERISK-20967)
Reported by: wdoekes
patches:
  issueA20967_file_leak_and_unused_wkspace.patch uploaded by wdoekes (License 5674)
........

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

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


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

When res_rtp_asterisk.c was altered to avoid attempting to apply
unprotect algorithms to non-audio RTP packets, the test used was
incorrect. This caused the audio packets to not be decrypted and
resulted in loud white noise on the other endpoint (or both endpoints
depending on the call legs involved). The test now properly checks the
version field in the RTP header to ensure that RTP and RTCP are
decrypted while other types of packets are not.

(closes issue ASTERISK-21323)
Reported by: andrea
Tested by: Kinsey Moore, andrea, John Bigelow
Patches:
    whitenoise_fix.diff uploaded by Kinsey Moore
........

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

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


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

When authenticating a SIP request with alwaysauthreject enabled, allowguest
disabled, and autocreatepeer disabled, Asterisk discloses whether a user
exists for INVITE, SUBSCRIBE, and REGISTER transactions in multiple ways. The
information is disclosed when:
 * A "407 Proxy Authentication Required" response is sent instead of a
   "401 Unauthorized" response
 * The presence or absence of additional tags occurs at the end of "403
   Forbidden" (such as "(Bad Auth)")
 * A "401 Unauthorized" response is sent instead of "403 Forbidden" response
   after a retransmission
 * Retransmission are sent when a matching peer did not exist, but not when a
   matching peer did exist.

This patch resolves these various vectors by ensuring that the responses sent
in all scenarios is the same, regardless of the presence of a matching peer.

This issue was reported by Walter Doekes, OSSO B.V. A substantial portion of
the testing and the solution to this problem was done by Walter as well - a
huge thanks to his tireless efforts in finding all the ways in which this
setting didn't work, providing automated tests, and working with Kinsey on
getting this fixed.

(closes issue ASTERISK-21013)
Reported by: wdoekes
Tested by: wdoekes, kmoore
patches:
  AST-2013-003-1.8 uploaded by kmoore, wdoekes (License 6273, 5674)
  AST-2013-003-10 uploaded by kmoore, wdoekes (License 6273, 5674)
  AST-2013-003-11 uploaded by kmoore, wdoekes (License 6273, 5674)
........

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


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

AST-2012-014, fixed in January of this year, contained a fix for Asterisk's
HTTP server for a remotely-triggered crash. While the fix put in place fixed
the possibility for the crash to be triggered, a denial of service vector still
exists with that solution if an attacker sends one or more HTTP POST requests
with very large Content-Length values. This patch resolves this by capping
the Content-Length at 1024 bytes. Any attempt to send an HTTP POST with
Content-Length greater than this cap will not result in any memory allocation.
The POST will be responded to with an HTTP 413 "Request Entity Too Large"
response.

This issue was reported by Christoph Hebeisen of TELUS Security Labs

(closes issue ASTERISK-20967)
Reported by: Christoph Hebeisen
patches:
  AST-2013-002-1.8.diff uploaded by mmichelson (License 5049)
  AST-2013-002-10.diff uploaded by mmichelson (License 5049)
  AST-2013-002-11.diff uploaded by mmichelson (License 5049)
........

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


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

The format attribute resource for H.264 video performs an unsafe read against a
media attribute when parsing the SDP. The value passed in with the format
attribute is not checked for its length when parsed into a fixed length buffer.
This patch resolves the vulnerability by only reading as many characters from
the SDP value as will fit into the buffer.

(closes issue ASTERISK-20901)
Reported by: Ulf Harnhammar
patches:
  h264_overflow_security_patch.diff uploaded by jrose (License 6182)
........

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


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

The softbutton endcall should not turn a transfer into a blind transfer but
hangup the exten being called and leave the original call on hold. This does
that.

(closes issue ASTERISK-21321)
Reported by: wedhorn
Tested by: snuffy, myself
Patches: 
    skinny-xferendcall01.diff uploaded by wedhorn (license 5019)


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

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

In r373424, several reentrancy problems in chan_sip were addressed. As a
result, the SIP channel driver is now properly locking the channel driver
private information in certain operations that it wasn't previously. This
exposed two latent problems either in register_verify or by functions called
by register_verify. This includes:
 * Holding the private lock while calling sip_send_mwi_to_peer. This can create
   a new sip_pvt via sip_alloc, which will obtain the channel container lock.
   This is a locking inversion, as any channel related lock must be obtained
   prior to obtaining the SIP channel technology private lock.

   Note that this issue was already fixed in Asterisk 11.

 * Holding the private lock while calling sip_poke_peer. In the same vein as
   sip_send_mwi_to_peer, sip_poke_peer can create a new SIP private, causing
   the same locking inversion.

Note that this locking inversion typically occured when CLI commands were run
while a SIP REGISTER request was being processed, as many CLI commands (such
as 'sip show channels', 'core show channels', etc.) have to obtain the channel
container lock.

(issue ASTERISK-21068)
Reported by: Nicolas Bouliane

(issue ASTERISK-20550)
Reported by: David Brillert

(issue ASTERISK-21314)
Reported by: Badalian Vyacheslav

(issue ASTERISK-21296)
Reported by: Gabriel Birke
........

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

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


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

r375757 attempted to resolve a race condition between multiple submissions of
CDRs while in batch mode from attempting to destroy the scheduled batch
submission by extending the batch CDR lock. Unfortunately, this causes a
deadlock between the pending CDR lock and the batch CDR lock. This patch
resolves the intent of r375757 by simply providing a new lock that protects
the scheduling of the batches. The original batch CDR lock is kept to protect
manipulation of the batch CDR settings, but has been placed such that it
is not held when the pending lock is held.

Thanks to Chase Venters for providing lock analysis on the issue.

(issue ASTERISK-21162)
Reported by: Chase Venters
........

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

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


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

This code caused a compiler warning when --enable-dev-mode was not used.
The warning was that this variable was set but not used.  That was indeed
the case as the only place this is used is as an argument to SKINNY_DEBUG
which is compiled out when not in dev mode.


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

When an SLA trunk is ringing (inbound call on the trunk) Asterisk will
make outbound calls to the stations that have that trunk.  If more than
one station answers the call at the same time, all channels other than
the first one to answer are left in a bad state.  The channel gets
leaked, is not connected to anything, and there's no way to get rid of
it.

We now properly clean up these losing channels by hanging up on them.
Since they lost the race, as we process their answer, there is no
ringing trunk for them to answer.
........

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

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


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

The CALLEDTON channel variable is set for incoming ISDN calls to the lower
7 bits of the Q.931 type-of-number/numbering-plan octet.  The
CALLERID(dnid-num-plan) should have the same value.

(closes issue ASTERISK-21248)
Reported by: rmudgett
........

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

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


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

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

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