Using Freepbx 15.0.16.38 GUI, changing the trunk CallerID source caused the trunk to no longer be found as an endpoint

FreePBX Providers
1

Using the Freepbx GUI 15.0.16.38 I modified the callerid source for my trunk that was working under pjsip, and when I reloaded the config, the trunk no longer worked. Making an outbound call, I get the following in my /var/asterisk/full.

Checked the obvious to see that I didn’t change anything related to the name of the trunk, and everything is in agreement. Looking in the pjsip.endpoint.conf file the trunk entry looks good. The “outbound_auth=” has the trunk name in it, but there in no section in the file for that stores the actual authentication. Oddly, running the CLI and issuing the "pjsip show registrations does show the trunk as registered.

So using the Freepbx GUI to manage the trunk, why now did the pjsip trunk suddenly stop being found as an endpoint which in turn seems to prevent pjsip from creating a channel for the trunk?

Been troubleshooting for a few days now, this is my home system, so I can keep it down for s bit, but I would like to solve this issue so I can avoid it in the future.

Thanks,
Greg Guldenschuh

[2020-01-04 12:51:20] VERBOSE[26486][C-00000003] pbx.c: Executing [[email protected]:26] Dial(“PJSIP/2201-00000002”, “PJSIP/[email protected],300,Tb(func-apply-sipheaders^s^1,(4))”) in new stack
[2020-01-04 12:51:20] ERROR[24013] chan_pjsip.c: Unable to create PJSIP channel - endpoint ‘Teli-Inbound’ was not found
[2020-01-04 12:51:20] WARNING[26486][C-00000003] app_dial.c: Unable to create channel of type ‘PJSIP’ (cause 3 - No route to destination)
[2020-01-04 12:51:20] VERBOSE[26486][C-00000003] app_dial.c: Everyone is busy/congested at this time (1:0/0/1)

2

You need to go into the PJSIP settings under Asterisk SIP Settings and turn off the “Allow Transports Reload”. It’s what is doing this.

@lgaetz @mattf: This really needs to be addressed and handled for systems out there. It’s causing more problems than good.

3

For some reason my FPBX15/Ast16 system doesn’t do this, even with Allow Transport Reloads enabled. I wonder what the trigger is.

4

I would have to look at the changelogs but perhaps it is something in Asterisk 16 itself that solves this.

5

As @jcolp has mentioned before, the issue here is a potential for a race condition and not all systems are similarly affected. I’m not aware of a specific configuration that can reliably reproduce it, nor have I ever seen it on a system I control.

FreePBX 13 didn’t have the gui option to enable, but pjsip transports had reload enabled by default until only very recently. For years this setting being enabled was under the radar and not an issue until the latest versions of Asterisk 13 were published, and users started reporting issues. In Asterisk SIP Settings ver. v13.0.131.11, transport allow reload is disabled and can’t be enabled in the gui.

It also is the case that the default setting in 14 did not appear to be an issue for quite a while, again corresponding recent versions of Asterisk. Starting in SIP Settings module versions 14.0.27.19 and 15.0.6.20, this value is disabled by default. Any new install or upgrade from 13 that gets one of the these versions will have it disabled by default. As of right now, an older version is bundled with the current ISOs, but that will be resolved at some point when new ISOs are created.

edit: latest versions of 14/15 Asterisk SIP Settings will throw a dashboard error when transport reload is enabled:

image

3 Likes
6

There is nothing that is solved in Asterisk itself. PJSIP just fundamentally doesn’t support it, because it originates primarily from the world of phones where you can then just restart the phone and have it apply. To that end noone has spent any time improving it.

7

In the GUI, “Allow Transports Reload” is off.

Looks like this is not the issue.

Any other thoughts?

8

My Asterisk SIP Settings module is 15.0.6.20, which seems to indicate my Asterisk is Version 15.

With my FreePBX version as 15.0.16.38, I must be up to date.

9

So, looking at all the replys–thanks to all who replied, BTW–, how do I proceed to identify and resolve this issue?

10

So being out of options and reading all the posts, I went with @billsimon and did an asterisk-version-switch to 16 and the trunks started working!

As easy as that for me.

@jcolp, whatever the issue, FreePBX 15 and Asterisk 16 seems to have solved the problem.

Thanks to ALL!

12

Asterisk 16 is a reasonable choice anyway, as it is the current long-term-supported version.

That said, you probably just got lucky?

13

Things are working now, but for completeness the quoted part is incorrect. Your asterisk version is independent of this or any other PBX module version. You can see the Asterisk version by browsing to Reports, Asterisk Info.

14

When I ran asterisk-version-switch, it provided 13, 15, and 16 as choices. To me that indicates something lower than 13 was likely where I was at. Regardless, I do not know of any way to discover what was there previously.

I must conclude that an older version of Asterisk combined with FreePBX 15 was the root cause since the issue disappeared upon upgrading to Asterisk 16.

Having been in the IT industry for more than 4 decades, I know of plenty of times where there is nothing wrong with package A and there is nothing wrong with package B, but package A plus package B results in something not functioning. I am chalking this issue up to that.

@billsimon I may have simply gotten lucky too.

15

I do believe that asterisk-version-switch will always show 13, 15, and 16 right now.

16

The simple solution is to use chan_sip. The first thing that I do when I install a new FreePBX is to disable pjsip and change chan_sip back to port 5060.

17

:racing_car: It’s a drive-by PJSIP disparagement!

6 Likes
18

Not really. I use what works.

19

And most like someone who has only used PJSIP within FreePBX.

Well enjoy it while you can. Chan_SIP is officially deprecated. It doesn’t get support unless someone in the community steps up and does it. It also is on the execution list, as in, within the next 4 years it becomes eligible to be removed completely. Also, as of v17 Chan_SIP is noload so you have to tell Asterisk to load and use Chan_SIP otherwise PJSIP is the only active SIP driver.

1 Like
20

Hey, when PJSIP works reliably, I’ll use it.

Chan_SIP doesn’t really need further development. It works.

21

Can you please explain how it’s not reliable?
Yes, I agree that PJSIP isn’t as easy to configure as ChanSIP, but once you figure it out, it’s very reliable.

It’s deprecated. I believe the Asterisk developers won’t release security fixes as well.