Summary:	ASTERISK-29793: adsi: CAS is malformed
Reporter:	N A (InterLinked)	Labels:	regression
Date Opened:	2021-12-06 13:30:25.000-0600	Date Closed:	2022-12-08 11:19:11.000-0600
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Resources/res_adsi
Versions:	18.8.0	Frequency of Occurrence	Constant
Related Issues:
Environment:	PJSIP + Confbridge DAHDI	Attachments:	( 0) audacity.png ( 1) dialplan.png ( 2) log.txt ( 3) native.png
Description:	The CAS that res_adsi is generating seems to be malformed or non-compliant in some way. When I manually use PlayTones to produce a CAS in the dialplan, my CPE correctly responds to it with the DTMF "A" ACK. However, when using the native CAS in __adsi_transmit_messages, it does not work and my CPE does not recognize the CAS. As a result, GetCPEID() exits. I can trick GetCPEID() by generating my own CAS before calling GetCPEID(), which makes the first CAS and response work, but subsequent CAS's generated by the application internally cannot be "propped up" in this manner. As such, GetCPEID() will always fail and exit. I have analyzed a few properties of the waveform and have concluded that the issue does not seem related to duration. A CAS of 80ms and 110ms both seem to work fine. The CAS generated by Asterisk seems to be about 100ms. The audio captured using MixMonitor doesn't seem to reflect volume adjustments, but the CAS generated by Asterisk is noticeably quieter than ones generated manually. FWIW, I cannot get the CAS to be recognized at all unless the endpoint is joined to it in a ConfBridge. I have dtmf_passthrough = yes, silence drop set to no, to maximize audio quality. When analyzing the recordings using the Plot Spectrum feature in Audacity, the CAS generated by Asterisk internally seems a lot noisier than the purer CAS generated by PlayTones in the dialplan. Perhaps this is causing the CPE to not recognize it. Upon a lot of further analysis, and some direct recordings off the line to analyze further, I'm actually rather stumped as some of the waveforms are definitely almost identical, yet PlayTones will work when adsi_careful_send does not. Reduce the TX volume beneath -11 causes PlayTones to also fail, but increasing the volume to any amount does not cause adsi_careful_send to start working. Replacing: {noformat} if (adsi_careful_send(chan, buf, 680, NULL)) { ast_log(LOG_WARNING, "Unable to send CAS\n"); } {noformat} with: {noformat} ast_playtones_start(chan, 0, "2130+2750", 0); ast_safe_sleep(chan, 80); ast_playtones_stop(chan); {noformat} *does* work. I can't, in practice, detect what the difference is, but it's consistent. The mystery deepens, however. At this point, the CAS succeeds, but the actual sending of the data is very strange. I get three ADSI retries, so it's like this: 1) CAS using ast_playtones_start succeeds 2) CPE responds with "A" DTMF 3) Asterisk sends data 4) NO RESPONSE from CPE. Retry. Send CAS 5) CPE responds with "A" DTMF 6) Asterisk sends data 7) NO RESPONSE from CPE. Send CAS... and so forth to retries = 3. Now, here's the funny thing about the data that is getting sent - it's all 1s! I monitored the line with my butt set and when I analyzed the tone in Audacity, it is nothing more or less than 200 ms of 1200 Hz - which is mark ('1") in Bell 202 FSK. I am aware that the GR-30 protocol is to send 55 to 70 bits or so of mark to begin data, and this is what happens with the Call Waiting Caller ID (Type II) FSK spill, but this is definitely way too much mark. The parameter code for getting CPE ID in AD is 10010110 in binary, so even if it was supposed to be all mark for some odd reason, that doesn't really explain that. I looked at the whole waveform. It's all 1200 Hz. More investigating to be done, but there we have that.
Comments:	By: Asterisk Team (asteriskteam) 2021-12-06 13:30:26.117-0600 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. Please note that log messages and other files should not be sent to the Sangoma Asterisk Team unless explicitly asked for. All files should be placed on this issue in a sanitized fashion as needed. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur. Please note that by submitting data, code, or documentation to Sangoma through JIRA, you accept the Terms of Use present at [https://www.asterisk.org/terms-of-use/|https://www.asterisk.org/terms-of-use/]. By: N A (InterLinked) 2021-12-06 13:33:59.056-0600 4 attachments: Audacity plot: Not shown is the first DTMF ACK from the CPE, for some reason. It's there, and it's in the CLI trace as DTMF debug, but for some reason it doesn't show up in the recording. Probably because it's RFC4833 and not in-band, but not sure why the second one DOES show up in that case... Plot spectrums of native Asterisk (which fails) and PlayTones (which succeeds) log.txt: dialplan output. Basically: 1. manually use PlayTones. 2. Successfully ACK from the CPE. 3. manually use PlayTones IMMEDIATELY followed by invoking GetCPEID() 4. Successful ACK from CPE. 5. GetCPEID() proceeds to the next data message and sends another CAS to the CPE. 6. No response from the CPE, because the CAS isn't quite right. As such, there is no response from the CPE. 7. GetCPEID() exits. This is reproducible in any order. PlayTones by itself will work, and PlayTones followed by GetCPEID will make the first CAS work. GetCPEID on its own does not work. By: Friendly Automation (friendly-automation) 2022-12-08 11:19:12.353-0600 Change 19576 merged by Friendly Automation: res_adsi: Fix major regression caused by media format rearchitecture. [https://gerrit.asterisk.org/c/asterisk/+/19576|https://gerrit.asterisk.org/c/asterisk/+/19576] By: Friendly Automation (friendly-automation) 2022-12-08 12:36:56.011-0600 Change 19668 merged by George Joseph: res_adsi: Fix major regression caused by media format rearchitecture. [https://gerrit.asterisk.org/c/asterisk/+/19668|https://gerrit.asterisk.org/c/asterisk/+/19668] By: Friendly Automation (friendly-automation) 2022-12-08 12:37:19.005-0600 Change 19669 merged by George Joseph: res_adsi: Fix major regression caused by media format rearchitecture. [https://gerrit.asterisk.org/c/asterisk/+/19669|https://gerrit.asterisk.org/c/asterisk/+/19669]