Commit Graph

7 Commits

Author SHA1 Message Date
Matthew Jordan 38236e54a8 Remove dead code from features.c; refactor pickup code into pickup.c
This patch does the following:
 * It moves the pickup code out of features.c and into pickup.c
 * It removes the vast majority of dead code out of features.c. In particular,
   this includes the parking code.

(issue ASTERISK-22134)



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396060 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-02 02:32:44 +00:00
Matthew Jordan 5c4b482471 Support externally initiated parking requests; remove some dead code
This patch does the following:
 * It adds support for externally initiated parking requests. In particular,
   chan_skinny has a protocol level message that initiates a call park.
   This patch now supports that option, as well as the protocol specific
   mechanisms in chan_dahdi/sig_analog and chan_mgcp.
 * A parking bridge features virtual table has been added that provides
   access to the parking functionality that the Bridging API needs. This
   includes requests to park an entire 'call' (with little or no additional
   information, thank you chan_skinny), perform a blind transfer to a parking
   extension, determine if an extension is a parking extension, as well as the
   actual "do the parking" request from the Bridging API.
 * Refactoring in chan_mgcp, chan_skinny, and chan_dahdi to make use of the new
   functions
 * The removal of some - but not all - dead parking code from features.c

This also fixed blind transferring a multi-party bridge to a parking lot (which
was implemented, but had at least one code path where using the parking features
kK might not have worked)

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

(closes issue ASTERISK-22134)
Reported by: Matt Jordan



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396028 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-01 20:55:17 +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
Richard Mudgett c017d5e6a3 Remove the unsafe bridge parameter from ast_bridge_hook_callback's.
Most hook callbacks did not need the bridge parameter.  The pointer value
could become invalid if the channel is moved to another bridge while it is
executing.

* Fixed some issues in feature_attended_transfer() as a result.

* Reduce the bridge inhibit count in
attended_transfer_properties_shutdown() after it has restored the bridge
channel hooks.

* Removed basic bridge requirement on feature_blind_transfer().  It does
not require the basic bridge like feature_attended_transfer().


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395574 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-26 21:34:23 +00:00
Richard Mudgett 50aba6be36 Improved feature limits interval hook implementaion.
* Fixed feature limits to not use special members of struct
ast_bridge_features.

* Fixed memory leak in off nominal paths of bridge_builtin_set_limits().

* Fixed off nominal path in ast_bridge_features_limits_construct() freeing
unallocated memory if it was not called by bridge_builtin_set_limits().

* Made bridge_builtin_interval_features.so unloadable.

* Simplified parking's use of its duration interval hook.

* Made BridgeWait S option not depend upon another module being loaded.

(closes issue ASTERISK-22107)
Reported by: Matt Jordan

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395559 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-26 21:10:24 +00:00
Jonathan Rose 9a46c1d019 Add name argument to BridgeWait() so multiple holding bridges may be used
Changes arguments for BridgeWait from BridgeWait(role, options) to
BridgeWait(bridge_name, role, options). Now multiple holding bridges may
be created and referenced by this application.

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395509 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-26 16:34:56 +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