Natural write failed while leaving a voicemail message

[ldardini]

From time to time, while a caller is leaving a voicemail message on Asterisk 18.7.1 with voicemail_odbc module, I get the following error and the message is truncated and the channel hangup.

[2021-10-28 12:39:17] VERBOSE[20313][C-0000098b] pbx.c: Executing [~~s~~@FollowDestination:548] VoiceMail("SIP/BandwidthSEC-00000eef", "198@AA01002,su") in new stack
[2021-10-28 12:39:17] VERBOSE[20313][C-0000098b] file.c: <SIP/BandwidthSEC-00000eef> Playing '/var/spool/asterisk/voicemail/AA01002/198/temp.slin' (language 'en')
[2021-10-28 12:39:28] VERBOSE[20313][C-0000098b] file.c: <SIP/BandwidthSEC-00000eef> Playing 'beep.ulaw' (language 'en')
[2021-10-28 12:39:29] VERBOSE[20313][C-0000098b] app_voicemail_odbc.c: Recording the message
[2021-10-28 12:39:29] VERBOSE[20313][C-0000098b] app.c: x=0, open writing:  /var/spool/asterisk/voicemail/AA01002/198/tmp/7ByMum format: wav, 0x7f9b1400eec0
[2021-10-28 12:39:48] WARNING[20313][C-0000098b] file.c: Natural write failed
[2021-10-28 12:39:48] WARNING[20313][C-0000098b] app.c: Error writing frame

Any idea about the reason it is happening?

Take in mind the server uses a ramdisk to temporary store voicemail messages (but the problem was happening also when using the disk). There is plenty of space on it.

[kharwell]

I took a look at the code, and based on the given information there appear to be only a few cases in which this could occur. 2 of the 3 cases also have other associated warning messages if those would have been the cause. And since I’m not seeing those in the output a best guess is it’s the only case left which happens when the given frame’s datalen is equal to 0.

As to why it’s possibly 0, I am unsure.

Do you have a jitterbuffer enabled on the channel(s)? If so perhaps a packet is dropped and an interpolated frame is passed to the function if such a thing is possible.

Maybe someone else knows of possible cases where an audio frame might have no data, or well have a datalen of 0?

[ldardini]

The server where it happens has no jitter buffer active and I was able to download the complete pcap of the call (available if it can be worth analyzing it if you think this can be escalated to an issue). From a first check, the call was completely normal and all the packets coming from the provider was 214, with correct payload