Since a few updates ago, my inbound callers have not been able to record voicemails longer than 20 seconds. I have checked all the settings that I know how to check, but they all seem to be correct. The strange thing is that local calls (extension to extension calls) are fine – the voicemail can be as long as it needs to. Also when we transfer an inbound caller to another extension the same thing happens, they only get about 20 seconds before the PBX disconnects the call. As previously stated, this only started happening as of maybe 1 or 2 core updates ago… so I’m not sure what’s going on.
Has anyone else had this issue? Or does anyone know what the problem could be? Any help is greatly appreciated.
In /etc/asterisk/asterisk.conf, check that
transmit_silence_during_record = yes
Next, see what the Asterisk log shows on a failing call. If it’s not clear what is triggering the disconnect, at the Asterisk command prompt type
pjsip set logger on
sip set debug on
to see whether it’s Asterisk or the trunking provider that is issuing the BYE (presumably for lack of RTP).
THANK YOU VERY MUCH!!! That fixed the voicemail issue. We have been pulling our hair out trying to get that fixed. I don’t have the greatest knowledge of all the ins and outs of FreePBX. I just was able to get out server up and running with our SIP trunks and thats as far as my knowledge really goes (as far as troubleshooting).
But now I seem to have another issue.
When I place an outbound call, the PBX system dials like it should and the called party’s phone rings. However, if the person does not answer, typically the call will be transferred to the users’ voicemail, but instead, now I am getting “All circuits are busy now, please try your call again later” and the phone displays Q.850;cause=34.
At first, I thought it was just a voicemail issue (when testing with my cell phone) but if I decline the call my voicemail picks up as it should. To me, it seems like the system is canceling the call if the user does not pick up in an allotted time. Is this a thing, and if so, how would I fix it? — Removing the line from above (transmit_silence_during_record = yes) does not seem to help either.
Would you have any ideas for this?
Never mind, turns out it was just a provider related issue. All is good now.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.