FreePBX Roadmap for Chan_SIP Removal

You mean compact headers? That support can be added to chan_pjsip. I would have to double check to see if someone is working on it.

Well chan_sip supports TEL URI. By Asterisk v20 so will chan_pjsip. In fact, the updates are up for review to be commited right now.

No I meant they read more into the values of some standard headers than the standards actually define.

The last time I saw Joshua say anything on this it was still a to do item, but may be that has changed. My understanding from Joshua is that TEL: has a similar status to directmediasetup, in chan_sip; the code doesn’t reject them, but you use them at your own risk, as they are not properly tested.

Where is the argument being made on the Asterisk forum? I want to see more details.

I wasn’t making it up when I said it is up being reviewed right now. res_pjsip: Add TEL URI support for basic calls. (If5729e6c) · Gerrit Code Review (asterisk.org)

I can’t work out the correct search terms to find it, but I’ve had several occasions where I noted that a chan_sip user should move to chan_pjsip challenged on that basis.

Well you need to be a bit more specific because there are at least 3 things you could be referring to in regards to headers. And honestly, if it is what I am thinking about it was something added in the last 7 years that most have no clue it exists.

We are talking about what Asterisk supports. It appears to support compact headers.

If we got into a list of what chan_pjsip or other Asterisk things FreePBX doesnt have native support, it would be a longer list.

Sorry I didn’t explain myself. My intention of posting was to show that it is possible and there’s even a discussion to get the setting exposed in FreePBX.

I get that and that did answer a question that was posed. What header handling was being referred to, compact headers wouldn’t be it because that support exists. What I believe is being referred to is this:
[![touser[@todomain]][![fromuser][@fromdomain]]] in chan_sip which allows you to override the TO and FROM headers Asterisk will generate on the outbound channel. This was introduced during v14 and had some work in the start of v15. That means this features is roughly 5-6 years old and it is a feature that barely anyone uses. It works…meh…on later versions.

So compact headers work, TEL URI support is coming, being able to manipulate the TO header is a very, very low requirement for about 99.99% of the users. Changing the from domain on the fly, also not something else really needed by most users. And this comment makes no real sense.

they read more into the values of some standard headers than the standards actually define.

What values are being added to standard headers that standards don’t define? I can get pretty much anything from the TO/FROM headers and with a little parsing get all the parts of said headers.

The only thing I can think of, is showing the User Agent when running pjsip show contacts <contact> similar to sip show peer <peer>
But that is not a configuration issue that would prevent someone from migrating.

That is not related to header discussions, that information is gathered and stored by Asterisk in the AstDB. Now you’re referring to how a CLI command should display output of that information.

To get back to the original topic, we have not discussed this internally, but I think an approach similar to what @billsimon shared in post 2 is probably best. We can throw a dashboard notification in the next version recommending against usage, but as long as FreePBX is supports an Asterisk version that has chan_sip, it doesn’t take any engineering work to support it in fpbx. Artificially disabling GUI features prior to that is just gatekeeping.

So then we can expect another 4-5 years or so of chan_sip being supported in FreePBX even though in FreePBX v16/Asterisk v18 it doesn’t load/compile Asterisk with chan_sip. However, if someone goes into Advanced Settings and enables “both” or “chan_sip” (only) then Asterisk will be recompiled to install chan_sip for them to use. Then the restore scenario where if they restore an old version of FreePBX to FreePBX v16/Asterisk v18 then once again, Asterisk will be recompiled to install chan_sip for them to use.

Am I getting the picture on this now?

FreePBX itself compiles nothing. The Asterisk rpms currently published for the FreePBX Distro have chan_sip enabled regardless of whether the admin chooses to use it or not.

I don’t want to speculate on timelines before the project decides on how or if we will automatically deal with legacy restores, but realistically we have years before the relevant asterisk versions are all EOL, so a similar timeline for FreePBX seems natural. Prior to that we will continue to do what we can to get the message out, starting with GUI messaging in the next major release.

1 Like

From my FreePBX v16/Asterisk v18 distro box:

[root@freepbx ~]# asterisk -rx "module show like chan_sip"
Module                         Description                              Use Count  Status      Support Level
0 modules loaded

Both app_macro and chan_sip had a similar natural timeline as app_fax of being removed in Asterisk v19. The only reason (I believe) that app_fax didn’t get extended was that no one in the Asterisk team realized FreePBX was still using it. No one on the FreePBX made them aware (or did anything about it) so it was removed. When people moved to v19 when the RPMs were released, faxing got broke.

So the natural timeline was v19 but their removal got stayed to v21 specially because of this project. Since things can only be removed in Standard releases of Asterisk they will exist in v20 which has the side effect of these two things existing for another 4 years as it is LTS. In other words, FreePBX missed deadlines and got extra time to do their homework. Let’s not wait till the night before the new due date to get to that homework.

Leave chan_sip in. Many people have older systems that don’t have support for pjsip

Thanks

1 Like

Please explain the nature of the lack of support (which is more likely to be the other way round, i.e. chan_pjsip doesn’t support something unusual that they do). As noted above there are issues with TEL, but that tends to affect newer systems, and partial support is being added. I also noted that I have seen specific claims of cases where chan_sip can work round unusual uses of SIP, but chan_pjsip can’t but I’ve been unable to find those again.

If you have specific experience of systems that require features that are missing from chan_pjsip, please let us know exactly what those are.

Those people then need to update. To not have chan_pjsip available means they are om Asterisk v11 or lower. None of that is supported.

I read the point as confusing the implementation with the protocol, and thinking PJSIP was a non-backwards compatible replacement for SIP, whereas chan_sip and chan_pjsip are actually both implementations of the, single, SIP protocol. If someone is using an old version of Asterisk, they are likely to be using an old version of FreePBX, as well, and won’t be concerned about later versions.

No. To clarify, we’re not talking about older systems here, we’re talking about current and future PBX versions. chan_sip is going away in Asterisk 21, that’s set in stone now. It’s time (past time really) for all Asterisk based PBX admins to take whatever steps are needed to eliminate chan_sip from their setup. This thread raises points about how it will be phased out in FreePBX and when.

1 Like