Re: [asterisk-dev] Updating call limits
On Fri, Jun 16, 2017 at 9:29 AM, Kaloyan Kovachev
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
>> 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
Re: [asterisk-dev] Updating call limits
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
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
Re: [asterisk-dev] Updating call limits
On Mon, Jun 12, 2017 at 8:10 AM, Kaloyan Kovachev 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
[asterisk-dev] Updating call limits
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? -- _ -- 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
