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

[Michael Manousos]

Ben Lear wrote:
> ** 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: 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
> 
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev