External Voicemail Hanging up or not Recognizing that Anyone is Speaking

Experiencing a strange issue that is completely random.

I have FreePBX running on a PC, on premise. I have no audio issues when I call out or when people call in. However, on a regular basis, when I, or any of our users, call out to someone’s cell phone and get their voicemail, the voicemail does not recognize that anyone is speaking. One of two things happens depending on the number we are calling that we are calling (Verizon, T-mobile, Spint, etc.); the call hangs up after 30 seconds or so because it thinks no one is there, or, the voicemail system will cut you off while you are leaving a message telling you that no message has been recoded because we are not speaking. I have also noticed that when this happens, if I hit # or any other key, the voicemail system does not recognize the key press. So either the call is disconnected or we hang-up and then call the number right back and this time it will work with no problems. The voicemail will answer and I am able to leave a message.

I have been able to duplicate this issue on two other systems. Both of those systems are FreePBX running in the cloud on a Vultr. And the exact same scenario occurs.

I can literally call a phone number, get the persons voicemail and leave a message with no problem, or call the same number and experience the issue that I described above. Then, call the number again and it will work with no issue.

I have no clue if this is a FreePBX issue, firewall issue, trunking issue (using Flowroute on all)…

Considering that they are different instances of FreePBX, different hardware and different firewalls, I’m not sure what the problem could be.

You will need to do some debugging on the SIP packets.

  1. SSH into the PBX
  2. Do: asterisk -rvvvvvvvvv
  3. Do either: pjsip set logger on or sip set debug on (PJSIP / Chan_SIP respectively)
  4. Make the call.
  5. Copy all of the call from the initial INVITE to the BYE
  6. Paste it on pastebin, give us the link to review.

Interesting problem. What is the approximate percentage of calls that go to mobile voicemail which fail? If this is small, are you reasonably certain that had the call been answered live, it would have been ok?

Are you using any codec other than ulaw on either the trunk or extension side?
Confirm that you aren’t using silence suppression anywhere.
Are you using direct media or re-invites (to get audio to flow directly between endpoint and trunk)?

For intermittent problems that occur infrequently, I run tcpdump on the server in the background, using a command such as
tcpdump -s 0 -C 100 -W 100 -w rbuf -Z root &

This writes all network traffic into a ring buffer of 100 files (rbuf00, rbuf01, …, rbuf99), each 100 MB. (It will use 10 GB of disk space.)

When you learn about a problematic call, find the file containing it, copy it to your PC and examine with Wireshark. If the signaling looks ok, check whether outbound audio was sent to the correct address and port and whether it actually contains the caller’s voice. You may also notice a pattern difference between working and failing cases.

I made a test call on Flowroute to a VZW mobile that went to voicemail. It was routed via Hypercube and I couldn’t see anything unusual about the signaling. Of course, this call didn’t fail.

Thanks for responding!

The percentage, as far as I can tell, is not very high. It happens to me maybe once a day if I am making 10 or 15 calls. It’s hard to say, honestly. I’ve never experience any audio issues if a call is answered so that is why it seems its just when vmail answers.

I’m not sure how to check for silence suppression or direct media or re-invites. If you are able to point me in the right direction, I would appreciate it.

I don’t see any codecs listed on the extension side under the advanced tab. On the trunk side, I have the following for outgoing calls on the SIP settings:


Under asterisk sip settings>codecs:

I will work on running the tcpdump in the background so I can see if I can get a good example of what is happening.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.