[Asterisk-Dev] H323 Channel Driver

[Michael Manousos]

Ben Lear wrote:
> 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.

There is a reason for this. At some point near the beginning,
the codecs used by the channel driver were changed from
"H323FramedAudioCodec"-based objects to "H323_LIDCodec"-based.
The first type of codecs allows any codec supported by OpenH323,
to be used by the application (channel driver). The way to do it
is straightforward, but there is a problem. All the encoding/decoding
process takes place inside the channel driver. This was wrong.
The only responsibility of the channel driver is to transfer
encoded voice between the network and Asterisk. That's why we
are now using LID codecs. They are codecs which do nothing at all
(their Encode/Decode functions are empty). Unfortunately, there are
no LIDCodec-based classes for all the codecs which are supported
by the OpenH323. Speex and iLBC don't have such a class
(although they do have H323FrameAudioCodec-based classes),
so that's why they are not supported by the channel driver.


> 
> 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]

  |                                             |
   ------------  Old H323 channel driver -------

That exactly was the logic in the first versions of the H323
channel driver, but, as I mentioned, the "CODEC BRIDGE" part
should not reside inside the channel driver. Let Asterisk
do that.

> 
> 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.
> 
> 
> 


Michael.