aufile module makes the audio start while the phone is still ringing

59 views
Skip to first unread message

Francesco Montorsi

unread,
Jun 11, 2025, 5:23:30 PMJun 11
to baresip
Hi all,
I'm a new user to baresip.
I managed to configure it with my VOIP provider and I can dial e.g. my cellphone, I get the call and I can answer.
However I'm trying to automate baresip and have baresip play a WAV file whenever the called party picks up the call.
In the config file /home/fmontorsi/.baresip/config I have put the following line:

audio_source aufile,/tmp/test.wav
...
module aufile.so

My problem is that I noticed that "aufile" module is sending the audio content even before the called party answers to the call... e.g. see this log:

sip:33813...@voip.eutelia.it
28595...@voip.eutelia.it: selected for request
call uri: sip:33813...@voip.eutelia.it
call: connecting to 'sip:33813...@voip.eutelia.it;transport=udp'..
call id: 6ab3e893881a7751
call: SIP Progress: 100 Trying (/)
call: SIP Progress: 100 Trying (/)
call: SIP Progress: 100 Giving a try (/)
call: SIP Progress: 183 Session Progress (application/sdp)
28595...@voip.eutelia.it: Call in-progress: sip:33813...@voip.eutelia.it;transport=udp
stream: update 'audio'
audio_recv: Set audio decoder: PCMA 8000Hz 1ch
pipewire: opening playback (8000 Hz, 1 channels, device , ptime 20)
pipewire: stream baresip-playback started (Success [0])
audio_recv: player started with sample format S16LE
audio: Set audio encoder: PCMA 8000Hz 1ch
aufile: loading input file '/tmp/test.wav'
aufile: /tmp/test.wav: 24000 Hz, 1 channels, S16LE
aufile: audio ptime=20 sampc=480
aufile: read end of file
aufile: loaded 365568 bytes
audio: source started with sample format S16LE
audio tx pipeline: aufile ---> aubuf ---> auconv ---> auresamp ---> PCMA
audio rx pipeline: pipewire <--- aubuf <--- auconv <--- auresamp <--- PCMA
aufile: end of file26/64000 (bit/s)
audio: ausrc - end of file
28595...@voip.eutelia.it: Call answered: sip:33813...@voip.eutelia.it;transport=udp
stream: update 'audio'
audio_recv: Set audio decoder: PCMA 8000Hz 1ch
28595...@voip.eutelia.it: Call established: sip:33813...@voip.eutelia.it;transport=udp
sip:33813...@voip.eutelia.it;transport=udp: session closed: Connection reset by peer [104]
sip:28595...@voip.eutelia.it: Call with sip:33813...@voip.eutelia.it;transport=udp terminated (duration: 8 secs)

The messages "Call Answered" and "Call Estabilished" come AFTER  the "ausrc - end of file" log. If I try and I'm really quick in picking up the phone call, I can hear the WAV file before it terminates (it's pretty short, like 5sec).

How can I tell baresip to only start playing the audio file when the call is estabilished?

Thanks a lot!

Francesco



Francesco Montorsi

unread,
Jun 12, 2025, 4:54:37 AMJun 12
to baresip
I forgot to add that I'm using baresip v3.22.0 and that I get the same behavior if I start baresip in interactive mode and then I issu:

/ausrc aufile,/tmp/test.wav
d <phoneNumberToCall>

Again I see that the audio file starts immediately, before the call is established... if you think this is a bug I might try to take a look at the code and submit a PR...

thanks,
Francesco

Christian Spielberger

unread,
Jun 12, 2025, 5:00:47 AMJun 12
to Francesco Montorsi, baresip
Dear Francesco,
this seems to be a bug. Please try to reproduce this with main HEAD and create an issue on github? Your also welcome to create a PR if you find a solution.

regards,
Christian.

--
You received this message because you are subscribed to the Google Groups "baresip" group.
To unsubscribe from this group and stop receiving emails from it, send an email to baresip+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/baresip/b7fc51c5-61ba-4605-810b-54b7c0170925n%40googlegroups.com.

Francesco Montorsi

unread,
Jun 12, 2025, 5:09:17 AMJun 12
to baresip
Thanks Christian,
I just compiled the latest git main branch and I still get the same.
Looking into the closed issues I think I found the same problem here: https://github.com/baresip/baresip/issues/2882
This should have been fixed in March 2024 apparently... but it seems it's back.
I'm going to dig starting from there...

Thanks,
Francesco

Christian Spielberger

unread,
Jun 12, 2025, 5:15:42 AMJun 12
to Francesco Montorsi, baresip
Reply all
Reply to author
Forward
0 new messages