CUCM SIP Trunk to FreePBX for Voicemail

I have a PJSIP Trunk created between FreePBX and our CUCM PBX. I am using FreePBX as a voicemail server. When a user calls into CUCM and they don’t answer, it kicks them over to FreePBX to leave the voicemail. I have waited on the phone for around 15 seconds leaving the voicemail, then the system hangs up on me. I get this message in the logs:

VERBOSE[28197][C-00000023] app_voicemail.c: Recording was 0 seconds long but needs to be at least 1 - abandoning

Even though something has been recorded, it doesn’t pick up anything. Also, when I call in to listen to my voicemails, the system does not pick up any of the DTMF tones. I have verified with Cisco and they are sending over the trunk.

[2020-04-09 13:43:14] VERBOSE[27751][C-00000022] file.c: <PJSIP/SIP_TRUNK_TO_CUCM_PUB-00000021> Playing ‘vm-password.ulaw’ (language ‘en’)
[2020-04-09 13:43:25] VERBOSE[27751][C-00000022] app_voicemail.c: Incorrect password ‘’ for user ‘204’ (context = default)
[2020-04-09 13:43:25] VERBOSE[27751][C-00000022] file.c: <PJSIP/SIP_TRUNK_TO_CUCM_PUB-00000021> Playing ‘vm-incorrect.ulaw’ (language ‘en’)
[2020-04-09 13:43:26] VERBOSE[27751][C-00000022] file.c: <PJSIP/SIP_TRUNK_TO_CUCM_PUB-00000021> Playing ‘vm-password.ulaw’ (language ‘en’)
[2020-04-09 13:43:37] VERBOSE[27751][C-00000022] app_voicemail.c: Incorrect password ‘’ for user ‘204’ (context = default)
[2020-04-09 13:43:37] VERBOSE[27751][C-00000022] file.c: <PJSIP/SIP_TRUNK_TO_CUCM_PUB-00000021> Playing ‘vm-incorrect.ulaw’ (language ‘en’)
[2020-04-09 13:43:39] VERBOSE[27751][C-00000022] file.c: <PJSIP/SIP_TRUNK_TO_CUCM_PUB-00000021> Playing ‘vm-password.ulaw’ (language ‘en’)

I’ve seen this before when trunking FreePBX to cisco, you need to tweak the silence threshold in the freepbx voicemail config, inbound calls from cisco are too quiet so register as silence.

Thank you for your response. I changed the silence threshold from “128” to “50”. I was still having the same issue, so I changed all the way down to “0”. Still the same problem. It seems as if FreePBX is not configured properly for the SIP Trunk. Not only does the voicemail not record, but any buttons I press don’t register for the DTMF tones.

Sounds like no RTP then.

Yeah, that’s what I was thinking. I wasn’t sure where to start looking for the RTP issue. Seems in the FreePBX, the RTP starts at 10000 and ends at 20000. The CUCM side is 16384 to 32766. Is there a way to find what might be incorrect on the FreePBX side for RTP?

1 Like

Also, there is not firewall between the two devices. They are on the same subnet.

Does anybody have any ideas for this? I have used some resources for setting up FreePBX as the voicemail system for CUCM. This is the only piece currently not working. It would be great to have this big win!

You can adjust these in the Advanced Settings or the Trunk Config (IIRC) on the Asterisk side, but that’s still not likely to solve your problem. The CUCM server has to send the RTP to the server, and for whatever reason, the Asterisk server isn’t picking it up. Have you tried turning on the DEBUG options for your connection to see what SIP/RTP traffic is getting passed?

I have not. I know I opened a case with Cisco and they said that there is SIP/RTP traffic being sent, but the other end (Asterisk) is not picking up.

OK - there are a few things to look into. The first would be to use a tool to watch the RTP traffic and make sure the systems are both working from the right addresses. It’s possible that there’s an IP address conflict.

Next, make sure that the address the RTP traffic is sending from is accounted for in the Integrated Firewall. It’s possible that the voicemail server has been blacklisted by the PBX server.

Finally, make sure that the PBX server has a trunk set up (so there are no Anonymous or Guest interactions) and that the server is recognizing the inbound call to the voicemail correctly. You should be able to find this interaction in the /var/log/asterisk/full file. If you don’t see the exchange there, the firewall or an IP address issue will be your next logical places to look.

While it might seem like you haven’t changed anything that would make this stop working, please indulge us. Some system updates can reset things that were working to a non-working default, even though the Sangoma team tries to keep that from happening. Let us know what you find.

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