Default Inbound Route Gets Busy Signal - Trunk Issue?

Brand new setup of FreePBX 16. I have one PJSIP trunk configured and I can see that it’s registered in Reports → Asterisk Info → Registries. When I dial the number from my cell phone, I get a very short ring then busy signal. I have one inbound route configured with the DID and Caller ID set to ANY. This should be a default, catch all inbound route. I’ve tried setting the destination to my IVR and to a specific extension, but I get a busy signal either way. When I shut down the PBX server, calling the number results in the exact same behavior. This makes me suspect that my trunk may not be fully registered or configured correctly. Can someone offer advice on what to check next?

Providing Great Debug - Support Services - Sangoma Documentation (atlassian.net)

  • Do you see the call attempt in the log?

  • You are registered to the trunk, but does the other side show registered to you?

  • Do you see the call attempt in the log? -where / how can I check this? ‘ship show registry’ in this version does not appear to be working. Not sure what / where the current version logs either.

  • You are registered to the trunk, but does the other side show registered to you? I can reach out to the vendor. They don’t offer phone support and it would be helpful (because of call attempts with time stamps) to have something close to real time. This would be a best effort but I’ll ask.

First, check what you can on the provider’s portal. With some, you have to configure the DID to associate it with a particular account, sub-account or trunk. If they offer call forwarding, either as failover when your PBX is down, or unconditionally, try enabling that to confirm the DID is working.

What logs do they offer? If failed calls get logged, is anything shown for your failed attempts?

Do outgoing calls work properly? Do they show your DID as caller ID?

Confirm that in Asterisk SIP Settings, External Address and Local Networks are correctly set. If you change these, after Submit and Apply Config, you must restart Asterisk.

On an attempted incoming call, what, if anything, appears in the Asterisk log (can be viewed in Reports → Asterisk Logfiles (the raw file is /var/log/asterisk/full) ? If nothing, run sngrep and report what, if anything, appears there. If also nothing, post make and model of your router/firewall, and any VoIP-related settings you have made there. Does your router have a public IPv4 address on its WAN interface? If not, please explain (ISP gateway configured as router, ISP does CGNAT, etc.)

The link I placed in my post, if you read it, it will provide the answer this question.

Unfortunately, the provider doesn’t have a portal. They are responsive to email and I’ve done some back and forth. They are telling me now they DO see a registration from the IP of my new box. I have temporarily opened up all ports on my hardware firewall and I have the FPBX firewall disabled (again, temporarily). There is nothing in the logs that I can see relating to call traffic. I do see the registration details as follows (I have redacted my credentials on purpose):

11971	[2024-01-31 22:39:21] VERBOSE[2289] asterisk.c: Asterisk Ready.	
11972	[2024-01-31 22:40:14] VERBOSE[2487] res_pjsip/pjsip_configuration.c: Endpoint XxXX is now Reachable	
11973	[2024-01-31 22:40:14] VERBOSE[2487] res_pjsip/pjsip_options.c: Contact XxXx/sip:[email protected]:5060 is now Reachable. RTT: 198.511 msec

Just got an update from the SIP provider. They said “You are proxy challenging the inbound call. Look for a setting insecure=port,invite” Any suggestions on where to find that. I’m on V16 and don’t see it in the pjsip settings / advanced

This is done in a different way for chan_pjsip, but the advice is faulty, even for old versions of chan_sip, as only insecure=invite addresses the issue; insecure=port is not needed, but gets added by copy and paste coding.

You will be challenging them either because have auth= when you should only have outbound_auth=, or because you don’t have a type=identify section that matches the address from which they are originating the request.

Translating this to FreePBX, the outbound_auth part is the direction of authentication, and the type=identify section is the match/permit settings.

Note that your log entries provide no evidence of a successful registration.

There will be log entries relating to your bogus challenge.

The last 2 log entries are the trunk. That’s not a successful registration???

Either way, where would I add the string? There are no peer details like there used to be for SIP trunks.

No , that’s an indication that the host(trunk) is ‘re-available’ , presumably in a short while it will ‘re-register’.

If it is possible to use ip/url based auth rather than registration it would be quicker, but if your network or provider is flaky, you need to fix that first

First, confirm that your trunk has Authentication Outbound (not Both). Next, it’s possible that Telasip sends calls from a addresses other than where you registered, or that your firewall rewrote the port number so Asterisk didn’t recognize it. At the Asterisk command prompt, type
pjsip set logger on
(you should see PJSIP Logging enabled)
then attempt an inbound call.
Take the relevant section of the Asterisk log (from /var/log/asterisk/full), redact as desired, paste it at pastebin.com and post the link here. Also, post router/firewall make/model.

It’s done through the GUI, see Authentication in the screenshot in FreePBX + Didww pjsip outbound trunk registration fails (note the rest of the thread won’t relate to your specific case - I would have used the user guide, if I could have found it).

This will only work if the provider is being correctly recognized, and the setting for that is on the Advanced Tab (Match / Permit), if they send from a different address from that which you use to send to them.

This appears to have been the issue. Changing from Both to Outbound allows calls to come in on the trunk. Thank you everyone!

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.