Strange effect with delay_echo against VAD
I got a strange effect, and help in understanding it would be appreciated. My FreeSWITCH server registers at an ITSP, and forwards incoming calls to "echo" or "delay_echo" applications, immediately after answering. The ITSP uses VAD and comfort noise when it sends audio to my server. If the call is sent to "echo" application, the calling party hears the echo, and also it hears comfort noise. If the call is sent to "delay_echo", with any delay (I tried 200 to 1000ms), the calling party hears only a loud noise. Here's a recording on the calling side (my voice in the left ear) http://www.k-open.com/s/0202eb6bfa655e47974325574ac47c7b.wav Also if the call is sent to an IVR, and delay_echo is executed as an IVR action, the caller hears the echo as expected. The call is happening in PCMA. I've got also packet captures, will share them on request, as they contain some confidential information.
the problem is solved with <param name="suppress-cng" value="true"/> in the SIP profile, so that FreeSWITCH stops offering CN in SDP. Still it will be interesting to know what caused this problem. On Sat, Mar 28, 2015 at 1:13 AM, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:
I got a strange effect, and help in understanding it would be appreciated.
My FreeSWITCH server registers at an ITSP, and forwards incoming calls to "echo" or "delay_echo" applications, immediately after answering.
The ITSP uses VAD and comfort noise when it sends audio to my server.
If the call is sent to "echo" application, the calling party hears the echo, and also it hears comfort noise.
If the call is sent to "delay_echo", with any delay (I tried 200 to 1000ms), the calling party hears only a loud noise. Here's a recording on the calling side (my voice in the left ear) http://www.k-open.com/s/0202eb6bfa655e47974325574ac47c7b.wav
Also if the call is sent to an IVR, and delay_echo is executed as an IVR action, the caller hears the echo as expected.
The call is happening in PCMA.
I've got also packet captures, will share them on request, as they contain some confidential information.
participants (1)
-
Stanislav Sinyagin