FreePBX 15.0.17.55
Just installed version 15 to try things out. I noticed a anonymous source is being reported in the asterisk info. Where is this coming from? It doesn’t exist on the extension list.
It’s a fake endpoint to allow some processing on a call that can’t be matched to an extension or trunk, for example to play an error announcement. It does not appear on my systems. Possibly it is not created if Allow SIP Guests is set to No (which is the more secure setting).
how do I get rid of it. BTw…I’m having issue connecting to my sip trunk provider. I’m wondering if this thing is mucking it up…
It’s unrelated to the connection problem, though an incoming call attempt that is messed up (by something previously wrong) might not be recognized as belonging to the trunk, so it would be processed by the anonymous endpoint.
Note that recent FreePBX defaults to pjsip on port 5060 and chan_sip on 5160. If (for example) you configured the trunking provider to send calls to port 5060 (where you used to have chan_sip), they will now be processed by pjsip which won’t recognize them.
I don’t know exactly…I’m trying to setup my trunk using pjsip on 5060. My provider tells me the server is sending bad authorization. It’s getting 401 Unauthorized error. Is there a reason why I shouldn’t try to delete this anonymous extension? If not, how do it delete it?
Sorry, I don’t know the answer to that (it disappeared automatically on my systems), but am quite certain that it’s not related to your issue.
I
Sorry, I don’t understand. His server or yours? On registration, an outbound call, or an inbound call?
At the Asterisk command prompt, type
pjsip set logger on
paste the Asterisk log showing a failing call or registration attempt at pastebin.freepbx.org and post the link here.
This is the information I got from my provider tech support as I’m troubleshooting why the trunk is not connecting. It’s likely my provider is not supporting pjsip. That aside, should the anonymous extension be deleted?
That’s very ambiguous. Do you mean that Asterisk is failing to register? Or that it registers but you aren’t getting calls? Or that an inbound or outbound call is failing?
There is no such thing. SIP is SIP and if your trunk is properly configured, it should work. (There are a few exceptions related to TEL URI and identifying by port.)
No, and in your situation, it’s a good thing that it is still there – a reference in the log to ‘anonymous’ indicates that an incoming request or response was not identified as belonging to your trunk.
Are you using registration or IP auth? If the former, does Asterisk show the trunk as registered? Does your provider? If the latter, have you configured Match (Permit) to include all the IP addresses from which the provider can send calls?
This is controlled by the Allow SIP Guest setting. YES = anonymous PJSIP endpoint is created. Set it to NO to get rid of the anonymous endpoint.
It’s ip auth…my provider tells my server authentication is be rejected (401 error). All my extensions are registered just fine.
I’ve just been informed there trunks don’t support pjsip
That statement doesn’t make sense. It’s like an ISP saying they don’t support German made routers or a car manufacturer saying they don’t support Asian drivers.
It is of course possible that pjsip is indeed incompatible with your provider, because one or both sides are in violation of the relevant RFCs. IMO that is very unlikely, but if you believe it to be the case, you should show configurations and logs as evidence. And, if the problem is on the pjsip side, you should submit a bug report.
First, confirm that your trunk config has Registration None and Authentication None. Also, confirm that Match (Permit) for the trunk lists (in the proper format) all the IP addresses from which your provider can send calls and in particular includes the address(es) from which they actually sent the failing calls.
If you still have trouble, paste a log with SIP trace as requested earlier and post the link.
Cancel your service with this provider as they are not qualified to be a SIP trunk provider as they are flat out telling you:
a. A lie because they are stupid
b. That their network does not actually use RFC compliant SIP.
Either way they are not a provider that you should place any trust in.
If you want to actually troubleshoot, post your configuration and logs. Otherwise nothing means anything because half of what you said makes no sense. It is not your fault, it is your provider confusing you.
Thanks for all you guys comments and support. Below is the original message I got from asterisk ( "# asterish -r "):
WARNING[18400]: res_pjsip_outbound_registration.c:837 schedule_retry: Temporal response ‘401’ received from ‘sip:xxx.xxx.com:5060’ on registration attempt to ‘sip:[email protected]:5060’, retrying in ‘60’
This is the message I’ve started the troubleshooting with my ISP.
My production server v14 is working just fine with the same ISP. It’;s connecting the trunk on chan_sip.
You are using sip registration. Yet you said it was IP based prior.
So one of the two things is wrong. Post your configuration as instructed.
Is this what you wanted to see
That’s the picture we wanted to see, but not with those contents.
Please set both Authentication and Registration to None.
The provider will authenticate you by the IPv4 address you entered on their portal (or possibly in a message you sent them). You authenticate the provider by setting SIP Server (and Match (Permit) if needed) correctly.
I’m having internet issue. I’ll have to continue this session tomorrow. I’ll make the change and let you know tomorrow. thx
Allow SIP Guests to “No” is not a more secure setting. In fact, a well known and very experienced user on these forums (and I believe a current Sangoma employee) has recommended changing the default to “yes” because “[t]here may have been legit reasons to have this setup in the past, but I’m pressed to figure out any value to these defaults on a system today.”
IMO- there was never any value to having it set to no, as long as your system was properly configured to handle guest calls that didn’t route to a valid DID.
If you’re relying on allow SIP guests to protect you, you’re focused on entirely the wrong thing.