Skip to main content

Loss of DTMF when using jitter buffer

Posted by ci_newman on Fri, 11/06/2009

Hi folks!

Whenever I configure a jitter buffer in sip.conf:

jbenable=yes
jbforce=yes
jbmaxsize=50

Some of the tenants on my MTE lose the ability to send DTMF tones. For the testing, I am using the same Cisco 7940 on a no-nat connection using RFC2833 DTMF tones.

When configured on tenant-a, I can call an outside IVR and the menu operates correctly based on the DTMF tones sent.

The same IP phone, configured in the same way but for a tenant-b does not operate the menu. As far as tenant.include is concerned, both tenants are set up in the same way and both tenants are using the same outbound trunk for calls.

What am I missing???

Regards,

Chris


Submitted by eeman on Fri, 11/06/2009 Permalink

dont force the jitter buffer (jbforce). Jitter buffers are only for end points. If you are sip handsets and a PRI this makes sense but forcing isnt necessary it will just use it. If you are sip -> sip a jitter buffer should not be applied (jbforce makes it apply even when regular logic says otherwise). In a sip -> sip scenario it would normally do a packet to packet transfer which is way more efficient but forcing a jitter buffer always keeps the asterisk internal channel in the middle of the audio stream.

Submitted by eeman on Fri, 11/06/2009 Permalink

fwiw the only time the jitter buffer in sip would really initialize when force is not set is when a sip device starts calling a feature on the system like voicemail, conferencing etc. The handsets have jitter buffers built in for audio arriving on the handset. The far end should have the same unless you have a PSTN connection and in that case use the jitter buffer on the dahdi channel instead.

When 1.4 first came out I bugged a problem with the sip jitter buffer being enabled where a call came in from a chan_zap (in this case it was a analog line) and handset a answered and transfered it to handset b. Whenever handset b answered it was always a 1-way audio call. I disabled sip jitter buffers at that time and never turned them back on. I've had similar issues with iax2 jitter buffers in 1.2 code.

Currently the only jitter buffers I run is in chan_dahdi.conf and I run it in fixed mode.

Submitted by ci_newman on Fri, 11/06/2009 Permalink

Hi Erik, thanks for the reply.

We are running a PRI -> SIP set-up and finding that when receiving an inbound call via a queue (oddly enough not with DDI calls), after a short time into the call we get voice jitter. Enabling / forcing the jitter buffer has resolved this particular issue but introduced the one mentioned above.

The jitter issue doesn't happen when calling SIP -> SIP, as you would expect.

Regards,

Chris

Submitted by eeman on Fri, 11/06/2009 Permalink

try running the jitter buffer out of chan_dahdi instead of chan_sip with a fixed implementation and see if that does anything for you. How are you running your queues? Is it invoking chan_agent who is then setting agents as Local/extension@somecontext/n ? If so then chan_local is probably your culprit and there's a better way to deal with this. FWIW I have many many installations (even those with digium TE412P pri cards) that have no jitter buffers at all and no issues of distorted audio.

who is hearing the jitter? keep in mind that the only thing you can buffer is the inbound stream... what comes from the pri to the end user isnt de-jittered since it hasn't left over a network to actually have jitter.

you realize theres a math problem with your max size right? your audio is in 20ms packets so how can you do 50ms? Thats only 2 packets of buffer (40ms). Have you tried the default 200ms? or 100ms?