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