[Asterisk-Dev] H323 Channel Driver

[Ben Lear]

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.