[asterisk-bugs] [JIRA] (ASTERISK-29793) adsi: CAS is malformed

[Friendly Automation (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-29793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=260839#comment-260839 ] 

Friendly Automation commented on ASTERISK-29793:
------------------------------------------------

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]

> adsi: CAS is malformed
> ----------------------
>
>                 Key: ASTERISK-29793
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29793
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_adsi
>    Affects Versions: 18.8.0
>         Environment: PJSIP + Confbridge
> DAHDI
>            Reporter: N A
>            Assignee: Unassigned
>            Severity: Major
>              Labels: regression
>         Attachments: audacity.png, dialplan.png, log.txt, native.png
>
>
> 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.



--
This message was sent by Atlassian JIRA
(v6.2#6252)