[asterisk-dev] Updating call limits

[Richard Mudgett]

On Fri, Jun 16, 2017 at 9:29 AM, Kaloyan Kovachev <kkovachev at 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 <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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20170616/bc167c95/attachment.html>