<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 16, 2017 at 9:29 AM, Kaloyan Kovachev <span dir="ltr"><<a href="mailto:kkovachev@varna.net" target="_blank">kkovachev@varna.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thank You for the answer!<br>
The caller's channel is enough for me, so it<br>
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:<br>
<br>
ast_heap_wrlock(features->inte<wbr>rval_hooks);<br>
for (idx = ast_heap_size(features->interv<wbr>al_hooks); idx; --idx) {<br>
struct ast_bridge_hook hook;<br>
<br>
hook = ast_heap_peek(hooks, idx);<br>
if ( hook->type == AST_BRIDGE_HOOK_TYPE_TIMER ) {<br>
// bridge_features_limits_copy -> remove -> modify -> re-add<br>
// or update in place ?<br>
}<br>
}<br>
ast_heap_unlock(features->inte<wbr>rval_hooks);</blockquote><div><br></div><div>It is a priority heap of next to expire timers. Simply changing a hook's timeout isn't enough.<br>You will have to remove it and re-add it to the heap. Otherwise you are likely to corrupt the<br>heap.<br><br></div><div>Richard<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
На 2017-06-14 01:01, Richard Mudgett написа:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, Jun 12, 2017 at 8:10 AM, Kaloyan Kovachev <<a href="mailto:kkovachev@varna.net" target="_blank">kkovachev@varna.net</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
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.<br>
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).<br>
<br>
What is the right way to update the call limit (and related warning time) - modify duration and warning inside ast_bridge_features_limits?<br>
And the second question is how to get access to the relevant structures/data are there any builtin functions to access them?<br>
</blockquote>
<br>
The new method wasn't designed for dynamic changes to the limit times. Since<br>
there was no way for a user to dynamically change them before, it was not a<br>
requirement that the new method be able to do so either. The old way simply<br>
checked each limit timer for every frame that passed through a straight forward<br>
two party bridge loop. The new way is more complicated because of the new<br>
bridging architecture. The new bridging architecture does not allow direct<br>
access to other channels in the bridge. A bridge can change from a simple two<br>
party bridge to a multi-party bridge at any time because each channel has its<br>
own caretaker thread and can be moved easily from bridge to bridge.<br>
<br>
You cannot simply modify the duration, warning, and frequency values in the<br>
ast_bridge_features_limits structure dynamically as you mention either. Those<br>
values are only used to construct up to three interval hooks by<br>
bridge_builtin_interval_featur<wbr>es.c:bridge_builtin_set_limits<wbr>(). It is those interval<br>
hooks that actually control the timing. The interval hooks are put into a priority<br>
heap where the next to expire hook timer is at the top of the heap. The bridge<br>
channel thread then waits for either the next interval hook timer to expire or a<br>
frame to arrive. The other change with the new way is that each channel gets<br>
its own interval timers with limits set depending upon if it is the chan or peer<br>
channel in the initial two party bridge. Each channel then acts independently<br>
on its own interval timers. There is currently no API call to allow access-to or changing-of the interval hook<br>
timers once they are set. It won't be easy to gain access to the necessary<br>
interval hook structures on both channels either. You can get close to locating<br>
the needed interval hooks by following this chain: with an ast_channel pointer use<br>
ast_channel_internal_bridge_ch<wbr>annel() to get the associated ast_bridge_channel<br>
pointer. With the ast_bridge_channel pointer dereference the features member<br>
which you then have access to the interval_hooks member. The interval_hooks<br>
heap is a heap of struct ast_bridge_hook_timer pointers. However, the<br>
interval_hooks heap is not searchable for specific hooks and following the chain<br>
may be hazardous because of all the links that need to be followed. You will<br>
definitely need to hold the channel lock to get the ast_bridge_channel pointer.<br>
Also the locking order to keep in mind is: ast_bridge locks ast_bridge_channel<br>
locks ast_channel. Locking against this order requires deadlock avoidance.<br>
<br>
Richard<br>
</blockquote>
</div></div></blockquote></div><br></div></div>