Also moves ACL messages to the security topic and gets rid of the
ACL topic

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



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

Also added some missing doc comments for stasis/app.h.


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

If DEBUG_THREADS is enabled __ast_rwlock_destroy causes a segfault while trying
to access a possible NULL t->track object.  A NULL check has been added before
trying to access the memory.

(closes issue ASTERISK-21724)
Reported by: Corey Farrell
Fixed by: Corey Farrell
Patches:
	ast_rwlock_destroy-segv.patch uploaded by Corey Farrell (license 5909)
........

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

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


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

The snapshot API contains an option that allow for combining of new 
and old messages within a single snapshot. New messages, however, 
include options beyond just 'INBOX' - it also includes the Urgent 
folder. A previous patch that combined INBOX and Urgent accidentally 
impacted snapshots that attempted to gain messages from just the Old 
folder. This patch fixes the snapshot gathering such that the API 
returns the appropriate messages for the folder selected, with and 
without the combine option.

This should make it more clear about what's happening.

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

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


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

This allows the SRTP library to be shut down properly when the
functionality is offered by libsrtp.

Review: https://reviewboard.asterisk.org/r/2538/
(closes issue ASTERISK-21719)
........

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

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


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

macros.


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

When implementing playback for stasis-http, the monolithicedness of
res_stasis really started to get in my way.

This patch breaks the major components of res_stasis.c into individual
files.

 * res/stasis/app.c - Stasis application tracking
 * res/stasis/control.c - Channel control objects
 * res/stasis/command.c - Channel command object

This refactoring also allows res_stasis applications to be loaded as
independent modules, such as the new res_stasis_answer module.

The bulk of this patch is simply moving code from one file to another,
adjusting names and adding accessors as necessary.

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


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

The debug versions of ao2_ref() should only be used if REF_DEBUG is
enabled so nothing is written to /tmp/refs unexpectedly.

