I used to use version 2 and had setup Localphone.com as a trunk.
how do i enter the registration string and make sure all peer details are setup?
I don’t see all these settings in 17 and I cant just pate in these details…
the trunk is NOT working now…
Username: UN
Secret: PW
SIP Server: localphone.com
SIP Server Port: 5060
Context: from-pstn-toheader
From Domain: localphone.com
From User: UN
If you have trouble, with pjsip logger turned on, paste the Asterisk log for the failure (registration attempt, outbound attempt, or inbound attempt) at pastebin.com and post the link here.
I think i’m also having a firewall issue.
Localphone used to work with no problem with just whitelisting their IP.
Now its not even working on an out of the box install of FPbx17 with the default firewall.
What firewall rules would I need to make sure inbound traffic works?
Thanks for your help Stewart.
The domain and user made it work now for outbound calls.
inbound still not making it over to astersik at all (did a asterisk -rvvvvv not a peep…)
In Asterisk SIP Settings, confirm that External Address and Local Networks are correctly set. If you change these, after Submit and Apply Config, you must restart Asterisk.
Try setting expiration to 120.
If no luck, look at Reports → Asterisk Info → Registries. Does the trunk show as Registered? If not, paste a log of a registration attempt (with pjsip logger on).
If registered ok, run sngrep and report what, if anything, appears there on an incoming call attempt.
If nothing, post details about network (ISP, modem/gateway, separate router/firewall if present, any VoIP-related settings in network gear, etc.)
so strange…
outbound calls work, and when I call the internet phone number from another locaphone account on my phone app it goes through.
when I dial the inbound phone number pointed to it it does nothing and doesn’t hit the server. (I also made a wildcard inbound route … still nothing)
when I forward the inbound number to another phone number it goes though to that.
must be an issue at locaphone somewehre.
Maybe not. I don’t have any Localphone DIDs, but I do have Voxbeam, same company.
On US (and I assume CA) DIDs, they include STIR/SHAKEN headers in the incoming INVITE. If using SIP over UDP (I don’t know whether they support other transports), this results in an oversize packet that must be fragmented. Many router/firewall configurations don’t handle this correctly, so a complete reassembled packet never hits the server.
If this is your issue, you should be able to see the fragments on the router’s WAN interface. If you have DIDs in other than US/CA, they should work. If you can send a US call via a flaky provider who doesn’t certify, that should also work.
I haven’t seen this at all. There are up to three headers that get added for presenting the results of STIR validation:
The use of the standard PAI header is the most common, unless I ask my upstreams for more “enhanced data” this is the only header I get that shows basic STIR validation. P-Asserted-Identity: <sip:+1707NXXXXXX;[email protected]:5060>
These two headers are attached for full/enhanced results: P-Attestation-Indicator: A P-Origination-ID: 3f4feb19-ebfd-4423-87ea-a24d3ad4d9c0
The entire size of this packet is 1068 bytes, well below the RFC requirement of 1300 bytes before using TCP. Now unless the MTU of the router is set so low it can’t do the standard 1500 MTU there’s not going to be much problems.
Even after I take those three headers and remove them, then re-add the PAI header with standard CallerID and then add two more headers (so back to three) but now it’s going to have additional record-route header and VIA headers for going through my switch and Asterisk before hitting the end user. By the time it hits my users network (be it a PBX or various IP phones) the packet is about 1200-ish in size if I’m sending all the extra headers (non PBX users don’t need the extra headers). Never once have I seen any of the firewalls or routers freak out over that or consider it an oversize packet because it doesn’t qualify as an oversize packet.
So without seeing the SIP message content or size I highly doubt the packet is oversized.
Well I can see why. There are additional headers that have nothing to do with STIR/SHAKEN like the Accept header. The Allowed header has a lot more methods than what my upstreams send because they don’t do SUBSCRIBE NOTIFY PUBLISH etc…they’re sending more codecs that my upstreams or I do. All of that does add to the packet size.
But most importantly here is that they are sending the raw Identity header which would be large. The only reason anyone would be getting that from their upstream is if they are the ones doing the actual STIR validation. That means decoding the header to get the JSON data that was encoded and parsing the JSON along with doing proper verification of the attached certificate. In most case of people getting a SIP trunk from Flowroute, Telnyx, etc. they would be getting STIR validation data but already parsed and presented in the PAI header with maybe additional headers.
So I’m not sure why the average FreePBX user would be getting the raw Identity header unless for the reason I mentioned above.
