audio on A-leg pauses during HTTAPI fetch

[tmancill]

Describe the behavior

An inbound call is interacting with an HTTAPI application. Audio played with uuid_displace is heard by the caller until the next HTTAPI fetch begins, at which point it drops out. Once the fetch completes and the HTTAPI document is returned, the uuid_displace audio can be heard by the caller again. A recording of the session contains the uuid_displace audio without any gap in playback.

FWIW, I'm not claiming this is a bug; it may be the expected behavior. But since I spent a fair amount of time investigating and creating a repro case, I thought I would share it and try to get a better understanding/definitive answer about how mod_httapi interacts with audio on the A-leg.

To Reproduce

1. Start the repro httapi application (Python script) where FS will be able to reach it. By default, it listens on port 8088. The script refers to audio found in the FS Debian package freeswitch-sounds-en-us-callie.

2. Configure FS to invoke the application. In my configuration, the inbound call comes in via mod_signalwire. Note that the reported behavior occurs whether or not record_session is used, and recording need not be part of the solution.

<extension name="httapi-pause-repro" continue="false">
  <condition field="destination_number" expression="^(\+18005551212)$">
    <action application="answer"/>
    <action application="record_session" data="$${recordings_dir}/${strftime(%Y-%m-%d-%H-%M-%S)}_httapi-pause-repro.wav"/>
    <action application="httapi" data="{url=http://localhost:8088,method=POST}"/>
    <action application="playback" data="misc/error.wav"/>
    <action application="hangup"/>
  </condition>
</extension>

3. reloadxml and then dial the extension and listen for the gap in playback of the displaced audio stream during the "long" fetch (fetch 2). The call sequence is given below. See the "HTTAPI application logs" below for the documents rendered by the HTTAPI server:

   fetch 1

   • sleep 1000
   • play welcome
   • uuid_displace start looping playback
   • sleep 2000 (caller hears looping playback)

   fetch 2

   • (pause on server side - caller does not hear looping playback)
   • sleep 2000 (caller hears looping playback)
   • uuid_displace stop playback
   • play prompt 2

   fetch 3

   • play goodbye
   • hangup

Expected behavior

The caller hears uuid_displace audio during the mod_httapi fetch.

If you're curious, we ran across the use case while replicating the behavior of the fetchaudio attribute of VoiceXML browsers. This can be used to "cover up" long fetches without having to play the prompt to completion. Typically the looping prompt is a typing sound or something similar.

Work-arounds

1. Bridging the inbound leg via the loopback and then using uuid_displace with the uuid created by the loopback. That is, the following sequence plus a slight modification to the script (found in https://pastebin.freeswitch.org/view/67ba0d55).

   • answer call
   • bridge to loopback/httapi-app-extension
   • capture variable_other_loopback_from_uuid in httapi app
   • uuid_displace ${variable_other_loopback_from_uuid}

2. Not yet attempted, but @briankwest suggested parking the call to apply the treatment. The reason this hasn't been attempted is because to unpark the call, we either have to transfer it or bridge it. Ideally, we could resume the HTTAPI application (where the session equates to the uuid) where we left off.

Package version or git hash

• 1.10.10~release~24~4cb05e7f4a~bookworm-1~bookworm+1

Trace logs

Freeswitch logs

https://pastebin.freeswitch.org/view/3d32d45f

HTTAPI application logs

$ python3 fs_httapi_pause_repro.py
2023-12-01T19:28:15Z.882 INFO     ----------------------------------------------------------------------
2023-12-01T19:28:15Z.882 INFO     session_id=41a89432-37f0-4cba-b5e2-9c4d7a059796, turn=0
2023-12-01T19:28:15Z.884 INFO     POST response:
<document type="text/freeswitch-httapi">
  <work>
    <execute application="sleep" data="1000"/>
    <playback file="/usr/share/freeswitch/sounds/en/us/callie/ivr/8000/ivr-welcome.wav"/>
    <execute application="set" data="api_result=${uuid_displace 41a89432-37f0-4cba-b5e2-9c4d7a059796 start /usr/share/freeswitch/sounds/en/us/callie/digits/8000/1.wav 0 flmw}"/>
    <execute application="log" data="INFO uuid_displace start"/>
    <execute application="sleep" data="1000"/>
    <execute application="log" data="INFO long fetch start"/>
  </work>
</document>


2023-12-01T19:28:18Z.607 INFO     ----------------------------------------------------------------------
2023-12-01T19:28:18Z.607 INFO     session_id=41a89432-37f0-4cba-b5e2-9c4d7a059796, turn=1
2023-12-01T19:28:20Z.608 INFO     POST response:
<document type="text/freeswitch-httapi">
  <work>
    <execute application="log" data="INFO long fetch complete"/>
    <execute application="sleep" data="1000"/>
    <execute application="set" data="api_result=${uuid_displace 41a89432-37f0-4cba-b5e2-9c4d7a059796 stop /usr/share/freeswitch/sounds/en/us/callie/digits/8000/1.wav}"/>
    <playback file="/usr/share/freeswitch/sounds/en/us/callie/base256/8000/hamlet.wav"/>
  </work>
</document>


2023-12-01T19:28:22Z.145 INFO     ----------------------------------------------------------------------
2023-12-01T19:28:22Z.146 INFO     session_id=41a89432-37f0-4cba-b5e2-9c4d7a059796, turn=2
2023-12-01T19:28:22Z.146 INFO     POST response:
<document type="text/freeswitch-httapi">
  <work>
    <playback file="/usr/share/freeswitch/sounds/en/us/callie/voicemail/8000/vm-goodbye.wav"/>
    <hangup/>
  </work>
</document>

2023-12-01T19:28:22Z.628 INFO     ----------------------------------------------------------------------
2023-12-01T19:28:22Z.629 INFO     session_id=41a89432-37f0-4cba-b5e2-9c4d7a059796, turn=3
2023-12-01T19:28:22Z.629 INFO     POST response:
OK