[asterisk-bugs] [JIRA] (ASTERISK-29009) app_amd: Detection issues when silence is not transmitted

[Joshua C. Colp (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-29009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joshua C. Colp updated ASTERISK-29009:
--------------------------------------

    Status: Open  (was: Triage)

> app_amd: Detection issues when silence is not transmitted
> ---------------------------------------------------------
>
>                 Key: ASTERISK-29009
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29009
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_amd
>    Affects Versions: 13.30.0
>            Reporter: Corey Farrell
>            Severity: Minor
>
> I've run into an issue when retesting an integration which uses {{AMD()}} when using 13.35.0.  Reverting the change from ASTERISK-28608 fixes my tests.  The issue occurs when I run AMD on a call to the following dialplan:
> {code}
> exten => s,1,Answer()
> same => n,Wait(0.5)
> ; Play hello.ulaw from asterisk-core-sounds-en-ulaw-1.6.tar.gz
> same => n,Playback(hello)
> same => n,Wait(5)
> same => n,HangUp()
> {code}
> My tests run PJSIP to PJSIP between two Asterisk PBX instances, one instance runs {{AMD()}} on an outbound call, the other instance simulates a human answering with the above context. Specifically the issue is that {{Wait(number)}} does not normally transmit silence.  In Asterisk 13.28.0 {{AMD()}} would detect a call to this context as "HUMAN" but in 13.30.0 it is detected as "NOTSURE".
> Setting {{transmit_silence=yes}} in the asterisk.conf of my daemon also fixed the tests, so I assume this is related to {{AST_FRAME_NULL}} handling.
> I know this module is extended support, I will eventually be able to dig deeper and hopefully create a patch but for now I just wanted to get the report open to document my findings.



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