your domain would best be your fully qualified name, and your endpoints would be best registering/qualifying against that name, and not the ip, if you do that your passed ‘spam calls’ will approach zero
My system shows pbx_variables.c: Setting global variable 'SIPDOMAIN' to '(my external IP)'
but receives incoming calls just fine, so I suspect that this is unrelated to your issue.
At the Asterisk command prompt, type pjsip set logger on
and make a failing test call.
Paste the relevant section of the Asterisk log, starting from the first line related to the call, through when the call was identified as anonymous, redacted as desired, at https://pastebin.freepbx.org and post the link here.
Also post:
Is the problematic trunk using registration, routing to host, or SIP URI?
If you have multiple trunking providers, do they all fail in this way?
Confirm that internal and outgoing calls work properly (the call leg from the extension to the PBX is an ‘incoming call’ to pjsip).
You need to add the addresses for the calls to your “Permit” line in the Advanced settings in your PJ-SIP Trunk definition. For example, 199.255.120.176 is listed as a call source that generates an error.
I understand that - but FreePBX was detecting these before, and now it’s not. It should be getting these from the provider like it did before, right? It should be based off of the subnet, but it’s not detecting the subnet range properly anymore.
Did you do what I suggested? I understand that you think this is all magic and should just work, but that isn’t always the case. There are a dozen reasons why this would stop working, so provide some logs showing the errors or try what we suggest. Sitting around for three weeks waiting for the magic to happen again isn’t going to get you where you want to go.
Perhaps if you actually read the thread it would help me avoid three weeks of sitting around.
I have already posted logs. Read them.
Explain to me how I’m supposed to fill in a whole subnet worth of IP addresses? One by one for a /24? Really, does that sound feasible for you?
The server works fine with the old version, getting theist as it should via the subnets.
I upgrade, and suddenly it gets one IP and doesn’t use the subnet.
That’s called a bug. I can’t report a bug to them because “it requires contacting support.” So I have to pay to tell them about a bug? Please.
Then I get your attitude because you didn’t really read the issue, you just wanted to comment. People who half-ass solutions for others don’t really put the products they’re “helping” with in very good light. And this is also a paid product? I think not.
I don’t think it’s too much to ask that a basic, fundamental, ALREADY WORKING piece continues to work. But hey, I guess things just don’t work like they used to. Most of it is because people just accept the “magic” not working anymore.
Gentlemen, lets please keep things civil shall we. Feel free to edit posts that don’t move the thread toward the goal.
@thetoad30 - if others were reporting similar issues, we might have some crowd expertise to draw upon, but as this seems to be an issue unique to you, I’m afraid the heavy lifting falls on your shoulders alone. Frustration is understandable, but please refrain from venting it here on our forum volunteers.
To the issue, the call traces you’ve provided only confirm what you originally state, that the inbound invite is being treated as anonymous. You now need to figure out why. Start fresh with a reload/restart:
fwconsole r
fwconsole restart
From Asterisk, the command
pjsip show identifies
will list all pjsip identifies, one of which will correspond to your your trunk. You can get more info with:
pjsip show identify XXXX
substitute the actual name. This should show that your match/permit line is being applied correctly.
