I’m just curious, what is FreePBX’s roadmap for the removal of Chan_SIP in Asterisk v21 and how long FreePBX will continue to allow Chan_SIP to be used.
In my opinion, there needs to be a firm deadline set for when FreePBX will no longer support Chan_SIP going forward. This would include removal of anything Chan_SIP related within FreePBX at a certain point. Leaving Chan_SIP in FreePBX going forward will let people still use it and that will make moving to anything higher than v20 for Asterisk problematic in the GUI. You will either need to hide all the Chan_SIP options or leave them and then that will be a can of worms in itself.
If FreePBX v17 is still a year out from being released, I’d say remove Chan_SIP from FreePBX v17.
chan_sip is already disabled by default in FreePBX 16.
I’m as big of a pjsip proponent as anyone but my vote would be to leave it in there as long as FreePBX still works with a version of Asterisk that has chan_sip.
If someone wants to cause himself pain by enabling a disabled and deprecated module that’s on him. I’m not sure why it should matter to any of us who have moved on to pjsip already.
How so? If you enable it and the driver isn’t there it just won’t work. So the admin has to choose the correct driver (pjsip), which would already be chosen by default. Maybe don’t let them choose chan_sip unless chan_sip.so actually exists?
Which means it can be enabled and be used. Not what I was referring to. On top of that, we’ve still have people in 2022 running out dated versions of FreePBX and telling them to install v16 and restore to v16. You know what happens then? Chan_SIP is no longer disabled because it’s being used.
We know that people are still running chan_sip and will continue to do so until they can’t. So we have someone on FreePBX with Asterisk v20 and they do an update and they end up on v21. Now chan_sip is gone but now none of their stuff is configured right.
So again, I’m curious what the plan is because the Restore part of Backup/Restore will, at some point, not restore chan_sip to chan_sip but convert chan_sip to chan_pjsip.
I’m not sure what you are trying to say here. FreePBX doesn’t have native support for every channel driver Asterisk offers, I’m talking about chan_sip which it does.
Also these channel drivers no longer exist in Asterisk as of v19: chan_oss, chan_phone, chan_nbs, chan_misdn and chan_vpb. Can’t install and use them.
These are the ones leaving in v21: chan_sip, chan_skinny, chan_alsa and chan_mgcp.
Historically people have been able to install chan_skinny and use it with FreePBX but as of v21 you won’t be able to anymore. When you update to v21 you will lose it.
If you wish to continue to use chan_sip you will never be able to update past v20. Well, I guess some diehard could maintain a 3rd party patch and take ownership of chan_sip outside of Asterisk.
There is at least one person on the Asterisk forum that makes a strong case that chan_sip handles some provider weirdnesses (off label use of standard headers, etc.) that only chan_sip copes with. There are also providers that insist on using TEL: URIs, which are not supported in either driver, but are explicitly blocked in chan_pjsip.
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.
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.
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.
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.