I am using mostly Voip.ms but heard good reports about Vitelity so decided to try their service. Unfortunately, they don’t like IAX and try to steer all customers to SIP trunks. All my other trunks are IAX so decided to try IAX anyway. Managed to get get outgoing calls working but can’t get incoming working. When I call the new DID, Vitelity support sends an email message:
“We received ‘CHANUNAVAIL’ when attempting to route the call to your server or device. This number is configured to route to the peer vxxxxxxx. This error usually means your server or device is not currently registered to our servers. Please make sure you are registered to the correct inbound server for your account as per the configuration samples found on the support page within the user portal and that you have selected the correct routing method for your DID(s) on the DIDs page.”
Due to their anti-IAX policy, Vitelity won’t help me figure it out. I have firewall forwarding all port 4569 traffic so doubt it’s a firewall problem. I’m running FreePBX 2.10 on Asterisk 10 and here are my trunk settings:
User Context vxxxxxxx
User Context vxxxxxxx
Register String vxxxxxxx:[email protected]
It’s probably an obvious mistake but I can’t see it. Anyone else have experience using IAX with Vitelity?
Thanks for any assistance!
To start a few of the commands you used just simply don’t exist, here is the list of valid keywords:
You can check registration status with ‘iax2 show peers’ command in Asterisk.
User Context should batch the username, iax does not have a dtmf mode and context needs to be from trunk.
None of this matters if the trunk is not registering.
You can use the ‘iax2 set debug on’ command to see the debug messages (don’t forget to turn it off).
It’s not that we “hate” IAX, its that it is non-standard and only works with a very small subset of IP PBX systems. While we still maintain some of our older Asterisk systems, we can’t promise that they will be around forever so we decided to drop support for IAX. If you absolutely need it for some reason, let us know and we will try to accommodate, but most certainly we want you to use SIP.
I’ve invested several more hours in an attempt to get incoming calls to work with no success. vcjdg at Vitelity emailed me following trunk settings:
register => xxxx_xxxxx:(password)@inbound41.vitelity.net
Checking iax_additional.conf shows this is exactly what I have. Per SkykingOH, I changed context=inbound to context=from-trunk but neither variation worked. I also deleted dtmfmode=auto since this is incorrect. I included qualify=yes so I could get a better look at what was going on. Also following SkykingOH, I checked IAX Info and can see Vitelity trunks listed in both Registry and Peers:
188.8.131.52:4569 N xxxx_xxxxx 184.108.40.206:4569 60 Registered
vitel-inbound/xxxx_xxxxx 220.127.116.11 (S) 255.255.255.255 4569 OK (62 ms)
vitel-outbound/xxxx_xxxxx 18.104.22.168 (S) 255.255.255.255 4569 OK (62 ms)
But still no success receiving inbound calls. Before I signed up with Vitelity I googled to see if they supported IAX. When I found info on their website about IAX, I paid my $35 to try their service. It can’t be that hard for Vitelity to check their log files and give me a hint what’s not working. It’s also hard to believe that IAX is that rare–lots of other vendors support it.
Did you turn on the IAX debugging?
Yes, turned on IAX debugging and can see reg successful and lots of poke-pong-ack activity. Nothing that looks like a failure or error message.
When I call from my cell to the Vitelity DID, I see nothing in the Asterisk log file, and if I watch my router with wireshark, I see no packets from Vitelity hitting my router as I do when I make a call to one of my Voip.ms DIDs. For some reason, Vitelity is getting a ‘CHANUNAVAIL’ and the call never reaches my location at all.
Try this in your IAX advanced settings (Settings, then Asterisk IAX Settings)
This is part of the IAX security settings. This will allow all ip’s to come in to your asterisk box.
Same behavior with requirecalltoken=no – the outgoing calls work perfectly. Incoming calls do not show in the asterisk log or even when monitoring the WAN port on the router.