For incoming, if the source address is in the Match (Permit) list the call will be associated with the trunk and accepted.
There may be some subleties associated with incoming re-invites for outgoing calls; if Skyetel sends those, e.g. every 15 minutes to confirm that the call is still alive, test that after you get the basics working.
yeah, that makes sense but the SRV record does NOT include all their inbound routes (different IP’s for inbound and outbound but with some overlap). Also, if you refer to the KB link in my previous posts you can see at the very bottom that they tell you to repeat the process (aka one trunk per IP).
My calling works both in and outbound… but inbound just has the issue that when answered it hangs up. I’ve got this same service with the same firewall, on freepbx (different version though which uses chan_sip) and it works without issues. This being a fresh install and defaulting to PJSIP I left it as such so maybe it is just a matter of changing the trunks to use chan_sip or something.
I would first try setting up Match for Skyetel_Outbound (leaving other settings unchanged), temporarily disable the other trunks, test. If this works reliably, you’ll have a much simpler configuration, easier to maintain in the future.
Second choice, carefully compare all the settings for Skyetel_Outbound vs. Skyetel_SE, to see if you can spot something that could cause the hangup when SE is chosen. If not, use a SIP trace (or tcpdump if needed) to see what the difference is.
Finally, you could compare a working site with this one (configs, logs, SIP traces and/or packet captures as needed), to see what’s is different about the failing one.
Another thought: I may have misdiagnosed the issue as related to trunk selection. In your first example, Skyetel_Outbound was good but Skyetel_SE was bad. Possibly, that was just a coincidence and some other factor determines whether the call fails. Perhaps you have other logs (or can easily create them), to see whether trunk selection is consistently related to the failures.
If by setting up Match you force all calls via Skyetel_Outbound and you still get failures, it would be interesting to see whether all calls now fail, or only some.
OK so I’ve looked at all this and there are a couple things here.
Looking in the full log for this as a troubleshooting step is fine but it is not definitive or overly in depth for this. As @Stewart1 has asked for a couple times the actual SIP dialog/transactions need to be seen.
This has nothing to do with the Match (Permit) setting in the PJSIP trunk. It’s matching on an endpoint and routing things to the from-pstn context. If this was an unmatched endpoint it would never get that far.
The failed calls on disconnecting right after the 200 OK from Asterisk. So this isn’t an RTP/media issue with no RTP flowing this is the ACK from the provider not making to back to Asterisk in response to the 200 OK. Without that ACK, the call dies.
This is 100% a NAT issue and I’m going to put 98% of that on pfsense. Over the years I have had to deal with numerous people using pfsense and running into NAT issues like this. While it may not be here, on IRC in the #freepbx, #asterisk and other rooms I have dealt with this a lot.
The provider is doing IP auth/peering. I’m going to guess there is no qualify/keepalive set on the endpoint or the provider doesn’t respond to them. So without that and not sending a new REGISTER every 120 seconds or so the NAT holes are being dropped by pfsense. That means when the endpoint is idle for too long (no outbound/inbound calls) when the new incoming call comes in the NAT is not fully open and that ACK is not making it back for some reason. However, once that call fails and they call back immediately the NAT has been opened and that call can connect normally.
That’s the working theory anyways, please do what @Stewart1 asked and provide the output of set pjsip logger on so we can see a failed call and a completed call to compare. That will confirm the theory as it will show the 200 OK and the ACK (or the lack of the ACK) back from the provider.
Maybe. The failed call matched a different endpoint from the successful one. If that choice was determined by the source IP address, and one of the endpoints was not configured properly, that could certainly explain the trouble.
It’s neither – the call died within the same second after the 200 was sent. Both a lack of RTP and a missing ACK would involve a ~30 second timeout.
I tend to agree (unless it’s a simple trunk misconfiguration issue), but I strongly suspect that pfsense is butchering packets, rather than merely not passing them.
The good news is that it’s easy with pfsense to capture traffic on the WAN side, so it’s not hard to make it confess to its crimes.
First off, thank you to all that provided insight. It helped me narrow down issues and ignore rabbit holes.
I believe this issue was/is PJSIP related. After fiddling with a lot of recommended settings we saw no marked improvement on the issue. I ended up changing all the trunks to CHAN_SIP and the issue has vanished.
This was not a NAT issue and yes, pfsense can be troublesome if not configured properly, but it was not the firewall either.
The provider did some tracing on their end and found that some packets where coming in out of order and thought it may be a timing issue. They suggested disabling re-invites but I was unable to figure out how to do that in FreePBX GUI (probably could have done it via CLI but then I would have had to remember what I did in the future) so I never did do that.
I’m still not sure why changing from PJSIP to CHAN_SIP worked but it did and at this point I’m going to enjoy the small victory and go on to deal with other more pressing matters.