I need to program some 390 ADSI phones to use with a Panasonic KSU. The asterisk.adsi file layout for Asterisk looks pretty understandable.
Is there a simple way to setup Asterisk just to program ADSI phones via a modem?
Many thanks for any help 
J Haggerty - did you ever find the answer to this problem?
Cheers!
Iâm not sure I fully understand the question, but I think thatâs what the ADSIProg application is for.
Notwithstanding issues with that, any other standards-compliant program could also do the same thing. I think this is all documented in GR-1273. ADSI is very similar to Type II Caller ID - it is 1200 baud FSK so you could use any 1200 baud modem to program it. You would need to add other elements of the ADSI protocol such as the acknowledgments and so forth on top of it.
Depending on what you are trying to do, I may be able to try to help further.
Hello Interlinked!
I think that what the original poster was asking was: is there a way to use a standard modem in an Asterisk box INSTEAD of a DAHDI card to communicate with the ASDI phone.
My question is, is there a third-party or common language solution to programming ASDI phones without using Asterisk? From googling it, all that Iâve found are references to Blueworx Voice Response for IBM AIX, but not much elseâŚ
The general answer is âyesâ but with some caveats. ADSI itself is a standardized, documented protocol so anything that can implement GR-1273 would theoretically work.
A hardware modem is probably not going to work great because the FSK spills are not very long and it is a 2-way conversation with the phone. The phone responds using DTMF, not FSK. Most modems arenât capable of dealing with that (I donât think), and I donât think you can tell them to write a raw stream and then exit immediately.
There is a good amount of âlogicâ to dealing with ADSI phones. If youâre familiar with the protocol for Call Waiting Caller ID, ADSI is similar but the ânext level upâ of complexity from that.
In theory, I donât think you need DAHDI, and historically I think that has been true as well. Some things Iâve had difficulty generalizing from DAHDI to other channel drivers thus far that would definitely be a better approach if it works.
Asterisk is capable of generating and sending FSK spills so if the problems with that can be sorted out, I think that would be ideal.
If not, itâs possible to use an external program to do the work. This is what Iâve done for Call Waiting Caller ID. See: GitHub - InterLinked1/orange-box: Flexible Orange Box (Type II Caller ID Generator)
Thatâs a bit simpler, since itâs a simple âServer Helloâ, âClient Helloâ, FSK spill, so you can very simply write out the raw bits that you need and have minimodem play that.
No reason a similar technique could not be used, with some dialplan logic wrapped around it, to interface with ADSI phones. Thatâs something thatâs sort of been on my back burner for a little while. Iâve been more focused on seeing if I can fix the broken ADSI in Asterisk and get that to work for me before trying a different approach, but all options are on the table.
1 Like
Would be nice to see the ADSI fixedâŚ
Were you able to narrow it down further to a specific minor build between 11/12/13 where it broke, as we discussed on the other thread?
I donât currently have access to my test equipment and I am probably the only developer interested in fixing this, so that would really go a long way in terms of pinpointing the issue so we can get the problems fixed. Iâm happy to dig in further at that point.
It seems that you & I are the only ones talking about this! I canât help but think that we cannot be the only ones out there with this type of equipment interest. I have one remote customer still using Vista 390s throughout their plant, mainly because they like them and they are robust enough for their environmentâŚand I only really do this as a sideline, so there must at least several others.
The newest functioning version I could bring online, with ADSI communicating properly is:
Asterisk 11.25.3 built by mockbuild @ jenkins2.schmoozecom.net on a x86_64 running Linux on 2017-09-19 17:44:52 UTC
The oldest version that I was able to bring online but the ADSI did not work on, was 13.2.0.
I was unsuccessful in getting any version between 11.25.3 and 13.2.0 to install and/or operate properly. In all of the newer versions tested, right up to 18.12.1, I was able to enable ADSI and have it query the equipment, but in every single case, GetCPEID(), ADSIProg() and voicemail reported unrecognized response from the CPE.
Since the production machine has my only TDM Wildcard in it, weâll have to wait until I can lay my hands on another before I can do any further testingâŚunless of course, you know of some way to implement ADSI over a Digium G080 gateway?
Cheers!
There are some other people I know that are interested, but not a great number - some of them are on this mailing list: phreaknet@groups.io | Home . Some of them have phones but not the right hardware, or vice versa, and theyâve also been running into the same issues that we both have, so itâs really just a complete mess on all fronts. Itâs been somewhat challenging to get this all pulled together. Nonetheless, ADSI is very much of great interest and we do plan to get it working and functional again as soon as possible so that we can continue to take advantage of it.
Your experience with the newer stuff matches mine exactly, so at least we know that doesnât work for a fact.
I did try to install some of the older versions but unfortunately I couldnât get them installed just due to how old they are. Iâm not even sure if PhreakScript would work necessarily because it was really only written with the more recent installers in mind. Nonetheless, what happens if you try to install a version of Asterisk 12 using the âManual installâ instructions here: Docs - PhreakNet ?
I would try 12.0.0 if you can and if that does not work - which right now is my first guess, since 12.0.0 had a lot of major changes, then we have narrowed it down to a single minor (well, also major) build and can probably narrow it down much more easily after that.
Any chance you could try that when you get a chance?
12.0.0 works
Wow⌠(mic drop). I was not expecting thatâŚ
In that case, weâll still need to narrow it down to within 12.
Could you try the latest release of Asterisk 12 and see if that works? I wonder if it was actually 12 going to 13 where it happened. It just doesnât make as much sense because 12 was the standard release and 13 was LTS.
Looks like the latest 12 is 12.8.2, there were only 9 major releases of Asterisk 12.
If 12.8.2 works, then a test of 13.0.0 will probably pinpoint it down. If not, then 12.4.0 will narrow it in further.
Sorry to make you get in the weeds more than youâd hoped, but we are getting close and almost there I think!
Okay, so here is the breakthrough: In version 12.1.0-rcl all the ADSI features work, but GetCPEID is corrupted, the phone screen shows garbled characters on last line:
âCPE Infoâ
Identifying CPEâŚ
Please waitâŚ
C~H;¢â
Had to fiddle with NOLOAD and PRELOAD in modules .conf to get these all to work with FreePBX gui 12.0.76.6, but: GetCPEID, ADSIProg and voicemail script downloads all working in versions 12.2.0-rc1, 12.3.0-rc1 and 12.8.2.
NONE of the ADSI features function in 13.0.0: they all result in âunexpected response to ackâ when talking to the CPE:
â Starting simple switch on âDAHDI/3-1â
â Executing [4268@from-internal:1] TryExec(âDAHDI/3-1â, âGetCPEID()â) in new stack
[2022-06-26 19:54:51] DEBUG[3087][C-00000009]: res_adsi.c:399 adsi_transmit_message_full: Switch to data is sent!
[2022-06-26 19:54:51] DEBUG[3087][C-00000009]: res_adsi.c:296 __adsi_transmit_messages: ADSI Compatible CPE Detected
[2022-06-26 19:54:51] DEBUG[3087][C-00000009]: res_adsi.c:311 __adsi_transmit_messages: Message 1, of 4 input bytes, 1734 output bytes
[2022-06-26 19:54:51] DEBUG[3087][C-00000009]: res_adsi.c:326 __adsi_transmit_messages: Sent total spill of 1734 bytes
[2022-06-26 19:54:52] WARNING[3087][C-00000009]: res_adsi.c:343 __adsi_transmit_messages: Unexpected response to ack: (retry 1)
[2022-06-26 19:54:52] DEBUG[3087][C-00000009]: res_adsi.c:296 __adsi_transmit_messages: ADSI Compatible CPE Detected
[2022-06-26 19:54:52] DEBUG[3087][C-00000009]: res_adsi.c:311 __adsi_transmit_messages: Message 1, of 4 input bytes, 1734 output bytes
[2022-06-26 19:54:53] DEBUG[3087][C-00000009]: res_adsi.c:326 __adsi_transmit_messages: Sent total spill of 1734 bytes
[2022-06-26 19:54:54] WARNING[3087][C-00000009]: res_adsi.c:343 __adsi_transmit_messages: Unexpected response to ack: (retry 2)
[2022-06-26 19:54:54] DEBUG[3087][C-00000009]: res_adsi.c:296 __adsi_transmit_messages: ADSI Compatible CPE Detected
[2022-06-26 19:54:54] DEBUG[3087][C-00000009]: res_adsi.c:311 __adsi_transmit_messages: Message 1, of 4 input bytes, 1734 output bytes
[2022-06-26 19:54:54] DEBUG[3087][C-00000009]: res_adsi.c:326 __adsi_transmit_messages: Sent total spill of 1734 bytes
[2022-06-26 19:54:55] WARNING[3087][C-00000009]: res_adsi.c:343 __adsi_transmit_messages: Unexpected response to ack: (retry 3)
[2022-06-26 19:54:55] WARNING[3087][C-00000009]: res_adsi.c:347 __adsi_transmit_messages: Maximum ADSI Retries (3) exceed
ed
â Executing [4268@from-internal:2] NoOp(âDAHDI/3-1â, âFAILEDâ) in new stack
â Executing [4268@from-internal:3] Playback(âDAHDI/3-1â, âthanks-for-using&goodbyeâ) in new stack
â <DAHDI/3-1> Playing âthanks-for-using.ulawâ (language âenâ)
â <DAHDI/3-1> Playing âgoodbye.ulawâ (language âenâ)
â Executing [4268@from-internal:4] Hangup(âDAHDI/3-1â, ââ) in new stack
== Spawn extension (from-internal, 4268, 4) exited non-zero on âDAHDI/3-1â
â Executing [h@from-internal:1] Hangup(âDAHDI/3-1â, ââ) in new stack
== Spawn extension (from-internal, h, 1) exited non-zero on âDAHDI/3-1â
â Hanging up on âDAHDI/3-1â
â Hungup âDAHDI/3-1â
Also tried 13.0.0-beta2, but it does not work either.
Awesome, this is great! Thank you for doing this testing.
So if I have this straight:
12.0.0 and earlier: everything works correctly
12.1.0-rc1: GetCPEID is corrupted (but things still partially work)
12.2.0-rc1 through 12.8.2: everything works perfectly (so no corruption with GetCPEID)
13.0.0 and newer: everything is broken, death and despair
Is this an accurate assessment?
In that case, I want to figure out what happened in 12.1.0-rc1 to make things funny like that, and what happened between 12.8.2 and 13.0.0. Those are the turning points.
Very interesting about that 12.1.0-rc1 observation⌠like something broke and then they fixed it? And then in 13, it all just stopped working.
I think thatâs enough for me to dive into this now. Iâll see if I come up with any insights.
Almost! All works properly <12.0.0. 12.1.0-rc1 thru 12.8.2 have the GetCPEID glitch.
Just finished with 13.0.0-beta1 - this version and all higher versions give âunexpected response to ackâ when using ADSI. Just restored back to 12.8.2, and voila! ADSI works againâŚ
So our âdefectâ lies somewhere between 12.8.2 and 13.0.0-beta1.
You mean <= 12.0.0, right? (Just want to make sure Iâm understanding exactly right)
In that case, the major problem happened right after 12.8.2, and a small glitch issue happened right after 12.0.0, it seems. Iâll look into both.
You got it exactly!
I was able to get Asterisk 12.0.0 installed on Debian 8.11, though I canât quite follow along because I donât have any ADSI hardware near me at the moment.
First, some background as to timeline:
12.0.0-alpha1 was released 30 Aug 2013.
12.0.0 was released 20 Dec 2013.
12.1.0-rc1 was released 6 Feb 2014.
12.8.2 was released 8 Apr 2015.
13.0.0-beta1 was released 11 Aug 2014.
(Yes, 12.8.2 is newer than 13.0.0). This is due to the way Asterisk major releases work. The fact that 12.8.2 works (mostly) but 13 doesnât, even though 12.8.2 is newer, tells me that the change that âbrokeâ it in 13 was never cherry picked into the 12 branch, i.e. the commit was âmaster onlyâ, probably a major change and not a backwards-compatible one. As such, it was likely a major change that occurred anytime from when the 12 branch was active until 13 came out, that is between Summer 2013, when 12 was forked from master, and Summer 2014, when 13 was forked from master and released.
If you look at the commit history for res_adsi, there is one such commit that potentially fits the mold: media formats: re-architect handling of media for performance improve⌠¡ asterisk/asterisk@a2c912e ¡ GitHub
This involved major changes to formats in the core, and though I donât really understand why, testing before/after that commit seems like our first step. (Note, Iâm not saying the problem is in res_adsi or any ADSI specific code, necessarily. However, that would be the first place to look).
One thing I may not have mentioned is that if you replace the code in res_adsi that calls ast_gen_cas and simply use the playtones API, the phone will respond the first time (it still doesnât really work, but it does show that somehow ast_gen_cas is implicated). So my primary suspects are either any of the ADSI code (res_adsi or adsi.c in particular) OR something related to tone generation, formats, etc.
Iâm actually more puzzled about the minor breakage between 12.0.0 and 12.1.0-rc1. I went through all the commits to master and 12 between them and didnât notice anything that looked relevant.
Any chance you have an extra ADSI phone that you wouldnât mind allowing me to have you test? I have a few ideas, but Iâm probably going to have to install from master at several points from 2014 to really narrow it down.
If you donât mind, Iâm thinking I can register my test Asterisk system to yours via IAX2. Then, you can simply call over the trunk into my system, which will call GetCPEID(), and you can see what happens on your end - yay or nay as far as if itâs working properly or not. Then I can keep recompiling and making changes until I get it figured out. What do you think? This would provide the fastest resolution. (Iâm assuming it would be easier for you than you recompiling Asterisk potentially a large number of times, though I can provide a script to do so automatically that should work, if that would be easier)
Yes!
I have three Vista 390s left to test. My lab assistant (read: restless feline) decided that the Vista 350 needed to be on the floor instead of on the shelf where she wanted to sit, so sadly it no longer works.
After all the testing, i am convinced that it is not the actual ADSI code, but that the problem lies in the core âimprovements.â I think that the way the format/tone generation is provided is the actual culprit.
I need to reimage my system, as it is hopelessly corrupted from the testingâŚas soon as I can, letâs get that IAX2 trunk going and see what we can do. We can trade details through cndr99 at gmail dot com if you like.
Thatâs a shame⌠those phones arenât super easy to find either these days.
Iâm inclined to agree with you there - I donât think it was ADSI changes specifically, because to be honest, there really havenât been any in a long time. Core changes are very likely given the whole 12 â 13 situation I described above. The media format change is the main culprit at this point.
Iâll drop you an email tomorrow and if you want to let me know when you can set up a trunk I can register to, we should be able to get some testing underway.
Thanks!