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

[Kevin P. Fleming]

On 04/25/2012 11:08 AM, 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.

... and in Asterisk 10, there is the JITTERBUFFER() dialplan function 
that can be used to apply an adaptive jitterbuffer to *any* channel, and 
on the 'read' side where it belongs :-) The jitter buffer config options 
in channel drivers really shouldn't be used any more.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming at digium.com | SIP: kpfleming at digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org