Distorted early media in call recording when mod_dptools:wait_for_answer is used.

[evgeniibuchnev]

Describe the bug

When native mod_dptools:wait_for_answer application is used - the call recording appears distorted in early media part of the overall call. When call is answered - clean and quality recording presented.

With a workaround in Lua both parts of the call(early media and answered media) recording appear OK.

This issue is easily reproducible with below. When real calls are made the issue persists.

To Reproduce

Dialplan snippet:

<include>
    <context name="testing">

        <extension name="leg_1">
            <condition field="destination_number" expression="^(leg_1)$">
                <action application="pre_answer" />
                <action application="playback" data="tone_stream://%(800,200,300);loops=2" />
                <action application="answer" />
                <action application="playback" data="tone_stream://%(800,200,300);loops=2" />
                <action application="hangup" data="busy" />
            </condition>
        </extension>

        <extension name="leg_21">
            <condition field="destination_number" expression="^(leg_21)$">
                <action application="answer" />
                <action application="record_session" data="/usr/local/freeswitch/recordings/distorted.wav" />
                <action application="wait_for_answer" />
                <action application="sleep" data="10000" />
                <action application="hangup" data="busy" />
            </condition>
        </extension>

        <extension name="leg_22">
            <condition field="destination_number" expression="^(leg_22)$">
                <action application="answer" />
                <action application="record_session" data="/usr/local/freeswitch/recordings/clean.wav" />
                <action application="lua" data="wait_for_answer.lua" />
                <action application="sleep" data="10000" />
                <action application="hangup" data="busy" />
            </condition>
        </extension>

    </context>
</include>

Workaround solution via wait_for_answer.lua:

function wait_for_answer(ses, sleep_interval_ms)
    local sleep_interval_ms = sleep_interval_ms or 20
    while not ses:answered() do
        ses:sleep(sleep_interval_ms)
    end
    ses:consoleLog("INFO", 'Session is in ANSWERED state.')
end

if session:ready() then
    wait_for_answer(session)
end

You can trigger these by:

bgapi originate {}loopback/leg_1/testing leg_21 XML testing
bgapi originate {}loopback/leg_1/testing leg_22 XML testing

Have a look into recordings:

Expected behavior

A clean recording (without distortion) is expected.

Package version or git hash

• FREESWITCH Version 1.10.12-dev git 31cf32d 2024-04-26 13:37:10Z 64bit
• FREESWITCH Version 1.10.11 -release-25-f24064f7c9 64bit

[evgeniibuchnev]

#413 looks related, although this ticket has clean and easy instruction for reproduction. Workaround included.