[asterisk-dev] [Code Review] JITTERBUFFER dialplan function - places a jitterbuffer on the read side of a channel

[Leif Madsen]

> On 2011-04-04 16:44:19, David Vossel wrote:
> > /trunk/funcs/func_jitterbuffer.c, lines 285-287
> > <https://reviewboard.asterisk.org/r/1157/diff/2/?file=16038#file16038line285>
> >
> >     One complication I am dealing with is how to handle the fact that a user could place a jitter buffer on both the read and the write side of the channel.  I think I should add a check at the beginning of this function to detect if a write jitter buffer is present on the channel, and if so exit.

What happens if I execute this before calling a Local channel, or inside of the Local channel? What if I'm using Local/foo at jimmy/j?

(from wiki:  'j' - Adding "/j" at the end of the string allows you to use the generic jitterbuffer on incoming calls going to Asterisk applications. For example, this would allow you to use a jitterbuffer for an incoming SIP call to Voicemail by putting a Local channel in the middle. The 'j' option must be used in conjunction with the 'n' option to make sure that the Local channel does not get optimized out of the call.)

Just trying to think of any situations where another jitterbuffer might be getting enabled from the dialplan that could interfere with this.


- Leif


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1157/#review3282
-----------------------------------------------------------


On 2011-03-31 17:29:42, David Vossel wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1157/
> -----------------------------------------------------------
> 
> (Updated 2011-03-31 17:29:42)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> This patch allows a jitterbuffer to be placed on the read side of a channel using a dialplan function.
> 
> I accomplished this by using framehooks (awesomehooks) to capture audio frames in the read direction of a channel.  As frames enter into the framehook callback two things may occur.
> 
> 1. If the frame is audio, it is placed into the jitterbuffer and then converted to a null frame.
> 2. If the frame either comes in as a null frame, or is converted from audio to a null frame, the jitter buffer is checked to see if a frame is ready to be released.  If this is the case, the null frame is replaced by the next available dejittered frame from the jitterbuffer queue.
> 
> Frames are guaranteed to be released at a consistent interval through the use of a timer.  The channel listens to this timer's fd causing read to get called each time the timer fires.  Read will get called more often that usual with a jitterbuffer on the channel, but frames will not be released until the right delivery time is met.
> 
> 
> Diffs
> -----
> 
>   /trunk/funcs/func_jitterbuffer.c PRE-CREATION 
>   /trunk/include/asterisk/abstract_jb.h 312069 
>   /trunk/include/asterisk/channel.h 312069 
>   /trunk/main/abstract_jb.c 312069 
>   /trunk/main/channel.c 312069 
> 
> Diff: https://reviewboard.asterisk.org/r/1157/diff
> 
> 
> Testing
> -------
> 
> I tested this by creating simulated network delay with netem.  Delay was set to vary between 200ms-100ms and packets were set to vary in the order they were sent.
> 
> A call coming in on the network with delay enters a meetme conference and plays back a file. Another phone is used to connect to that meetme conference without the simulated delay to hear the effect of the network on audio quality.  Without the jitterbuffer enabled on the playback channel, the audio being played into the conference sounds terrible.  With either an adaptive or fixed jitterbuffer set at at least 200ms in size the audio sounds perfect.
> 
> 
> Thanks,
> 
> David
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20110411/e07e9479/attachment.htm>