I am not able to receive calls with FreePBX 13. Below is the trunk configuration I am using… do you see any thing wrong here? Please note I am registering with Vitelity via IP address. I copied the previous configuration settings from my older FreePBX deployment, but am not making any progress here…
Insecure=very is deprecated and replaced by “insecure=invite,port”.
Your settings directmedia=yes and directrtpsetup=yes don’t make much sense on a trunk.
In fact Vitelity requires a directmedia=no or canreinvite=no.
You aren’t using secret?
Also, why aren’t you sing a register string for your inbound trunk?
Try something like this in your inbound trunks settings:
type=friend
dtmfmode=rfc2833
username=whatever you have
secret=whatever
context=from-trunk
insecure=port,invite
canreinvite=no host=inbound37.vitelity.net; _(or whatever FQDN or IP address Vitelity gives you)
allow=ulaw
disallow=all
qualify=yes
And register string: username:secret@vitelityFQDN or IP address:5060
When you are on the Vitelity portal, upper right corner under support, you can select FreePBX support and you will be shown your proper trunk settings.
Thank you for your response. The FreePBX solution I am using now is: FreePBX 2.11.0.43
The configuration mentioned earlier works with that version of FreePBX. I understand there may have been several updates to the code since then, which causes the need to update items like insecure, thank you.
The authentication method I am using with Vitelity is mapping directly to the IP address. We are not using an account or sub account for authentication. That being the case, I opened a case with vitelity to confirm my SIP trunk settings as the new version of FreePBX 13 may have some unknown requirements.
Is there a way with in FreePBX 13 to verify if the system is trying to connect to vitelity? Some command in the CLI that will allow me to see if the trunk is attempting to connect and failing? Or, is there a command that I can use to validate the configuration is not erroring out?
You will find some info in the Asterisk CLI (asterisk -vvvvr), where you can also perform a SIP debug if needed. Sip set debug on (or debug for specific peer or IP).
You are both missing the point, you have posted that your trunk has :-
allow=ulaw
disallow=all
In your trunk config.
If you do that, you will never be able to make or receive calls over that trunk (certainly not ulaw as you apparently wanted it to be exclusive). Does that not make sense?
Thank you dicko for your response. Please note that the configuration at the top image does not have:
allow=ulaw
disallow=all
That was avayax made the potential suggestion, however, I did not add that content as not all the setting suggested applied. I have since updated my case with Vitelity asking for their needed configuration settings.
Besides that, is there anything else you see in the original config that would cause issues?
Well the directmedia etc as noted won’t work. with Vitelity you can do direct IP for both in and out if so enabled , but the servers will be specific to your vitelity trunk, if you use ip auth then no problem inbound, select the outbound host appropriate to your account, probably best to use
I suggest you turn SIP debugging on in the Asterisk CLI, call in and if nothing happens, fix your router, if something happens but it doesn’t go anywhere, then fix your inbound routes,.
My guess is you are using IP auth but haven’t set your router correctly to forward inbound calls to your PBX, If you use the alternate Vitelity “Registrations” process for your SubAccount it will likely work unless you have a dumb-ass router (there are a sh*t load of these routers out there, do you use a non-dumb-ass one?)
Seems as if I have some work to do with Vitelity. When I use the sub account as suggested earlier, it works. However, when I use the previous configuration with the IP address, it does not. Once I have more details from Vitelity, I will an update.
Vitelity will now only accept inbound IP routing on a sub account (and there are VERY GOOD REASONS why). it says so on their website, so if you don’t follow the rules . . . . .
I am back to trying to making this work again. I am able to successfully make calls via sub_account, not IP address. Vitelity is stating that the following is occurring:
SIP/2.0 401 Unauthorized
My User Details AND PEER Details for my inbound route is:
Also, if your configuration is the exactly the same in both the User and Peer settings, you should use “type=friend” and just set it up in the Peer section.
