Fix bridge/channel AMI event ordering issues

The stasis_cache_update messages are somewhat cumbersome to handle
with the stasis_message_router. Since all updates have the same
message type, they are normally handled with the same route.

Since caching itself is a first class component of stasis-core, it
makes sense for the router to handle the cache update messages itself.
This patch adds stasis_message_router_add_cache_update() and
stasis_message_router_remove_cache_update() to handle the routing of
stasis_cache_update messages.

This patch also corrects an issue with manager_{bridging,channels}.c,
where events might be reordered. The reordering occurs because the
components use different message routers, which they needed because
they both needed to route cache update messages. They now both use
manager's router, and add cache routes for just the cache updates they
are interested in.

(closes issue ASTERISK-22038)
Review: https://reviewboard.asterisk.org/r/2677/


git-svn-id: http://svn.asterisk.org/svn/asterisk/trunk@395118 f38db490-d61c-443f-a65b-d21fe96a405b
Continue events when ARI WebSocket reconnects

This patch addresses a bug in the /ari/events WebSocket in handling
reconnects.

When a Stasis application's associated WebSocket was disconnected and
reconnected, it would not receive events for any channels or bridges
it was subscribed to.

The fix was to lazily clean up Stasis application registrations,
instead of removing them as soon as the WebSocket goes away.

When an application is unregistered at the WebSocket level, the
underlying application is simply deactivated. If the application
WebSocket is reconnected, the application is reactivated for the new
connection.

To avoid memory leaks from lingering, unused application, the
application list is cleaned up whenever new applications are
registered/unregistered.

(closes issue ASTERISK-21970)
Review: https://reviewboard.asterisk.org/r/2678/


git-svn-id: http://svn.asterisk.org/svn/asterisk/trunk@395120 f38db490-d61c-443f-a65b-d21fe96a405b
Add DTLS-SRTP support to chan_pjsip

This patch introduces DTLS-SRTP support to chan_pjsip and the options
necessary to configure it including an option to allow choosing between
32 and 80 byte SRTP tag lengths.

During the implementation and testing of this patch, three other bugs
were found and their fixes are included with this patch. The two in
chan_sip were a segfault relating to DTLS setup and mistaken call
rejection. The third bug fix prevents chan_pjsip from attempting to
perform bridge optimization between two endpoints if either of them is
running any form of SRTP.

Review: https://reviewboard.asterisk.org/r/2683/
(closes issue ASTERISK-21419)


git-svn-id: http://svn.asterisk.org/svn/asterisk/trunk@395121 f38db490-d61c-443f-a65b-d21fe96a405b