Asterisk Crashs


My asterisk crashed… can u help me?

Logs (/var/log/asterisk - message.log)

[Nov 29 20:36:10] WARNING[2192] chan_sip.c: Retransmission timeout reached on transmission 3b38a603349da70209e4b94578bcb213 for seqno 1 (Critical Response) – See
Packet timed out after 31999ms with no response
[Nov 29 20:36:18] WARNING[2192] chan_sip.c: Retransmission timeout reached on transmission d4f25f725b50ef98b6f5c9b7686fa900 for seqno 1 (Critical Response) – See
Packet timed out after 32000ms with no response
[Nov 29 20:36:56] WARNING[2323][C-00000004] file.c: Unable to open file /var/spool/asterisk/monitor/000048222098998/732-20161129203656-in.wav: No such file or directory
[Nov 29 20:36:56] WARNING[2323][C-00000004] res_monitor.c: Could not create file /var/spool/asterisk/monitor/000048222098998/732-20161129203656-in
[Nov 29 20:36:56] WARNING[2323][C-00000004] res_monitor.c: Cannot change monitor filename of channel SIP/ to 000048222098998/732-20161129203656, monitoring not started
[Nov 29 20:36:56] WARNING[2128] func_cdr.c: CDR requires a value (CDR(variable)=value)
)[Nov 29 20:36:56] WARNING[2323][C-00000004] pbx.c: Channel 'SIP/137.74.-00000004’ sent to invalid extension but no invalid handler: context,exten,priority=my-account,00048222098998,1
[Nov 29 20:40:14] ERROR[2417] chan_ooh323.c: Unacceptable ip 83.137.

Thanks & regards,

I’m not seeing a crash there but some errors and warnings.

Check your network path or NAT settings. That usually means that the server lost contatc with the peer after the communication begin.

Pretty clear, file doesn’t exist.

Something with your dialplan or maybe disk is full.

Bad dialplan and peer is not authenticated.

So check your dialplan and peer settings. And just for the sake of your server also the disk space.

1 Like

It’s more likely that the directory doesn’t exist and that the third group has the same underlying cause.

If the *'s in the last group are actually there, it could be a secondary fault from the cause of the crash, i.e. part of the memory corruption.

For actual crashes, you need back traces from the core image dump files. For deadlocks, you need to attach a debugger and get backtraces on the live system. Ideally you should also have thread debugging enabled and use “core show locks”, from the CLI, but that does have performance imlications…