[Asterisk-Dev] H323 Channel Driver

[Jeremy McNamara]

Speex and iLBC works on chan_h323. I've tested it personally.

Jeremy McNamara

Adam Hart wrote:

>I'd love to see some development on H.323, more specifically, Speex working
>with H.323.
>
>good luck with it
>
>----- Original Message ----- 
>From: "Ben Lear" <benlear at benlear.com>
>To: <asterisk-dev at lists.digium.com>
>Sent: Thursday, August 28, 2003 3:48 AM
>Subject: [Asterisk-Dev] H323 Channel Driver
>
>
>  
>
>>Hi all,
>>
>>It has been quite a while (almost a year :| ) since I first played
>>around with Asterisk H323 channel drivers. A current project requires
>>such functionality and thus I have a rekindled interest. During my time
>>away the Asterisk and openH323 libraries have changed considerably and
>>the modified Inaccess H323 channel driver which I had working near
>>perfectly... no longer even compiles :(  Which is a shame as it
>>supported *ALL* the H323 CODECS made available by openh323, not just
>>A-Law, U-Law and sort of GSM.
>>
>>Checking around today I see there are now two implementations, the
>>original Inaccess(pseudo soundcard version) and "Pingtel"(Native
>>Asterisk RTP Stack version). Now, I got both of these to work (with some
>>tweaking) but where back to A-Law, U-Law and GSM (sort of) which is just
>>tragic :(
>>
>>So now the question/proposal.... My idea to quickly get both/one of
>>these drivers working with all of the H323 codecs (all with DTMF etc)
>>was to implement a conversion layer at some point in the audio path. The
>>idea being that we pick something Asterisk can work with, lets say
>>u-Law, so the H323 driver *always* talks to Asterisk using u-Law and a
>>"bridge" feeds the H323 client. Something like dis:
>>
>>[CLIENT] <-> [CONNECTION] <-> [CODEC BRIDGE] <-> [ASTERISK]
>>
>>Looking into at some possible implementation points it seems fairly
>>straight forward to do. I know I would be copping a encode/decode CPU
>>overhead but I care not (hardware is cheap). This could be a bridging
>>solution in itself until Asterisk supports the required native H323
>>codecs / functions and a "nicer" driver can be molded, at such time this
>>could be slotted into existing applications that use the "bridge" driver
>>with zero reconfig; it should just work :)
>>
>>Anyways, I just thought I would throw this at the list to see if anyone
>>has some already done this or has some comments before I start coding.
>>
>>Let the flaming begin :P
>>
>>Cheers,
>>
>>Ben.
>>
>>
>>
>>
>>
>>
>>
>>
>>_______________________________________________
>>Asterisk-Dev mailing list
>>Asterisk-Dev at lists.digium.com
>>http://lists.digium.com/mailman/listinfo/asterisk-dev
>>    
>>
>
>_______________________________________________
>Asterisk-Dev mailing list
>Asterisk-Dev at lists.digium.com
>http://lists.digium.com/mailman/listinfo/asterisk-dev
>  
>