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

[Orehov Pasha]

Steve Kann wrote:
> 
> 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:
It sounds nice. I'l look to -HEAD. I was speak about -stable, where i 
write channel drivers for our hardware, because -HEAD is not ready for 
proguction eat. :(
> 
> 
> 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, 
why? it'l be like HEAD/iax.c/get_from_jb but scheduled by not 
ast_sched_add but poll(POLLOUT)@ast_generic_bridge. or by thread in 
chan_, which converts channel's need of data to flag "need for a voice 
frame"and chan->alertpipe signal. when


ast_generic_bridge(){

....
  	who = ast_waitfor_n(cs, 2, &to);
	peer=(who==c0)?c1:c0;
	if(who->needvoiceframe){ /*sets by channel driver (pollout thread)*/
		f=jb_get(peer);
		ast_write(who,f); /*channel who want for a packet and
		                    data writed to it! */
		who->needvoiceframe=0;
	}else{
		f=ast_read(who);
		if(who->manualwritetiming&& VOICE_FRAME){
			 /*integrate to ast_read*/
			jb_put(who,f);
			ast_frfree(f);
			f=NULL_FRAME;
		}
	}
	/* default behavior */
	ast_write(peer,f);

> 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).
channels, who can't say write timing by youself (voip for ex.) may be 
served by push mode. as is.
channels, who can poll(POLLOUT) MUST get data at it's own speed. Because 
they WILL consume data at that speed, not at speed of peer or asterisk 
(ast_sched_add). Is it right?
> 
>> 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.
may be ... but -stable does not work at any case.

> 
>> 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?
yes. till 15 devices/calls at 1Mbit. :)
Yes, it's feature of my device, not asterisk at all. But how to deal with?
> 
> 
>> 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.
hm... interesting... I'l try to use IAX's JB in my drivers for -stable.
> 
> 
> 
>>> 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.
yes... but
1. oh323 exists. it doesn't use rtp.c nor chan_iax2.c
2. sometimes 8KHz differs at asterisk and at alsa-card (for me it is) 
and for my RS232 device. so see to (>> 1.)
> 
> -SteveK
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev