Im trying to find out why I am getting voicemail cutoffs on Asterisk 16.
Im getting reports and example voicemails where the person has been cut off mid recording.
The particular systems in question get the following error and in my testing Im occasionally getting this error and the call drops out:
Jun 13 13:18:47 ###server### local0.warn asterisk[1203]: WARNING[1533][C-000004bc]: file.c:293 in ast_writestream: Translated frame write failed
Jun 13 13:18:47 ###server### local0.warn asterisk[1203]: WARNING[1533][C-000004bc]: app.c:2010 in __ast_play_and_record: Error writing frame
I see none of these on my Asterisk 13 systems. They both have the same voicemail.conf config:
The files are certainly not too large and plenty of disk space. format=wav.
Yes I realise there are later versions and I will be moving to Asterisk 18 but is this really an Asterisk bug at 16.27? I did upgrade to 16.30.0 and it did the same thing.
Is there anything I should be looking for rather than just assuming its an Asterisk bug?
Im using alaw for all calls but I will do some debugging to confirm its using this when it fails.
I upgraded to Asterisk 18.16.0 and it still did it. Any ideas what could be causing this?
The two possible causes are what I stated. The first case would require probably orchestrating things and going through the complete media flow to determine where/how a frame with no data appeared.
is the call still active or is the log message a result of cutting off the call?
I recently had to deal with a provider who was waiting for incoming audio data. However, the data usually does not flow while the recording is running. Thus, the provider disconnected after a certain time.
The solution was the option “transmit_silence=yes” in the file asterisk.conf, section “options”. This option causes RTP data to flow towards the provider while the recording is running.
So the testing I performed was to call into the system from my mobile to a number that goes directly to voicemail without a greeting. If the call stayed up for a couple of seconds then I would hang up and call again.
Whenever I got the Warning messages, the call actually dropped. Another log line I didnt add was:
-- Recording was 0 seconds long but needs to be at least 1 - abandoning
We are the provider actually with Asterisk as a softswitch but its not really sitting there for a period of time e.g. the call drops pretty much immediately.
That being said, I tried “transmit_silence=yes” and although I did experience a single dropout it was in over 150 calls so MUCH better than previously.
Interestingly I did get the warning logs occasionally after I hung up which I suspect is fine.
I will try setting this at a couple of our problem sites to see if it fixes the problem.
Thanks so much for responding.
you probaly need to do a tcpdump and look into what is happening with SIP+RTP
to see if you can find somehints on what is causing the calls to be droped
Thanks all for your help.
Well setting transmit_silence=yes didnt fix the issue.
Using tcpdump I managed to do a packet capture as the problem is unfortunately occurring frequently enough to make this possible.
After looking at the pcap with Wireshark, the RTP stream looked fine and I could not find any empty RTP frames e.g. all had payload entries and were the same size. They were all G.711 PCMA encoded as well.
Really sorry but not sure where to go from here as surely it cant be a disk write issue otherwise I would probably be seeing other issues and its pretty intermittent?
Update:
I actually think I have fixed the problem. I removed the adaptive jitterbuffer from voicemail in the dialplan and I was not able to make it happen again after over 30 attempts. I put it back and it cut off the first call.
Will implement out in the wild and see if it fixes the problem. Will let you know how I go.
I can confirm that removing the adaptive jitterbuffer from my voicemail module and prior modules in the call flow has solved this issue.
Is this a recognised bug? I was using Set(JITTERBUFFER(adaptive)=default).
All current bugs are filed on Github[1]. If nothing is there, then it’s not in the issue list. Asterisk 16 also no longer receives bug fixes, and no issues will be accepted against it. We only accept security reports for it.
Sorry didnt get a notification of your reply for some reason.
This was tested with Asterisk 18 as well and did exactly the same thing. I did a thorough search of the issues list and could not find anything regarding this.
Worth raising an issue once I have officially moved to 18?