[asterisk-dev] Updating call limits

[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/20170613/6c8e16f9/attachment.html>