[asterisk-dev] Asterisk RTP Jitter Buffer and DAHDI Channels

[Fernando Berretta]

I've configured in chan_dahdi in order to try..

jbenable=yes
jbforce=yes
jbmaxsize=50
jbimpl = fixed

IP Phones / SoftPhones are in same LAN than Asterisk so.. Jitter never 
should be greater than 50ms (I hope), I've detected Windows Based 
SoftPhones send RTP packets with a lot of Jitter and.. at least for 
me... was practically imposible fix this issue

what's your opinion ?


On 4/25/2012 1:08 PM, Russell Bryant wrote:
> On Wed, Apr 25, 2012 at 11:58 AM, Kevin P. Fleming<kpfleming at digium.com>  wrote:
>> On 04/25/2012 09:27 AM, Fernando Berretta wrote:
>>> Hi Everybody,
>>>
>>> We recently had some problems with some SIP/PSTN gateways have not
>>> properly implemented RTP Jitter buffer, and as work around, we have
>>> forced a Jitter buffer in Asterisk and all worked ok.. but with extra
>>> delay of course. This situation have maked us think about all possible
>>> problems related with common RTP Jitter Buffer and how Asterisk handle
>>> Jitter Buffer when it is working as a SIP/PSTN gateway through DAHDI
>>> Channels. Could some one there please let me know if asterisk / dahdi
>>> ,by default, do something about Jitter Buffer with calls which comes
>>> from VoIP Network and goes to PSTN through Asterisk acting as a gateway
>>
>> DAHDI itself provides some very basic de-jittering, but it does not do
>> packet loss concealment or reordering. DAHDI channels have an 'input buffer'
>> that can hold a configurable number of frames of audio, and the buffer
>> policy can be configured so that the buffer must be full (or half-full)
>> before any audio will be played out to the channel. In this configuration,
>> small variations in the packet delivery times over the IP network will be
>> absorbed by the DAHDI channel, but as you say, this comes at the cost of
>> introducing some delay in the audio path (as all jitter buffering does).
>>
>> Note that the default configuration for DAHDI channels won't help much, as
>> the normal mode for the input buffer is 'immediate' mode (audio playout
>> begins as soon as the first frame is stored in the buffer). If the next
>> frame arrives before the first one is done playing out, then the buffer will
>> accept it and it won't have to be dropped, but if the next frame is late,
>> then there would be a gap in the playout. The 'half' and 'full' buffer
>> policies in DAHDI allow you to decide how you want to address this problem.
> And IIRC, chan_dahdi can provide a jitterbuffer with PLC and
> reordering above DAHDI if you enable it in chan_dahdi.conf.
>