[Asterisk-Dev] RFC: New Jitter Buffer

[Steve Kann]

I'm replying to my own message here, since I haven't gotten feedback of 
any kind from my previous message.    I'd like to know if (Mark, 
mainly) will accept this change, and the main issue of concern about 
that is the most significant change integrating this will make..


> It's certainly not perfect, but I've got PLC going with it, it's 
> modular, and it was pretty easy to hook up to libiax2 (and would go 
> into chan_iax2 pretty much the same way).


To use this jitterbuffer in chan_iax2, the biggest change is that it 
handles the queue of packets itself, instead of relying on the 
scheduler to handle them.

Presently, incoming frames are "scheduled" via the present 
jitterbuffer, and immediately inserted as events in the scheduler.

So, the question for integration is, how do we get the frames out of 
the buffer.  There's two choices:

1) We could extend ast_chan_waitfornandfds (even more), so that it can 
handle this itself.
2) We can keep an event in the scheduler, for each channel, to dequeue 
the next frame.

(2) should be easy enough to do, because the jb API allows you to call 
jb_next(), and it will tell you when the next frame (real, or 
interpolated) is due out of the buffer.  So, to do this, whenever we 
queue or dequeue a frame, we'd call jb_next, and adjust the scheduler 
entry as appropriate for the channel.

Next question:
In iaxclient, I implemented interpolation (a.k.a. PLC) by passing along 
voice frames with zero length data, but with the proper number of 
samples.  I've modified the codec drivers there to interpret this as a 
request for interpolated frames.  This would probably work for asterisk 
as well, although there might be cases we need to concern us with here 
(i.e. sending out a frame like this over VoIP to an endpoint that 
doesn't understand this; we should probably never transmit these kinds 
of frames via VoIP).

Finally,  how would this be integrated into rtp.c, etc;  how would 
applications/bridge situations turn off or tune the buffer for their 
needs?  As I wrote in the requirements, I think the buffer should be 
on, except in cases where the channel is bridged to another VoIP 
channel, and the codecs are compatible.  Otherwise, because the 
jitterbuffer adds PLC and stuff, you'd probably want it on.  There's 
likely to be exceptions to this, though.  For example, app_echo 
probably wants the jitterbuffer off, because the same activity will be 
handled when the frames are bounced back..

app_voicemail, app_record, etc all want it on, so that the recorded 
voice is clear.  app_meetme/app_conference also need it on..

-SteveK