(closes issue ASTERISK-21785)
Reported by: abelbeck
Patches:
      jira_asterisk_21785_v11.patch (license #5621) patch uploaded by rmudgett
Tested by: abelbeck
........

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


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

This moves the JSON event generators out of the Stasis-HTTP modules and
into standalone JSON-related counterparts so that Stasis-HTTP and
res_stasis can depend on them without creating dependency cycles. This
also provides a future location for Swagger Model validator functions
once the generators for that code are written.

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


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

The CALL-ID (ie [C-00000074]) is missing when logging to syslog.  This was just
an oversight when this feature was added.

* Add CALL-IDs when using syslog

(closes issue ASTERISK-21430)
Reported by: Nikola Ciprich
Tested by: Nikola Ciprich, Michael L. Young
Patches:
    asterisk-21430-syslog-callid_trunk.diff by Michael L. Young (license 5026)

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

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


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

The prior code committed, r385473, failed to take into consideration that not
all outgoing calls will be to a peer.  My fault.

This patch does the following:

* Check if there is a related peer involved.  If there is, check and set NAT 
  settings according to the peer's settings.

* Fix a problem with realtime peers.  If the global setting has auto_force_rport
  set and we issued a "sip reload" while a peer is still registered, the peer's
  flags for NAT are reset to off.  When this happens, we were always setting the
  contact address of the peer to that of the full contact info that we had.

(closes issue ASTERISK-21374)
Reported by: jmls
Tested by: Michael L. Young
Patches:
   asterisk-21374-fix-crash-and-rt-peers.diff by Michael L. Young (license 5026)

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

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


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

Adding the cleanup function needs some deeper thought since it
apparently doesn't exist for all variants of libsrtp.
........

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

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


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

(closes issue ASTERISK-21723)
Reported by: Corey Farrell
Patches:
    core-pbx-cleanup.patch uploaded by Correy Farrell (license 5909)
........

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

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


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

Ensure that libsrtp is shutdown properly when res_srtp is unloaded.

(closes issue ASTERISK-21719)
Reported by: Corey Farrell
Patches:
    res_srtp-library-shutdown.patch uploaded by Corey Farrell
........

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

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


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

(closes issue ASTERISK-21670)
Reported by: Snuffy
Review: https://reviewboard.asterisk.org/r/2473/
Patches:
    gulp-coding-guide.diff uploaded by snuffy (license 5024)



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

AMI actions must never return non-zero unless they intend to close the AMI
connection.  (Which is almost never.)

(closes issue ASTERISK-21779)
Reported by: Paul Goldbaum
........

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

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


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

* Made isdn_msg_parser.c build a progress message with the mandatory
progress indicator IE.  (The mISDNuser NT state machine rejected sending
the incomplete message.)

Note: The associated mISDN and mISDNuser patches respectively are viewable
here:
http://svnview.digium.com/svn/thirdparty?view=rev&rev=200
http://svnview.digium.com/svn/thirdparty?view=rev&rev=201

(closes issue AST-1153)
Reported by: Guenther Kelleter
Patches:
      progress-chan_misdn.diff (license #6372) patch uploaded by Guenther Kelleter
      progress-misdn.diff (license #6372) mISDN patch uploaded by Guenther Kelleter
      progress-misdnuser.diff (license #6372) mISDNuser patch uploaded by Guenther Kelleter
........

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

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


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

pbx_dundi added an io context without removing
it. This caused a memory leak when the module was
unloaded.

(closes ASTERISK-21718)
Reported by Corey Farrell
Patches:
	pbx_dundi-ast_io_remove.patch uploaded by Corey Farrell (License #5909)
........

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

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


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

After the merge of support for the realtime sorcery module, extensions that
contained a pattern were not being found through odbc realtime.  It was tracked
down to this one line that was advancing to the next variable list before it
should have been.  The removal of this one line fixes this.

Tested this fix on my machine.

Received confirmation that this is the right fix from file on IRC.


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

I've noticed when doing a graceful shutdown that the res_stasis_http.so
module gets unloaded before the modules that use it, which causes some
asserts during their unload.

While r386928 was a quick hack to get it to not assert and die, this
patch increases the use counts on res_stasis.so and res_stasis_http.so
properly. It's a bigger change than I expected, hence the review instead
of just committing it.

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


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

STASIS_MESSAGE_TYPE_*() macros.


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

This change adds a framework in res_stasis for handling events from
channel topics. JSON event generation and validation code is created
from event documentation in rest-api/api-docs/events.json to assist in
JSON event generation, ensure consistency, and ensure that accurate
documentation is available for ALL events that are received by
res_stasis applications.

The userevent application has been refactored along with the code that
handles userevent channel blob events to pass the headers as key/value
pairs in the JSON blob. As a side-effect, app_userevent now handles
duplicate keys by overwriting the previous value.

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


(closes issue ASTERISK-21180)
Patch-By: Kinsey Moore <kmoore@digium.com>


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

........

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


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

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

When we send out a CN packet (for instance, in the case of using rtpkeepalives),
we are not setting the payload code properly.  Also, we are setting the marker
bit when we shouldn't be according to RFC 3389, section 4.

AST_RTP_CN is not defined by AST_FORMAT codes.  Therefore, we should be using
ast_rtp_codecs_payload_code() rather than ast_rtp_codecs_payload_lookup().

11 and trunk already use the appropriate function.

* In 1.8, use ast_rtp_codecs_payload_code()

* Remove the setting of the marker bit

* Fix the debug message by incrementing the seqno after the debug message is set
  in order to display the correct seqno that was sent out

(closes issue ASTERISK-21246)
Reported by: Peter Katzmann
Tested by: Peter Katzmann, Michael L. Young
Patches:
    asterisk-21246-rtp-cng-payload-error_1.8_v2.diff
                                     uploaded by Michael L. Young (license 5026)

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

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

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


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

When the "ignorebusy" setting was deprecated, we added some code to allow us to
be compatible with older setups that are still using the "ignorebusy" setting
instead of "ringinuse".  We set a char *variable with the column name to use,
which helps the realtime functions to use the correct column in their SQL
queries.  When "persistentmembers" is enabled, we are not setting this variable
before the realtime functions were called to load members.  This results in the
variable being NULL and therefore causing a segfault when loading members during
the module's process of loading.

The solution was to move the code that sets that variable to be before these
realtime functions are called during the loading of the module.

(closes issue ASTERISK-21738)
Reported by: JoshE
Tested by: JoshE
Patches:
    asterisk-21738-rt-ringinuse-field-not-set.diff
                                     uploaded by Michael L. Young (license 5026)

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

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


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

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

A GCC bug[1] can, in some cases, pop up an unsuppressible pedwarn when
using a static inline standard library function from a non-static
inline function.

This normally doesn't show up, but can occur if you're running an
upgrade version of GCC (such as GCC 4.8 on OS X, which normally runs
GCC 4.2).

 [1]: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47816


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

The <arpa/nameser_compat.h> was introduced way back in OS X Panther, which
itself was end-of-lifed back in 2007. We can assume that any OS X machine
we build on will need that header file :-)

Why bother removing it? The flag we're checking (__APPLE_CC__) is actually
Apple's build number. Self-compiled versions of GCC (such as installing the
latest version of GCC from homebrew) sets the value to 0, making it useless
for this sort of compile flaggery.


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

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

Previously, a call to ast_load_realtime_multientry could get away with
passing a NULL parameter to the function, even though it really isn't
supposed to do that. After the change over to using ast_variable instead
of variadic arguments, the realtime engine gets unhappy if you do this.

This was always an unintended function call in app_directory anyway - now,
we just don't call into the realtime function calls if we don't have anything
to query on.

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

When we first introduced the channel blob types, the JSON blobs were
self identifying by a required "type" field in the JSON object
itself. This, as it turns out, was a bad idea.

When we introduced the message router, it was useless for routing based
on the JSON type. And messages had two type fields to check: the
stasis_message_type() of the message itself, plus the type field in the
JSON blob (but only if it was a blob message).

This patch corrects that mistake by removing the required type field
from JSON blobs, and introducing first class stasis_message_type objects
for the actual message type.

Since we now will have a proliferation of message types, I introduced a
few macros to help reduce the amount of boilerplate necessary to set
them up.

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


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

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

An endpoint is an external device/system that may offer/accept
channels to/from Asterisk. While this is a very useful concept for end
users, it is surprisingly not a core concept within Asterisk itself.

This patch defines ast_endpoint as a separate object, which channel
drivers may use to expose their concept of an endpoint. As the channel
driver creates channels, it can use ast_endpoint_add_channel() to
associate channels to the endpoint. This updated the endpoint
appropriately, and forwards all of the channel's events to the
endpoint's topic.

In order to avoid excessive locking on the endpoint object itself, the
mutable state is not accessible via getters. Instead, you can create a
snapshot using ast_endpoint_snapshot_create() to get a consistent
snapshot of the internal state.

This patch also includes a set of topics and messages associated with
endpoints, and implementations of the endpoint-related RESTful
API. chan_sip was updated to create endpoints with SIP peers, but the
state of the endpoints is not updated with the state of the peer.

Along for the ride in this patch is a Stasis test API. This is a
stasis_message_sink object, which can be subscribed to a Stasis
topic. It has functions for blocking while waiting for conditions in
the message sink to be fulfilled.

(closes issue ASTERISK-21421)
Review: https://reviewboard.asterisk.org/r/2492/



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

RFC6665 4.2.2: ... after a failed State NOTIFY transaction remove the subscription

The problem is that the State Notify requests rely on the 200OK reponse for pacing control
and to not confuse the notify susbsystem.
The issue is, the pendinginvite isn't cleared if a response isn't received,
thus further notify's are never sent.

The solution, follow RFC 6665 4.2.2's 'SHOULD' and remove the subscription after failure.
  
(closes issue ASTERISK-21677)

Reported by: Dan Martens
Tested by: alecdavis
alecdavis (license 585)

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

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

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


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

The \example tags marks an entire file as an example, not a code snippet.


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

The \example tags marks an entire file as an example, not a code snippet.
........

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


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

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

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

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