Hi Group
I have always added jitter buffers in Asterisk where I can and its never really been a problem until Asterisk 13 where the /j Local Channel option adds quite a bit of delay.
After reevaluating the architecture of the system, I really cant see the need for implementing a jitter buffer in Asterisk unless Asterisk terminates the media e.g. conference, announcements etc. For all other call scenarios, whether native or non native bridging, the end devices would provide the jitter buffering anyway.
I have therefore only added the JITTERBUFFER(adaptive)=default function in the modules that terminate the media.
Does this seem a reasonable architectural decision? Have I missed something?
Thanks
Mike
(this will not be a helpful answer)
In my case is the contrary of you, on all of these years I’ve never used JitterBuffer in any of my installations. I Guess it depends on the scenario and more on the network that you are using. In my opinion, all reduce to: If your latency is normal then you will not need to enable the option.
I have never used jitter buffers until recently. I moved to the country and now require jitter buffers on my wireless internet connection. This is especially true at peak usage hours of the day.
My setup is far from normal however as I use hamachi between asterisks due to a double NAT and no public IP at the home location.
Jitter buffers have saved me and i really can discern little difference in latency. I do set the maximum jitter buffer to 120ms
Mark.
Have you tried with TCP instead of UDP?
TCP will make jitter worse. TCP turns lost packets into extreme jitter.
Generally you do not need to explicitly add jitter buffers. I think they are on by default for circuit switched channel drivers, which are the only ones where the remote system can’ t be assumed to be doing jitter buffering.
??
Jitter buffers are applied to the RTP media stream which can only be UDP.
I think you are getting confused with the SIP signalling which can be TCP or UDP.
I think you will also find that jitter buffers are not on by default.
Mike
I’m probably getting mixed up by people who try and push the RTP over TCP based VPNs.
DAHDI seems to provide a limited amount of software jitter buffering on transmit, but that is independent of the jtenable setting, which is only for receive. It looks like it might be desirable to enable jtenable on VoIP channels if there are any DADHID ones. I’m not sure about conference bridges. meetme seems to have its own jitter buffer.
I do not use TCP and not sure of the impact of jitterbuffers (if any) on TCP.
I am curios however of the following:
I have to force the media through asterisk I do this by forcing volume VOLUME(RX)=0
this means I then see “joined ‘simple_bridge’ basic-bridge” . I MUST use this on the Hamachi segment of the call or I get no audio . My configuration is
SIP Phone (LAN IP) >> Asterisk 1 (Hamachi IP} >> Asterisk 2 (Data Center Public IP) >> VoIP Termination
So my question is that with this type of bridge between asterisk machines does this impact jitterbuffers use? Should I then run jitterbuffers on BOTH asterisks?
Also if I use
Set(JITTERBUFFER(adaptive)=120,60
in the dial plan , am I forcing jitter buffers when they may not be necessary?
Can anyone provide a reasonable answer here?
If both endpoints of a media stream have their own jitter buffers, then Asterisk is purely a passthrough, whatever type of bridging it is, and any jitter buffering should be accommodated by the endpoints involved!
Mike