<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 12, 2017 at 8:10 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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?<span class="gmail-HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>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><div>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_features.c:bridge_builtin_set_limits().  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.<br></div><br></div>There is currently no API call to allow access-to or changing-of the interval hook<br><div>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_channel() 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></div><div><br></div><div>Richard<br></div></div><br></div></div>