Natural write failed while leaving a voicemail message

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.

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?

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

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.