Commit Graph

8 Commits

Author SHA1 Message Date
Richard Mudgett 0b9ab0c61a Remove extra CR/LF from AMI event.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396462 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-08 20:51:38 +00:00
Richard Mudgett 3f724fa493 Make bridge snapshots use prefixes.
* 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
2013-08-08 19:16:33 +00:00
David M. Lee 309d7e08f0 Clean up ast_json with ast_json_unref
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396143 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-02 17:29:52 +00:00
Mark Michelson 328e99f41d Make a couple of changes to help AMI events to be more clear in what is occurring.
* BridgeEnter now contains the unique ID of the channel that is to be swapped out, if applicable.
* There is a ParkedCallSwap event that is sent when a parked channel has a new channel take its place.

(closes issue ASTERISK-22193)
reported by Mark Michelson

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



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396107 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-02 14:13:04 +00:00
Kinsey Moore 03090a88ba Fix documentation replication issues
This prevents XML documentation duplication by expanding channel and
bridge snapshot tags into channel and bridge snapshot parameter sets
with a given prefix or defaulting to no prefix. This also prevents
documentation from becoming fractured and out of date by keeping all
variations of the documentation in template form such that it only
needs to be updated once and keeps maintenance to a minimum.

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395985 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-01 17:07:52 +00:00
David M. Lee e1b959ccbb Split caching out from the stasis_caching_topic.
In working with res_stasis, I discovered a significant limitation to
the current structure of stasis_caching_topics: you cannot subscribe
to cache updates for a single channel/bridge/endpoint/etc.

To address this, this patch splits the cache away from the
stasis_caching_topic, making it a first class object. The stasis_cache
object is shared amongst individual stasis_caching_topics that are
created per channel/endpoint/etc. These are still forwarded to global
whatever_all_cached topics, so their use from most of the code does
not change.

In making these changes, I noticed that we frequently used a similar
pattern for bridges, endpoints and channels:

     single_topic  ---------------->  all_topic
           ^
           |
     single_topic_cached  ----+---->  all_topic_cached
                              |
                              +---->  cache

This pattern was extracted as the 'Stasis Caching Pattern', defined in
stasis_caching_pattern.h. This avoids a lot of duplicate code between
the different domain objects.

Since the cache is now disassociated from its upstream caching topics,
this also necessitated a change to how the 'guaranteed' flag worked
for retrieving from a cache. The code for handling the caching
guarantee was extracted into a 'stasis_topic_wait' function, which
works for any stasis_topic.

(closes issue ASTERISK-22002)
Review: https://reviewboard.asterisk.org/r/2672/


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395954 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-01 13:49:34 +00:00
Matthew Jordan 56a90d435c Fix incorrect reference to stasis/bridging.h
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395381 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-25 04:18:05 +00:00
Matthew Jordan cafc115896 A great big renaming patch
This patch renames the bridging* files to bridge*. This may seem pedantic
and silly, but it fits better in line with current Asterisk naming conventions:
* channel is not "channeling"
* monitor is not "monitoring"
etc.

A bridge is an object. It is a first class citizen in Asterisk. "Bridging" is
the act of using a bridge on a set of channels - and the API that fulfills that
role is more than just the action.

(closes issue ASTERISK-22130)


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395378 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-25 04:06:32 +00:00