I just noticed that app_adsiprog and res_adsi are deprecated as of 16 and scheduled for removal as of 19.
I thought at first that these were older parts of ADSI support that maybe had been superseded, but it seems like res_adsi is responsible at least for getting CPE info and app_adsi is the actual ADSIProg application.
Are these being moved to something else? I guess I don’t follow where this functionality is being moved - maybe I missed something?
It’s all being removed. It sees little if any use by the vast majority of the user base. In fact, we removed ADSI functionality already from parking and noone had any issue. Removing it allows us to clean up code and remove the various tendrils across the tree for where ADSI hooks in.
Is there any way to “appeal” this or prevent this from happening, or is it already too late for that?
ADSI is an important capability for analog phones. I’ve just been getting into it more recently but that would be all for moot if it’s going away. A bit slow at it, because it’s DAHDI-only and there’s so little documentation on it. The Parking ADSI might have been useful to me.
I can see why SIP might be getting removed, since PJSIP is, in theory, a drop-in substitute for it, but there isn’t a replacement for ADSI, so I fail to see how removing features from Asterisk makes it better. Can it just be “unsupported” but left there so at least people using it can continue to do so, offering patches or improvements themselves if necessary? Maybe the code can just be “frozen” like SIP currently is, “with no official maintainer”?
Sure, I could save the C files and just keep building with that manually, but if code from other files referencing ADSI starts getting removed, then it’s not going to become clean to keep building with ADSI support after it gets removed, would that be right?
At the end of the day, part of what makes it great is rich functionality that can make it on par with a PSTN switch for features. Doing ADSI outside of Asterisk would never be as clean.
You could attempt to by posting to the asterisk-dev mailing list, but the code is not being maintained by Sangoma and does not wish to be maintained by the community and the developer community would like to see it removed. You may literally be the only individual interested in it or using it.
If it were removed, you would need to maintain a patch set to add it back in.
I should also add that in a frozen state it’s something we still have to maintain. If further GCC versions find issues with it, we then have to figure out the issue and resolve them. It’s not zero ultimately.
You could attempt to by posting to the asterisk-dev mailing list, but the code is not being maintained by Sangoma and does not wish to be maintained by the community and the developer community would like to see it removed.
Well, speaking as a developer, I would not like to see it removed.
You may literally be the only individual interested in it or using it.
I don’t doubt that it’s probably one of the lesser used features, but I’m sure there are at least a few. Probably more people than using AlarmReceiver() at least, I’d bet. There are a lot of people out there using Asterisk who don’t participate in the Asterisk community forums and lists. I’ve been using it for years in the telecom sphere but only recently became more involved with the Asterisk community.
If it were removed, you would need to maintain a patch set to add it back in.
Right - if it was just app_adsiprog being removed and nothing else, it might not be a big deal, but if there are many references in other files, with a changing codebase over time, it seems that this might grow to be more and more complex over time.
I already have a few custom patches that I apply, since I haven’t gotten around to adding options to the application yet (such as ConfBridge), but this is more involved.
I should also add that in a frozen state it’s something we still have to maintain. If further GCC versions find issues with it, we then have to figure out the issue and resolve them. It’s not zero ultimately.
I’m totally fine with Sangoma not maintaining it, I don’t think anyone expects them to, it would just be really nice if it were kept “as is, with no support”, rather than removed. Doesn’t need to be enhanced and maybe bugs can be ignored, but what’s already there is better than nothing. I didn’t know about the Parking and so in the future I’ll see if I can patch that back, at least myself. I just haven’t added parking to my system yet.
I could try to support the module myself, on a best effort basis, at least for myself and anyone else using it if that is helpful.
I’d suggest starting a dialog on asterisk-dev as I stated. Developers do not participate in this forum generally, so will not see this discussion or points.
I don’t have usage information specifically on ADSI. I know sales information for analog cards, FreePBX usage information, reported issues, and what I’ve gathered from talking to people. You are the first person to mention ADSI in 10+ years except for one individual semi-recently who experienced an issue with ADSI where it was misbehaving on a SIP channel for some reason.
For parking it would be complete fresh code to add support, as parking was completely rewritten.
Someone has to maintain even at a base level, it can’t be as-is. If a new version of GCC causes it to stop building then someone has to fix that. This applies to all code in Asterisk - we have to ensure, as best we can, that it at least builds. If that’s you then fine.
I’d suggest starting a dialog on asterisk-dev as I stated. Developers do not participate in this forum generally, so will not see this discussion or points.
Okay, will do.
I don’t have usage information specifically on ADSI. I know sales information for analog cards, FreePBX usage information, reported issues, and what I’ve gathered from talking to people. You are the first person to mention ADSI in 10+ years except for one individual semi-recently who experienced an issue with ADSI where it was misbehaving on a SIP channel for some reason.
Does Asterisk support ADSI natively on SIP after all? I thought, like TTY and many other modules, it’s DAHDI only? ISTR seeing this in the documentation.
As far as ADSI goes, the equipment seems to be rarer than 10-button Touch-Tone phones these days, I was (and still am) hunting for an external ADSI module but I’m not sure such a thing exists. Considering writing some ADSI software, similar to TTY programs that allow for using TTY with a SIP client on a PC, if only for testing.
For parking it would be complete fresh code to add support, as parking was completely rewritten.
Ah, okay. Well in that case, I don’t feel so bad about that part being removed necessarily. I might consider it in the future.
Someone has to maintain even at a base level, it can’t be as-is. If a new version of GCC causes it to stop building then someone has to fix that. This applies to all code in Asterisk - we have to ensure, as best we can, that it at least builds. If that’s you then fine.
If that’s what it takes to keep support, I guess I don’t have much of a choice 
Wouldn’t mind doing that, though I’m a bit new to that area so I’ll need to work my way up to that. Happy to at least try to ensure that it keeps building.
It doesn’t but the code still seemingly can execute on SIP channels and cause problems. I don’t recall the specifics.
I also forgot to mention that the next set of releases will log, after startup, deprecated modules that are loaded to give people more of a heads up. Maybe people will care about ADSI then, maybe not.
It doesn’t but the code still seemingly can execute on SIP channels and cause problems. I don’t recall the specifics.
I see.
Generally speaking, what’s the rationale in Asterisk to restricting certain things to DAHDI only? Not just ADSI, but also TTY, etc. A lot of features are like this for no apparent reason. Is it 1) just a matter of practicality with the channel drivers themselves? Or 2) “if you’re not using a channel bank, I don’t see why you want this feature ever” type of thing? Or 3) “if you’re not using channel banks, there might be packet loss / compression and screw this up, so we don’t want you to even try” type of thing? Been curious about this for a while.
For TTY generation, I just have a subroutine play the audio files of each tones, since this is the only channel-agnostic way to do it. It works just fine with SIP - using G711 uLaw. This is just TX though. RX would be nice, but again, TTY is DAHDI only. A TTY-TTY call through Asterisk - in band, of course, with SIP - works just fine, which suggests that TTY-Asterisk would (or could) work just fine, too.
TTY is 45.45 baud and ADSI is 1200 baud. Orange boxing on SIP works just fine, which means CWCID (1200 baud FSK) works just fine in band with SIP (really any non-compressed connection) just fine. (To put this in perspective, I can get 40kbps with dial-up over SIP to a remote server - over the Internet - not bad.) So, at such low speeds, the DAHDI-only mentality seems artificial to me. Is there more to the story than this? (I recognize a lot of things, for technical reasons, are DAHDI only, because they require a physical connection or such precise timing - not referring to those things here.)
I also forgot to mention that the next set of releases will log, after startup, deprecated modules that are loaded to give people more of a heads up. Maybe people will care about ADSI then, maybe not.
That would be super helpful. I didn’t even know chan_sip was deprecated until I saw that when upgrading from 13 to 18. (Virtually everyone I know is still using SIP, with only a handful on PJSIP so far.) I didn’t come across this page until recently: Home - Asterisk Documentation
The things you’re interested in predate me (so that’s 15+ years) and are legacy old code. They weren’t architected/written/expected to be used elsewhere at that time and subsequently noone has been interested in using them elsewhere since and thus nothing has changed.
They are the way they are because that was likely the fastest way to get it done for what was needed at the time.
Gotcha - so fundamentally, there isn’t no reason to not have that support, and there would be no problem/objection to patches that added multi-channel or channel-agnostic support for these?
I have no knowledge of that underlying technology/stuff so I can’t comment on that fundamentally, and the devil is in the details of every patch.
From a SIP perspective there is a T.140 TTY specification for real time text which is not supported in PJSIP. It’s not strictly an audio stream, but that’s seemingly the way that world has gone.
From a SIP perspective there is a T.140 TTY specification for real time text which is not supported in PJSIP. It’s not strictly an audio stream, but that’s seemingly the way that world has gone.
Yeah, I’ve heard of that, but I mean actual 45.45 baud TTY, such as those used by a physical TDD manufacturer by, such as an Ultratec (I have a couple of those), or software like ipTTY, and possibly teletypes. It works just fine in band even over the Internet, so T.140 has always seemed like a solution w/o a problem to me, though I know there are other uses like with WebRTC.
T.38 is another weird thing. Faxing in Asterisk has never worked for me with T.38 with VoIP, but when I force it to be entirely in band, TX/RX works just fine at 14.4k. A lot of these protocols seem better suited for compressed connections and don’t seem to work well with G.711.
T.38 doesn’t care about underlying codec. It does work, but some external implementations can be poor.
Just to make sure I’m not missing another train that has left the station, I can see that app_fax is also listed as deprecated on the same timeline.
However, I know that there’s also res_fax and the two seem to be different.
In this case, is this just removal of older fax functionality, but not the newer ReceiveFax() and SendFax() that rely on res_fax as opposed to app_fax?
That is correct. It is the app_fax module being removed and not the other stuff. In the app_fax case it hasn’t been default built in ages, is marked as deprecated, and can’t even be built if res_fax is enabled.
Another thing: there isn’t any mention of deprecations in the Asterisk wiki in each function/application page. I thought that gets generated from the source code and I’m looking at the latest versions (for 18), but I don’t see any notices there. Is something broken with this?
There’s nothing broken in that nothing exists to do that as of this point in time. Modules are deprecated, but that is not tied to applications/dialplan functions/etc. It could be in the future, but isn’t at the moment.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.