[Asterisk-Dev] common infrastructure for jitter/vad/echo/freq diff compensation on terminal/sync devices

[Steve Kann]

Orehov,

I really don't understand what it is you're looking to implement or 
change, w.r.t. the jitterbuffer, PLC, etc system that's presently in 
-HEAD, but I'll respond to the particular points I could figure out:


On May 7, 2005, at 6:04 AM, Orehov Pasha wrote:

> Paul Cadach wrote:
>> Hello "tezka",
> Hi
>> Orehov Pasha wrote:
>>>> I would like to see in 1.2:
>>>> 1) working/stable h.323 stack - #3967 and other;
>>>> 2) configurable PRI functionality (facilities, IEs per individual 
>>>> connections, not per switch type) - no ticket
>>>> available but -dev list have reports;
>>>> 3) loadable language syntax modules (with russian support) - #3832 
>>>> (russian support is pending);
>>>> 4) event-based MWI - #2980;
>>>> 5) T.38 support;
>>>> 6) unloading modules on shutdown (should help chan_h323 to 
>>>> unregister from Gatekeeper on Asterisk's shutdown) -
>>>> discussed long time ago in #asterisk-dev;
>>>> 7) internal timing for indications and moh without zaptel hardware.
> 9) "R1.5" shuttle/packet as R2 for russian federation
>>>
>>> 5a T38 passthrough (I have many h323/sip devices which handles t38 by
>>> yourself and less need with t38 termination at asterisk)
>> IMHO 5 should be replaced by 5a until T38 integration with spandsp is 
>> ready.
>>> 8 common infrastructure for channel negotiation: VAD,jitter,echo,freq
>>> diff compensation for SYNC/terminal channels (such as alsa,zap,modem)
>> Could you explain deeply?
> Did you called from h323 g729 w VAD to alsa? Did you have long call 
> (10+ hours (it lead to buffer overflow for me))? Was voice (and 
> silence) smooth? It was not for me. So in my alsa-based driver  I have 
> to
> 1. take clock to write to device from device, not from ast_write().

This would be ideal if bridged channels could do this, but it would be 
a rather major (and complicated) change to the present design.  At 
least, it would be either complicated (because some channels cannot 
work this way), or inefficient (because forcing all channels to "pull" 
would be less efficient than having things pushed to them).

> 2. Add "G711I" from spandsp0.2 to smooth voice but g729 has internal 
> smoother (lose recovery) but it was unavailable for me

That's not an 'asterisk' issue, it's dependent on the provider of the 
proprietary g.729 module you use supporting PLC in their proprietary 
binary module.

> 3. ignore ast_read and use queue_frame because i has many 
> devices/calls on single RS232 in a my device (What is right way here?)

I have no idea what this means.  You're sharing lots of calls over a 
serial connection?


> So (8) is
> 1 ability for asterisk take write clock from dst channel, not src (if 
> dst need and declare it)
> 2 ability to interpolate lost/skipped/dropped frames utilizing 
> internal capabilities of codecs. It better then generate non-smooth 
> G711 flow from G729 and interpolate it by g711I. Isn't it?

Yes, see (2) above.

>>> and bypass of  packet flow on "transit" channels such as SIP,H323,IAX
>>> w/o mangling.
> in transit call iax-iax we don't need to jitter compensate. It is work 
> for terminal device. and it has nothing in common with native 
> bridging.

The jitterbuffer as integrated into IAX is already automatically 
bypassed when the channel is bridged to another VoIP channel (unless 
you configure it otherwise).  I posted this all to the list, Olle 
included it in a README, and it's clear in the code and configuration 
files.



>> It's naming as "native bridging". SIP, H.323, MGCP, Skinny uses RTP 
>> for voice packet transmission and could be easily
>> bridged, but IAX have its own streaming technique and can't be 
>> natively bridged with RTP.
> Did you see if(ch0->bridge==ch1->bridge){bridge(ch0,ch1)} ?
> so h323 never bridge to SIP. and H323 never bridge to IAX becase RTP.

>
> Native bridging is nothing of the kind i mean. It was taked  against 
> jitter buffer in IAX as thing out of place. And in contrast of 
> uniformed service of jitter/freq diff/vad/echo compensation. And 
> against code duplication in every syncronous device such as zap. and 
> luck of such service in over "simple devices/channels (alsa/oss, 
> modem,my...)"

The jitterbuffer itself is a separate module, and it could be used 
anywhere in the path of media.  The part that integrates it into 
chan_iax is pretty trivial "glue" code, and it could be moved somewhere 
else.   Still, I readlly don't understand what you're saying here:  If 
it gets integrated into chan_iax2, and rtp.c, then channels which 
render audio directly (alsa, oss, modem, zap, etc etc) won't need to 
duplicate any code.

-SteveK