We have recently upgraded to certified/13.8-cert4 as well as 14.1.2 (several servers). On both versions we found that we would get 1-way audio when phones were in a queue, however, when they are called directly audio worked as expected. We resolved the queue issue by setting the dtmfmode to “inband” (it was “rfc2833”).
Everything seemed fine, but now if a device is using “inband” and the user tries to change their voicemail password asterisk becomes unresponsive, which requires a reboot. Switching back to “rfc2833” fixes this problem, but reintroduces the queue issue.
You would need to provide console output, sip debug (sip set debug on), and rtp debug (rtp set debug on) to understand exactly what is negotiated for DTMF. As for the deadlock the wiki has a guide[1] on how to acquire a backtrace to understand where it is blocked.
jcolp, Thank you for the response. I will do so ASAP. After further testing it has been revealed that the original symptoms are incorrect. Asterisk becomes unresponsive regardless of dtmfmode. The issue occurs when a new voicemail is setup (i.e., password = mailbox) after a “voicemail reload” has occurred. This does not happen after starting asterisk, only after a voicemail reload or a full “reload” from the CLI has occurred and then a new password changes is attempted.
A voicemail reload (or reload) from the CLI occurs.
A new voicemail is setup. When the user is asked for a new password and the user keys the password (twice), Asterisk dies every time.
Asterisk goes unresponsive 100% of the time under these conditions.
Voicemail files are not stored in a DB but voicemail_users is RT. Our configurations have been running without issue for about 4 years. When we ported our configs to a new version of Asterisk this started occurring.