Stasis: Fix StasisEnd message ordering

This change corrects message ordering in cases where a channel-related
message can be received after a Stasis/ARI application has received the
StasisEnd message. The StasisEnd message was being passed to
applications directly without waiting for the channel topic to empty.

As a result of this fix, other bugs were also identified and fixed:
* StasisStart messages were also being sent directly to apps and are
  now routed through the stasis message bus properly
* Masquerade monitor datastores were being removed at the incorrect
  time in some cases and were causing StasisEnd messages to not be sent
* General refactoring where necessary for the above
* Unsubscription on StasisEnd timing changes to prevent additional
  messages from following the StasisEnd when they shouldn't

A channel sanitization function pointer was added to reduce processing
and AO2 lookups.

Review: https://reviewboard.asterisk.org/r/4163/
ASTERISK-24501 #close
Reported by: Matt Jordan
........

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

Merged revisions 427789 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427790 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit is contained in:
Kinsey Moore
2014-11-13 15:46:48 +00:00
parent cc4c396647
commit 74e706878b
6 changed files with 181 additions and 153 deletions

View File

@@ -790,11 +790,6 @@ void stasis_app_unref(void);
*/
struct stasis_message_sanitizer *stasis_app_get_sanitizer(void);
/*!
* \brief Stasis message type for a StasisEnd event
*/
struct stasis_message_type *ast_stasis_end_message_type(void);
/*!
* \brief Indicate that this channel has had a StasisEnd published for it
*