On Fri, Jun 16, 2017 at 9:29 AM, Kaloyan Kovachev <kkovac...@varna.net> wrote:
> Thank You for the answer! > The caller's channel is enough for me, so it > Just one more question when i walk trough the heap should i remove and > re-add the ast_bridge_hook_timer(s) or it is enough to update their values > in place: > > ast_heap_wrlock(features->interval_hooks); > for (idx = ast_heap_size(features->interval_hooks); idx; --idx) { > struct ast_bridge_hook hook; > > hook = ast_heap_peek(hooks, idx); > if ( hook->type == AST_BRIDGE_HOOK_TYPE_TIMER ) { > // bridge_features_limits_copy -> remove -> modify -> > re-add > // or update in place ? > } > } > ast_heap_unlock(features->interval_hooks); It is a priority heap of next to expire timers. Simply changing a hook's timeout isn't enough. You will have to remove it and re-add it to the heap. Otherwise you are likely to corrupt the heap. Richard > > > > На 2017-06-14 01:01, Richard Mudgett написа: > > On Mon, Jun 12, 2017 at 8:10 AM, Kaloyan Kovachev <kkovac...@varna.net> >> wrote: >> >> Hi, >>> I need to update the call limit of an active call, but the old method of >>> updating "struct ast_bridge_config" is not working anymore. >>> The fields 'timelimit', 'play_warning' and 'warning_freq' are used just >>> to populate the new interval hook and 'nexteventts' is completely unused >>> (and probably should be removed in trunk). >>> >>> What is the right way to update the call limit (and related warning >>> time) - modify duration and warning inside ast_bridge_features_limits? >>> And the second question is how to get access to the relevant >>> structures/data are there any builtin functions to access them? >>> >> >> The new method wasn't designed for dynamic changes to the limit times. >> Since >> there was no way for a user to dynamically change them before, it was not >> a >> requirement that the new method be able to do so either. The old way >> simply >> checked each limit timer for every frame that passed through a straight >> forward >> two party bridge loop. The new way is more complicated because of the new >> bridging architecture. The new bridging architecture does not allow >> direct >> access to other channels in the bridge. A bridge can change from a >> simple two >> party bridge to a multi-party bridge at any time because each channel has >> its >> own caretaker thread and can be moved easily from bridge to bridge. >> >> You cannot simply modify the duration, warning, and frequency values in >> the >> ast_bridge_features_limits structure dynamically as you mention either. >> Those >> values are only used to construct up to three interval hooks by >> bridge_builtin_interval_features.c:bridge_builtin_set_limits(). It is >> those interval >> hooks that actually control the timing. The interval hooks are put into >> a priority >> heap where the next to expire hook timer is at the top of the heap. The >> bridge >> channel thread then waits for either the next interval hook timer to >> expire or a >> frame to arrive. The other change with the new way is that each channel >> gets >> its own interval timers with limits set depending upon if it is the chan >> or peer >> channel in the initial two party bridge. Each channel then acts >> independently >> on its own interval timers. There is currently no API call to allow >> access-to or changing-of the interval hook >> timers once they are set. It won't be easy to gain access to the >> necessary >> interval hook structures on both channels either. You can get close to >> locating >> the needed interval hooks by following this chain: with an ast_channel >> pointer use >> ast_channel_internal_bridge_channel() to get the associated >> ast_bridge_channel >> pointer. With the ast_bridge_channel pointer dereference the features >> member >> which you then have access to the interval_hooks member. The >> interval_hooks >> heap is a heap of struct ast_bridge_hook_timer pointers. However, the >> interval_hooks heap is not searchable for specific hooks and following >> the chain >> may be hazardous because of all the links that need to be followed. You >> will >> definitely need to hold the channel lock to get the ast_bridge_channel >> pointer. >> Also the locking order to keep in mind is: ast_bridge locks >> ast_bridge_channel >> locks ast_channel. Locking against this order requires deadlock >> avoidance. >> >> Richard >> >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev