This happens when something has blocked handling of media from the Local channel. What exactly are you doing with Asterisk? Grabbing a backtrace[1] for a deadlock would allow seeing where it is blocked.
We used in our company for receive call with sip and E1 and “ext to ext” call.
Using backtrace take memory and cpu usage a lot? because server is working now with 100 extentions.
The only way to know what is going on at the time is a deadlock backtrace as previously mentioned. Are you sure that’s all you do in your dialplan? Do you use any non-core supported modules? Using things in creative ways?
You can run Asterisk using any way you want for a deadlock. Yes, that is the command to run. I don’t understand what you mean by “What below command take time?”. After it’s done you would need to file an issue[1] and provide the result.
A few seconds to a bit longer, ultimately it depends on the system itself, how much memory is being used by Asterisk, how active it is. The amount of time it takes isn’t a set amount.
Enabling DEBUG_THREADS can seriously impact performance and should only be enabled if you suspect a deadlock may be occurring.
MALLOC_DEBUG can also impact performance but the impact is not very noticeable.
So if you did that, then that would be expected. It wasn’t really required yet for this issue. Otherwise you’d need to be more specific on what you did.
asterisk don’t freeze after i enable those debug, so tell me what can i do to solving problem?
if i disable again, i cant find first problem, so what can i do?