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] Pjsip segfault
On Fri, Jun 16, 2017, at 11:37 AM, Tomec Martin wrote: > On Fri, Jun 16, 2017, at 11:10 AM, Tomec Martin wrote: > > Hi, > > I am looking at issue > > https://issues.asterisk.org/jira/browse/ASTERISK-27037 and so far I have > > found that: > > In asterisk function ast_sip_send_stateful_response, we receive message > > via pjsip_tsx_recv_msg then prepare answer and send answer via > > pjsip_tsx_send_msg. > > Before we send the answer, the pjsip_transaction structure can be deleted > > by some pjsip callbacks. So the pjsip_tsx_send_msg is called with invalid > > pjsip_transaction. > > > > Is anybody aware of correct way how to prevent pjsip_transaction from > > being deleted? Or is there a way to determine that transaction was > > deleted (by some callback)? > > Have you determined what callbacks will occur that can cause it to > happen? Are you referring to timer entries for example? > > I can't tell exactly. We suspect that it could be caused by some bad > implemented webrtc client. > From the log it seems to some "transport error" while receiving message. > And the terminated transaction is then destroyed by timer: > [Jun 13 12:45:18] DEBUG[8093] pjproject: tsx0x7fe4bc0631a8 > ..Transaction created for Request msg REGISTER/cseq=2 > (rdata0x7fe494118e18) > [Jun 13 12:45:18] DEBUG[8093] pjproject: tsx0x7fe4bc0631a8 > .Incoming Request msg REGISTER/cseq=2 (rdata0x7fe494118e18) in state Null > [Jun 13 12:45:18] DEBUG[8093] pjproject: tsx0x7fe4bc0631a8 > ..State changed from Null to Trying, event=RX_MSG > [Jun 13 12:45:18] DEBUG[8092] pjproject: tsx0x7fe4bc0631a8 > State changed from Trying to Terminated, event=TRANSPORT_ERROR > [Jun 13 12:45:18] DEBUG[8092] pjproject: tsx0x7fe4bc0631a8 > Timeout timer event > [Jun 13 12:45:18] DEBUG[8092] pjproject: tsx0x7fe4bc0631a8 > .State changed from Terminated to Destroyed, event=TIMER > [Jun 13 12:45:18] DEBUG[8092] pjproject: tsx0x7fe4bc0631a8 > Transaction destroyed! > [Jun 13 12:45:19] DEBUG[8093] pjproject: tsx0x7fe4bc0631a8 > .Sending Response msg 200/REGISTER/cseq=2 (tdta0x7fe4bc1e5aa8) in state > Destroyed > We can replicate this only in production environment, but it is possible > to add some logging if needed... I think in order to determine the proper path forward we need to understand the specific scenario, the threads involved, and the specific interaction that caused it to happen. For example I wouldn't expect the above to happen, that is I don't know what would cause it to transition to a TRANSPORT_ERROR in that case if a message hasn't been sent yet (and it doesn't look one has yet). -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- 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] Pjsip segfault
On Fri, Jun 16, 2017, at 11:10 AM, Tomec Martin wrote: > Hi, > I am looking at issue > https://issues.asterisk.org/jira/browse/ASTERISK-27037 and so far I have > found that: > In asterisk function ast_sip_send_stateful_response, we receive message > via pjsip_tsx_recv_msg then prepare answer and send answer via > pjsip_tsx_send_msg. > Before we send the answer, the pjsip_transaction structure can be deleted > by some pjsip callbacks. So the pjsip_tsx_send_msg is called with invalid > pjsip_transaction. > > Is anybody aware of correct way how to prevent pjsip_transaction from > being deleted? Or is there a way to determine that transaction was > deleted (by some callback)? Have you determined what callbacks will occur that can cause it to happen? Are you referring to timer entries for example? I can't tell exactly. We suspect that it could be caused by some bad implemented webrtc client. >From the log it seems to some "transport error" while receiving message. And >the terminated transaction is then destroyed by timer: [Jun 13 12:45:18] DEBUG[8093] pjproject: tsx0x7fe4bc0631a8 ..Transaction created for Request msg REGISTER/cseq=2 (rdata0x7fe494118e18) [Jun 13 12:45:18] DEBUG[8093] pjproject: tsx0x7fe4bc0631a8 .Incoming Request msg REGISTER/cseq=2 (rdata0x7fe494118e18) in state Null [Jun 13 12:45:18] DEBUG[8093] pjproject: tsx0x7fe4bc0631a8 ..State changed from Null to Trying, event=RX_MSG [Jun 13 12:45:18] DEBUG[8092] pjproject: tsx0x7fe4bc0631a8 State changed from Trying to Terminated, event=TRANSPORT_ERROR [Jun 13 12:45:18] DEBUG[8092] pjproject: tsx0x7fe4bc0631a8 Timeout timer event [Jun 13 12:45:18] DEBUG[8092] pjproject: tsx0x7fe4bc0631a8 .State changed from Terminated to Destroyed, event=TIMER [Jun 13 12:45:18] DEBUG[8092] pjproject: tsx0x7fe4bc0631a8 Transaction destroyed! [Jun 13 12:45:19] DEBUG[8093] pjproject: tsx0x7fe4bc0631a8 .Sending Response msg 200/REGISTER/cseq=2 (tdta0x7fe4bc1e5aa8) in state Destroyed We can replicate this only in production environment, but it is possible to add some logging if needed... Martin Tomec -- _ -- 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] Pjsip segfault
On Fri, Jun 16, 2017, at 11:10 AM, Tomec Martin wrote: > Hi, > I am looking at issue > https://issues.asterisk.org/jira/browse/ASTERISK-27037 and so far I have > found that: > In asterisk function ast_sip_send_stateful_response, we receive message > via pjsip_tsx_recv_msg then prepare answer and send answer via > pjsip_tsx_send_msg. > Before we send the answer, the pjsip_transaction structure can be deleted > by some pjsip callbacks. So the pjsip_tsx_send_msg is called with invalid > pjsip_transaction. > > Is anybody aware of correct way how to prevent pjsip_transaction from > being deleted? Or is there a way to determine that transaction was > deleted (by some callback)? Have you determined what callbacks will occur that can cause it to happen? Are you referring to timer entries for example? -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- 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] Pjsip segfault
Hi, I am looking at issue https://issues.asterisk.org/jira/browse/ASTERISK-27037 and so far I have found that: In asterisk function ast_sip_send_stateful_response, we receive message via pjsip_tsx_recv_msg then prepare answer and send answer via pjsip_tsx_send_msg. Before we send the answer, the pjsip_transaction structure can be deleted by some pjsip callbacks. So the pjsip_tsx_send_msg is called with invalid pjsip_transaction. Is anybody aware of correct way how to prevent pjsip_transaction from being deleted? Or is there a way to determine that transaction was deleted (by some callback)? Thanks for any hints. Martin Tomec -- _ -- 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
