** 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 :) ).
Nice work! Although I still believe that the best solution would be to write H323_LIDCodec-based classes for these that don't have one (Speex, iLBC).
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).
Sure, just mail me!
Cheers,
Ben.
Michael.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Manousos Sent: Thursday, 28 August 2003 6:30 PM To: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev
_______________________________________________ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev
_______________________________________________ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev