Has anyone experimented with increasing the DAHDI chunk size in improve fax reliability? If so, did it help, hurt, or not make any difference?
You can follow any responses to this entry through the RSS 2.0 feed.
Both comments and pings are currently closed.
I haven’t found issues related to the DAHDI chunk size. The main thing which used to hurt FAXing with Asterisk before Digium launched their own FAX software was the timing within Asterisk, which they refused to fix at that time (although independent patches were available). With the launch of FFA they changed chan_dahdi so on a FAX call the buffering should change to make the flow of transmitted audio a lot more elastic. People just tolerate some hiccups in voice calls, but hate latency. Modem signals must be rigidly timed, but a bit more latency is OK. This change fixed the main issue affecting all the FAX solutions around. If that switch in the buffering mode is not happening on your system for some reason it can badly affect the reliability of FAXes.
I’m uncertain of exactly to which changes you’re referring. Your comments seem to fall in-line with the notion behind the DAHDI “buffers”
feature for the channel as well as the DAHDI fax-detection “faxbuffers”
feature, but I’m seeing no noticeable improvement, AND I’m uncertain how to implement the CHANNEL(buffers) feature due to:
— Executing [4628160@fax-outbound:1] Set(“IAX2/ttyIAX99-584″,
“CHANNEL(buffers)=”12,half””) in new stack
[Aug 18 20:12:40] WARNING: func_channel.c:530
func_channel_write_real: Unknown or unavailable item requested: ‘buffers’
— Executing [4628160@fax-outbound:2] Goto(“IAX2/ttyIAX99-584″,
“outbound,4628160,1″) in new stack
— Goto (outbound,4628160,1)
— Executing [4628160@outbound:1] Dial(“IAX2/ttyIAX99-584″,
“DAHDI/g0/4628160″) in new stack
On some installations there are occasional instances in most outbound calls where Asterisk creates what otherwise would be considered jitter on the DAHDI channel. Generally these do not cause much real-world trouble, but I’m a stickler for perfect audio quality on all-digital calls. I’ve seen this on Asterisk versions 1.4, 1.6, and 1.8. On other installations there never is any such trouble noticeable.
Would you mind being a bit more specific on the Asterisk changes to which you refer and how they should be implemented in the configuration?
I was referring to the DADHI buffer control, which is (or was the last time I looked) tied in with the DADHI channel’s fax detection scheme. It was never that big a problem with iaxmodem for some reason. The timing of things passing through Asterisk was always handled more smoothly than the timing of things originating from within Asterisk.
For smooth audio flow you need to have plenty of audio buffered up in the DADHI transmit queue. Sometimes DADHI doesn’t get serviced for quite a long time, and the queue needs enough stored audio to prevent underflows. The same issue can cause buffer overflows on the audio receive side, and additional buffers certainly help there, but underflow on the transmit side was always the dominant problem.