Friends,
I have been beating my head against the wall all day on this and just cannot figure it out. I am setting up a FreePBX distro with a SIP trunk from FirstComm. They claim there is no ID or secret to use, they use the external IP address for security. On my PBX, I have ETH0 as the LAN and default gateway there. ETH1 is the external IP that Firstcomm wants me to use. I have a static route for the SIP trunk IP out through ETH1. Firewall is turned off. This is the same type of config I have done for years on many different providers. I have been playing with trunk settings, adding and removing a myriad of settings and cannot get calls to move in or out. If I do a SIP debug (when I set qualify=yes), I see the PBX attempting to register and not getting a reply.
If I try to make a call in our out - the call just sits and never goes anywhere, just silence. The SIP provider has no clue… Im thinking that I need to put the external IP into that string its sending (instead of the ETH0 local lan .11 address), but I don’t know where to do that? Ive never had to do this before with any other provider… WHat can I send? The current trunk settings are:
Currently inbound is blank - but I have tried many of the above settings in there too…If I ping the SIP trunk 216 address from the console, it responds fine. Traceroute shows it going out through ETH1 so I think the networking part is OK
Hopefully this makes sense - let me know what else I can give. This is the latest FreePBX distro with all updates as of 6-4-2020
Does eth1 has a public static IP? If so, you need to set it on the SIP settings on the settings menu. If the trunk is trying to register but your provider says you don’t need username or password, then no registration is needed and the trunk should not be trying to register.
Looks like the provider is not proxying RTP. Routing the SIP server address alone to eth1 is not enough. RTP traffic can come from/goto anywhere. If the default gateway is eth0, then all the audio traffic is going out the wrong interface.
173.161.38.17 appears to be an address from Comcast assigned to US Waterproofing in Illinois. Is any of that familiar, perhaps the location of a remote extension?
168.93.99.x is assigned to FirstComm. Are they your ISP as well as your trunking provider? If not, please explain the setup. If yes: Why do you have the default gateway on eth0? Is there a different ISP providing that?
You have more configurability with PJSIP. I can’t test your scenario myself, but I think you should try using that channel driver instead. In the PJSIP transports, you can define the IP address you want to use.
Thanks for all the help everyone. I have narrowed this down to an actual networking problem… Your guidance certainly helped. To Bill that suggested pjsip - this provider specifically doesn’t support pjsip, only legacy sip - so that wont help this time, but thanks for the reply. To the others, I think flipping the default gateway to the external interface will be the answer - but now that I have done that, I can see this connection isn’t going anywhere anyway. The traceroutes and pings were being rerouted over the internal LAN connection… I missed that part. Thanks all - ill post back when I finally get it.
I see this written all the time and it makes ZERO sense. It’s like a car manufacturer saying they don’t support gas purchased at Shell. Gasoline is manufactured to specific standards to which the engine specifications conform. The same is (largely) true of SIP. From the point of view of your provider, they would have no way of knowing what SIP driver you are using locally on your PBX.
It’s probably more accurate to say that they won’t help you set it up if you’re using PJSIP. Customers who are being told this should be pushing back a little bit. PJSIP is the current supported driver, and refusing to support customers using it means they will eventually lose their Asterisk customers.
I will be the first to admit this is above my paygrade. But, I know when I setup one with AT&T a long time ago, when Pjsip was first put in, they kept rejecting everything being sent until I changed everything over to legacy sip. Firstcomm specifically said legacy sip on 5060 only. But, they have been useless as far as asterisk is concerned anyway - all thy could send was some old trunk config sheet from a trixbox screen shot…
This is the real problem. The provider put some minimal effort into a setup document 15 years ago and hasn’t looked at it since.
You can’t argue with success. If one works and the other doesn’t then you go with what works. The average user is probably not in a position to figure out why. You just need to know that using chan_sip today means starting out with a bit of technical debt that will need to be addressed eventually.
Understood. I remember AT&T not being much help either. Its amazing to me how the mainstream providers STILL don’t really support setting up their trunks on Asterisk - and I have been setting these up since 2006. Everytime I tell them its FreePBX over Asterisk - they glaze over and cant help. That’s AT&T, XO, Comcast (and now FirstComm). Thanks for replying - im still chasing this one…
I think that’s because many front line or second tier individuals at providers don’t actually understand SIP at all, or the properties of the deployment of the provider. SIP is SIP in the end, and it’s really in how the deployment/policy is that alters the configuration. They just know the magic values to put in in some places for solutions that use them.
Speaking from the perspective of someone who has supported people across the forums as well as internally (Switchvox has been exclusively PJSIP since February 2016) I’ve found PJSIP not working generally comes down to three things:
The configuration in use doesn’t match the chan_sip configuration. It’s different and it yields different behavior.
The provider relied on inherent broken behavior in chan_sip to work as a result of spinning SIP their own way out of spec. A great example is chan_sip not actually implementing SRV/NAPTR/failover correctly/at all. Some providers rely on that brokenness, despite being set up to do it properly. Since 16 and above support it properly stuff can fall apart.
Probably could be lumped into 1 or 2, but counting it separately - extra configuration is required because of PJSIP better complying to the SIP specification.
You lost me after “I think” lol. Just kidding. I get it, Reminds me of when everyone got together and agreed on an ical standard. Microsoft went off and did their own thing and didn’t conform to the standard they had agreed to. IBM did conform with Lotus domino. But the two have trouble talking to each other - IBM says "we followed the standard, we aren’t changing. Microsoft said. We’re Microsoft… it works if its all Microsoft… we’re not changing it.
I wanted to get back to the group to explain what happened in case anyone is searching in the future. Client had a sip trunk coming in on a port with data. Vendor required him to use one of his public IP for the SIP trunk. No authentication, they limit the SIP traffic from his public IP only as their security. Had the normal turnup call. Because of the lockdown, I wasn’t on site, relying on local IT to plug the wire from the ETH1 on the PBX to the 5 port basic switch that his data connections already were plugged in. Its his backup data from this vendor. Interface showed connected, I setup the static IP, etc. Some traffic seemed to move, some didn’t. I could ping the SIP gateway address fine. Calls still weren’t moving in or out. Vendor was sending option pings and not showing a connection. My side showed “unreachable” when I would set “qualify=yes”.
End result was that the switch was bad. I had local IT plug a PC into the switch and assign the public IP to it and he couldn’t go anywhere either. Then had him remove the switch and plug the PBX directly into the AdTran and calls instantly started moving fine. So, the switch showed a connection, seemed to ping OK, but wouldn’t work long enough to get the trunk up and running. Thanks to all that helped, sometimes the simplest thing is the easiest.
