[asterisk-dev] Updating call limits

[Kaloyan Kovachev]

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);


На 2017-06-14 01:01, Richard Mudgett написа:

> On Mon, Jun 12, 2017 at 8:10 AM, Kaloyan Kovachev <kkovachev at 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