[Asterisk-Dev] H323 Channel Driver - CODEC SUPPORT UPDATE

[Ben Lear]

** UPDATE **

Thanks for the informative response Michael, looking through the code I
can see what has transpired in my absence from the Asterisk scene.
Though I'm still undecided if moving the codec support from the driver
into the Asterisk core is the overall best solution, but I'm sure this
has been debated long and hard so I'm not going to go there. 

After reading the following post from Jeremy;
"....Speex and iLBC works on chan_h323. I've tested it personally...."
I again tried (really hard) to get the "pingtel" driver to work with
Speex to no avail, also I noticed that unless you are using a-law or
u-law then In-band DTMF is just not gunna happen (which is what I need
for my application) due to the reliance on the in-band detection code in
DSP.C, thus, SPEEX and GSM(GSM/MSGSM) will not have in-band DTMF.

So armed with a little more knowledge I decided the best bet for a fast
solution would be to go back to my working mod of your channel driver
and try and get that to compile and see if it runs. What I thought was
going to be a nightmare turned out to be straight forward, basically
change some of the mutex functions, comment out a number of redundant
struct members and bingo it compiled against the *lastest* openh323 lib
from the sourceforge CVS. Now I did not expect it to run, but I tried it
anyway and to my surprise it worked first go... *ALL* current H323
codecs worked *WITH* DTMF in-band.

Now I would be first to admit this is indeed a hack, but at the end of
the day if you want to make, make install and connect h323 clients
utilizing the full range of CODECS straight out of the box then this may
be the "bridging" solution for you (until something better comes along
anyway :) ).

I'm happy to provide to anyone that's interested the patched source for
the InAccess H323 channel driver (if you would like to review it first
Michael just let me know).

Cheers,

Ben. 

-----Original Message-----
From: asterisk-dev-admin at lists.digium.com
[mailto:asterisk-dev-admin at lists.digium.com] On Behalf Of Michael
Manousos
Sent: Thursday, 28 August 2003 6:30 PM
To: asterisk-dev at lists.digium.com
Subject: Re: [Asterisk-Dev] H323 Channel Driver

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.



_______________________________________________
Asterisk-Dev mailing list
Asterisk-Dev at lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev