Currently, we use dtmf to check if audio path was correctly opened after call answer/reinvite.
However, occasionally we get wrong dtmf detection like absent digits or duplicated digits.
I suspect this happens because we are using in on low powered or overloaded VMs and somehow this negatively impact dtmf detect.
So let's implement bfsk support which should be less demanding and see if this improves audio data detection.
(obs: currently we have support for bfsk using ws_speech_server but we don't want to depend on it for this kind of test).
Currently, we use dtmf to check if audio path was correctly opened after call answer/reinvite. However, occasionally we get wrong dtmf detection like absent digits or duplicated digits. I suspect this happens because we are using in on low powered or overloaded VMs and somehow this negatively impact dtmf detect. So let's implement bfsk support which should be less demanding and see if this improves audio data detection. (obs: currently we have support for bfsk using ws_speech_server but we don't want to depend on it for this kind of test).