Asterisk Quit with ConfBridge and jitterbuffers enabled

Hi Folks,

I’m using Asterisk, compiled from source on Debian 6. I have a couple of SIP clients (one hard phone, one soft phone) and a second Asterisk ( machine connected via IAX to which another hard phone is connected. The Asterisk 1.8 server has no DAHDI hardware so I am relying on internal timers, I suppose. (running ‘timing test’ from the CLI suggests Asterisk is using the timerfd module)

At the moment all phones and the two Asterisks connect across my LAN, however when the server goes into production it will be across the 'net. So I thought I’d enable the jitterbuffers for the IAX and SIP channels.

It seems that jitterbuffers generally do bad things to the ConfBridge application.

First issue: If either the IAX or SIP jitterbuffers are turned on, every now and again Asterisk will crash when I call in to a ConfBridge conference on the 1.8 server from the phone on the 1.6 server through IAX. If the jitterbuffers are disabled, I have not seen the crash. It doesn’t happen every time so is hard to debug.

Second issue: If the IAX jitterbuffer is enabled, audio from a call coming from the IAX channel into the ConfBridge application is very choppy. Audio the other direction is fine, as is audio between the SIP clients. In this case it seems that the IAX jitterbuffer is interfering with the ConfBridge’s audio.

I would suspect these things are related and it’s possibly some issue with timing in the deep insides of the system.

For the moment I’ve turned off the jitterbuffers and things seem OK. It is a shame though, the jitterbuffers and the ConfBridge application are two really attractive features of Asterisk 1.8 and it’s a shame not to be able to use them together.

The jitterbuffers seem to behave correctly when calling between the phones, it’s only in combination with the ConfBridge application that I see the problems.

Has anyone had a similar experience? I’m wondering if it worth submitting bug reports to Digium.


We’ve got some heavy lifting going on for the ConfBridge application relative to 1.10. It’s worth opening a bug, yes. If there’s an identifiable problem, we don’t want it existing any longer than it has to; and, if we’re already spending time on ConfBridge for tomorrow, it’d be a reasonable time to look into any problems with it today.