It’s certainly possible. The security fixes included nothing to do with PJSIP or bridging in any of the related area, so that would mean it could have been from 20.20.0 which has been out for a few weeks now.
Presumably a deadlock, but it’s just a guess. A core debug log leading up to it could also provide insight.
It’s certainly possible, but it’s an end result assertion - it doesn’t tell you how it got there. The assertion itself was also present in the prior versions of PJSIP.
I’m seeing an issue with PickupChan() where it works after an Asterisk restart, but after some time pickup stops working until Asterisk is restarted again.
From the log, PickupChan() does appear to find the target channel and enter the pickup path. The failure does not look like a channel lookup problem.
What I observe after the issue happens is:
Later PickupChan() attempts stop working.
The called extension can remain stuck in Ringing.
Restarting Asterisk clears the condition temporarily.
My suspicion is that something later in the pickup path is getting blocked, possibly around the channel move/masquerade or the related device/extension-state update.
One area I’m looking at is the new extension-state path.
the below is ai ,i do not trust but have a feeling it something in that area …
Device-state updates now use synchronous Stasis subscriptions, and extension_state_device_state_cb() appears to publish an extension-state message while still holding the extension-state object lock. If a subscriber/callback in that path needs related state/channel locks, it might explain the partially completed pickup and the extension state remaining stuck as Ringing.
You mentioned the latest releases. These don’t have the new extension state work, so are you not using the latest releases and instead the git branch?
then i think i am going back to remove the manager patch and see if it happens again
since nobody reported a issue with 20.20 like me
and iam testing the new manager patch maybe something there .
but do not see it .
side note why am i seeing this message did something change ?
[root@pbx5 asterisk-20.20.0]# asterisk -rx "devstate list"|grep RING Unable to access the running directory (No such file or directory). Changing to '/' for compatibility.
I wouldn’t expect the manager patch to do anything, since it doesn’t lock anything involved in pickup really. A backtrace would really show what is going on.
Are you in a directory that you’ve deleted elsewhere?
Something I have noticed is that performance changes are indirectly causing existing potential issues to occur more often, because things are faster resulting in threads executing faster.
Interesting that you mention that. I am noticing that a system running 22.10.0 has calls that my SIP proxy show as gone still up and alive. I also have rtp timeout set so if the calls went away Asterisks hould have hung up on them. I am doing some more troubleshooting to make sure this is not an ID10T error.
