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

Orehov Pasha asterisk at opa.nsib.ru
Sat May 7 03:04:50 MST 2005


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().
2. Add "G711I" from spandsp0.2 to smooth voice but g729 has internal 
smoother (lose recovery) but it was unavailable for me
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?)

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?
> 
> 
>>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.
> 
> 
> 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...)"



More information about the asterisk-dev mailing list