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...)"
_______________________________________________
Asterisk-Dev mailing list
[email protected]
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev

Reply via email to