Got a minor, yet annoying issue: FreePBX 15.0.29 has migrated to Vultr-hosted VM (public IP) successfully, everything seems to work seamlessly except one thing. As the customers set ‘forward to’ phone numbers on their SIP devices, any re-directed inbound call comes to nowhere: target cell phone receives nothing, while CDR logs reports call to cell number BUSY, and Asterisk log gives ‘Everyone is busy/congested at this time (1:1/0/0)’ status.
This is likely a caller ID issue. By default, when forwarding a call, FreePBX attempts to send the number of the original caller. Because ‘spoofing’ caller ID is often used for malicious purposes, many trunking providers don’t permit sending a number that’s not yours, require signing a special agreement to do so, or have special technical requirements.
Did the system you migrated from pass the original caller’s number? If not, forcing the main company number in the trunk or outbound route should fix the problem. If yes, check the trunk settings and any custom dialplan you used to accomplish this.
If you still have trouble, at the Asterisk command prompt, type pjsip set logger on
or (if the trunk is still using chan_sip) sip set debug on
paste the Asterisk log for a failing call at pastebin.freepbx.org and post the link here. If you are too new to post links, just post the last 8 hex characters of the URL.
Another likely cause may be the format of the phone number being dialed. Some providers such as Twilio require that it be in E.164 format. This means make sure to have +1 for US phone numbers as prefix and + for non US numbers.
Looking at error logs from your cvall at the SIP trunking provider will likely pinpoint the underlying problem. For me and twilio this is at:
Appreciate your response! Well, I played a little with trunk CID options, but didn’t succeed as well as with Outbound CID tweaks. So here goes Asterisk log for a typical failed call… or better say last 8 characters of URL required:
You are missing timestamps in the log, which are significant when one is considering no-answer cases. You should use the full log file, not a screen scape.
It appears that Vitelity played an error announcement in early media (from 02:38:33 to 02:38:44). If this was played to the caller, it may give a clue as to why they rejected the call.
Otherwise, some guesses:
You have many codecs enabled, causing the INVITE to be fragmented, which might have caused them to parse it incorrectly. Try allowing only ulaw and alaw.
The Diversion header on line 635 shows only the extension number. In Advanced Settings, try toggling Send Diversion Headers.
Conceivably the square brackets in the display name could be causing confusion.
Otherwise, capturing the INVITE for a working outgoing call may show a difference that is causing the trouble.
Next, it’s possible that Vitelity is rejecting calls with a caller ID that’s not a number of yours. You can test this by temporarily setting Outbound CID for your extension and seeing whether an outbound call works.
Did forwarding the original caller’s number work on your old system? Using the same Vitelity account?
Do you need that functionality?
Appreciate your response! Well, disabling some codes didn’t fix the problem, experiments with Outbound CID didn’t help either, but trick with checking Generate Diversion Headers in Advanced Settings has resolved the problem completely. Yay! Thank you so much for your suggestions!